Hi All,
Welcome back to another tutorial . In this tutorial we will be looking into a rarely known aspect in servicenow . Today we will be lloking into ServiceNow Processors.
We will understand
1. What is ServiceNow Processors
2. Usage of ServiceNow processors
3. Demo Example on ServiceNow Processors
Lets first understand what is ServiceNow Processors
ServiceNow PRocessors :
Processors provide a customizable URL endpoint that can execute arbitrary server-side JavaScript code and produce output such as TEXT, JSON, or HTML. Creating custom processors is deprecated.
When to Create Processors
Do not create custom processors. This feature is deprecated. Please use the REST APIs instead of creating custom processors. The remaining information is left for existing processors only.
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!
ServiceNow_Second_Edition_Kindle.png
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.
There are a few very important things to note about this approach, which I’ll list below. Please do not attempt this in your instance without carefully reading the below points!
The SRAPI method should be GET.
Requires authentication should be set to false.
Unless you want unauthenticated users to be able to trigger your SRAPI script to run as often as they want (very risky), you must be sure to include gs.isLoggedIn() as a condition for your script running, before it does anything important!
See my comments and conditional return on lines 14 - 23 in the code above, which prevent unauthenticated users from using this pseudo-processor.
I have not yet found a better way of doing this, which is a little disappointing since Processors just handled it for you (including the redirect after the login). If I come up with anything more friendly, I’ll update this article.
If you have any ideas, please reply in the comments and you’ll be credited for the suggestion if it works!
The redirect URL (the second argument to the redirect() function) must be a full URL, including http(s) or another resource/protocol identifier.
Please follow subscribe to my channel Technomonk and press the bell icon to get the latest update on my new videos.
Till then stay happy and safe.
Have a nice day.
Regards,
Amit Gujarathi