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.