- My View
In this Expert Event, Steven Bell, community MVP, provides insights and best practices around Scoped Applications. Steve will show some tips on what will and won't work in a scoped application.
Live Demo Air Date March 2, 2017 - 10am PT
Steven Bell is an Architect Manager and ServiceNow Trainer for Accenture Cloud-First. He has over 30 years of Developer experience. His areas of expertise include Application Development, Development Process, Orchestration, Discovery, Asset Management, Software Quality Assurance. Steven's prior experience includes web services development in C#/.Net. He earned a BS in Computer Science from Texas Tech University - Lubbock.
And Please Let our Expert Know how they've helped! Comment Below!
Like, Share, Mark Helpful.
To increase resolution : click the "cog" icon and change to 720HD
Sorry this is a pretty basic question, but I haven't seen where I actually change the version number? Studio hasn't prompted nor forced me to change them yet.
Inside of the Studio when you go to File -> Publish you will see the version number. At this location it is the last version that was published. If it is the very first time you have published an application it will be 1.0.0. You are only allowed to publish with any given version number one time. Next time you publish 1.0.0 will be displayed, but you will need to change it to 1.0.1 or 1.1.0 or some such. Otherwise you get an error saying that number has already been used to publish with.
Outside of the Studio in System Applications -> Application -> <<your application system properties under the icon>> you will see a publish link under Related Links. When you click this the same publish form will be displayed, but it will auto-increment the version for you.
Hope that helps.
When adding application files manually, does ServiceNow automatically keep track of changes to those files and include the latest version of it when publishing the application or will it keep the state of the file from when the application file was created?
No, as I demonstrated, in that last bit, during the session you will need to:
1) Make sure you are in the right project.
2) Go to the list view and re-add the same record to your project.
This will force the system to update the record in the project. Otherwise the changes you made will not appear.
Hope that helps.
This was a great presentation, very informative and useful! I did have a unique use case scenario for a scoped application that I was hoping to get some advice on. I've been writing an application that automatically generates new table in the sys_db_object table at runtime based upon form input data from the end user of the application. I have found that I can only programatically generate new table records via script from within the Global scope, and not from within a scoped application. I believe this is due to the Application Access settings for the sys_db_object table specifically. I do not want my application to modify the access level for the global sys_db_object table, but I would still like to achieve my goal of automatically creating a new table in my application scope that extends from task, at runtime. The way that I am currently achieving this is by using REST API calls from my application scope to the global scope to generate the new table and all other related records. As you might imagine, this resulted in a lot of tedious code which feels like overkill. Can you think of a better way to achieve this? Additionally, one of the things I don't fully understand is the logic behind why SN decided to provide full web service access to the sys_db_object table, but not full CRUD access from all application scopes, or at a minimum CR access with conditional UD depending on the scope the table resides in. I value any feedback you can provide. Thanks!
Sr. ServiceNow Developer
Consider a different approach. It is not necessary to use the web service API. Try instead calling a Globally scoped Script Action via an Event. This should achieve what you want nicely. BTW, I have had to use this approach several times to get around the Packages.Java limitation within the Scoped environment.
And as to the Global sys_db_object access vs. CRUD in Scope? It is an enigma. I have found at least six different oddities like that; with no explanation as to the "why" of it. Sorry.
Hope that helps.