GenevaGem - Inspecting Orchestration REST

Since many of the projects I work on are integrations, I'm frequently working with custom orchestration activities. Most of these involve some sort of REST interface. The introduction of ServiceNow's REST API Explorer was a great addition, but I want to introduce you to another tool I find extremely useful. It's RequestBin from Runscope.

 requestb.in

requestb.in

RequestBin allows you to create temporary endpoints to receive any HTTP client request. You can then view the request data sent from the client. This can be a helpful tool when you need to debug payload or header values if it's not easy to inspect before the client sends it. A common use is for system that generate webhook event requests, just point your app to the temporary RequestBin address and it will show you everything the client is sending.

I found this extremely useful when working with custom REST orchestration activities. In many cases, the process starts with a catalog request capturing some variables. These values are then handed off to a workflow, possibly workflow variables, and finally onto REST activity variables. There could also be data transforms along the way. It's not always easy to inspect what is finally getting to the endpoint.

Adding a temporary redirect to RequestBin is quick and easy, and you'll definitely be able to tell what is being sent when it leaves ServiceNow.

 

Create a requestbin

From the RequestBin homepage, create a RequestBin. It will provide the temporary endpoint and a number of client call examples.

The endpoint will live for 48 hours and display the last 20 requests received. Simply refresh the page to view the latest request details.

 

calling requestbin from workflow

In most cases a ServiceNow REST Message object is used to manage the endpoint details, headers, and methods. So all we have to do is make a quick change to the endpoint path and we can redirect our request to the bin for inspection. This also works if you are using a script instantiated RESTMessageV2 object instead of a RESTMessage record, just change the endpoint URL in the script.

In my case, I will modify the endpoint in the post method record. Since my endpoint also uses variables, I'm going to just pass these as URL parameters so I can inspect those as well.

The next time a requested item kicks off the workflow the REST activity request will be captured by the bin instead of our normal target. Depending on how you are handling the response back, the workflow may fail from here, but that's fine we really just want to know what the request was. RequestBin should reply with "ok" and status code of 200 if all goes well.

Once we refresh the RequestBin page we will see all of the details for the request we sent.

Thanks to my friends at PagerDuty for turning me on to this.

If you're looking for a HTTP request client to test your endpoints, I highly recommend Postman which comes in Chrome and Mac flavors.