Very often, we’ll find ourselves writing a custom application (whether scoped or global) that requires some “setup” by the admin who installs it. Maybe we’re writing the app to be distributed to multiple ServiceNow customers, each with their own environments and needs; or maybe the app just requires a unique setup process in each instance we promote it to. Whatever the case, I’ve often had cause to want to build my own “guided setup”.
Unfortunately, for some reason, ServiceNow has made it difficult to create a guided setup in our own development instances.
In this article, we’re going to learn how to get around those limitations; then, we’re going to learn how to build a guided setup ourselves!
Use Automated Tests to Validate "Guided Setup" Completion & Functionality.
Here's a Quick Pro-Tip:
If you have an application which requires some setup or initial configuration, write ATF tests specifically to validate that the application is set up properly. Add executing the tests as a final step in your application's Guided Setup, and provide some meaningful output that directs the admin to the right place(s) to fix any issues identified by the tests.
For example, I'm building an application now which connects to an outside application running on…
Read more"Processors", SRAPIs, and How to Run a Script and Redirect a User From a URL in ServiceNow
Processors in ServiceNow are (were) actually extremely useful things, though they’re surprisingly not very well-known. They give you a URL you can hit (like my_processor.do) and allow you to run a server-side script, then redirect the user to some other page.
Processors are quite useful for situations like generating a record and then redirecting the user to that record just by navigating to one URL, or - by adding some URL parameters (like my_processor.do?some_param=some_value) automating some simple or complex processes with nothing more than a single click of a URL! You can generate that URL dynamically and present it in the UI somewhere (for example, by using gs.addInfoMessage()), or link to the processor in an email. You could even use something like my “Set Catalog Variables from URL Parameters” tool in conjunction with this functionality to dynamically populate and submit RITMs from a single click of a link in a Knowledge Article!
Some pre-existing useful processors are:
System cache flush (cache.do)
Attachment processor for constructing and viewing attachments (sys_attachment.do)
Content search (content_search.do)
Customer service chat (CustomerServiceChat.do)
Export Wizard (export_wizard.do)
While it’s possible to modify the ACLs on the Processor table to allow you to create them again (for now), that may not be the best idea for long-term support.
So, if we don’t use a processor, how can we accomplish this functionality in our app? The answer is Scripted REST APIs (SRAPIs) plus a little bit of http header magic!
In this article, we’re going to show you how to accomplish (mostly) the same functionality as a processor using an SRAPI, and provide some code you can use to get your pseudo-processor SRAPI up-and-running within minutes! We’ll also provide some best-practice advice for how to use SRAPIs in this way, and outline some specific use-cases for this sort of thing.
Read more