Basics
The best path to exchange work between the Instance and the Robot is to use the concept of a Queue.
Read more about queues on our product docs.
Setting up a queue is really simple, all it requires is a name and description. Optionally a department can defined to keep track who 'owns' the work in this queue. A queue is - as the name suggest - a queue of work items to be processed. Queue Items are therefor the element we need to transport information to the robot. So let's have a look at such an item:
It contains some basic information like Name, status, timestamps but also scheduling options like Priority or which robot is currently processing this item.
The interesting part for exchanging data are two content fields. Request content is used to send from ServiceNow to the robot - see it as the instance is requesting this to be processed. Response content is the robots response - if any.
In this case I used Request Content to send a JSON formatted string containing a complex object. Technically there is no limitation, it could be a simple string, name-value pairs, or whatever you deem appropriate. Personally I find JSON easy to generate and parse. I'll show more on this further down in the blog, first look how an item ends up in the work queue.
Adding work to the queue
The most obvious way of adding something into the RPA queue is for sure a Flow. Flows make it easy it act on triggers like records being created or modified. For more information on Flows check the Flow CoE.
Once you have your flow setup, it is as simple as using the RPA Spoke. The spoke delivers a flow action called Add WorkItem to Queue. In a minimal setup all you need are
- the Queue where the item should be added to
- the Name of the item in the queue
Additional options are priority, stage, type and content. As for the name, it is important to note that depending on the queue settings, the name must be unique. I tend to use the unique ID for the record triggering my RPA bot - can be an incident number, request number - you get the point.
The content is the part we are most interested in for passing additional data to our robot. In a simple case you can simple craft your JSON string within the content field:
While this works, it can be a bit tricky at times. Making sure you have all comma and quote signs at the right place. If wrong the robot will not be able to read the JSON causing some hours of trouble shooting.
If you are ok with some scripting, the same can be achieved with incline script at the content field. For pro-codes this is surely a piece of cake:
Here is the code snipped in case you need it:
var myObj = {
sys_id: fd_data.trigger.current.sys_id,
number: fd_data.trigger.current.number,
customer: fd_data.trigger.current.customer.name,
discount: fd_data.trigger.current.discount,
line_items: fd_data.flow_var.line_items
}
return JSON.stringify(myObj);As you see, I am just creating my object and use the JSON api to stringify it. This way I can be sure all special characters are correctly encoded. It is also much easier to read - if you are ok to read some code.
Reading Request Content from your Robot
When working with queues, the robot needs to have some logic to know which item to work on. This blog will not focus on the queue management, i will be writing a separate blog on that topic. For now lets assume this is in place and you already use the PickWorkItem component from the Queue connector methods.
This component has by default already an output port for RequestContent. Now, this will return the JSON string as we can see it in the queue record on ServiceNow. The decode it back to an object with proper attributes we need two methods this time from the JSON component: DeserializeObject and GetProperties:
The first method will parse the JSON string and get us a proper Object to work with. The second one then will look into the properties we need. There is no output port on the GetProperties method when dropped on the canvas, you need to configure it and add the json path notations for the properties you want to be returned. That's it, the values are available and can be used in subsequent components.
Returning data to the instance
That should be a simple now as we already know where the data can be stored, right? Usually there are two scenarios when you want to return information to the instance: Success and Error or Debug messages.
The method in Desktop Design Studio is UpdateWorkItem in the Queue component. On default this provides data input for the WorkItemId and RequestContent. We can surely use the RequestContent to update the data in there, but this will kind of overwrite what is there already. A bit smarter is to use the Gear-Icon on the component and add ResponseContent, this gives an additional data input and allows for writing data into the Response Content field.
Any string you pass in this method will be stored on the respective column on the work queue item table. You can use this as often as needed, but bear in mind, the field is not audited. So the last update wins.
If you need to send lots of data or structured objects to the instance use the same pattern, create your objects and use JSON-SerializeObject method to stringify it.
Acting on bot responses
Cool, you send something the bot and you get information back - what next?
Sometimes you will need to act based on the returned information, maybe update a record or send a notification. The quickest way to do this is to create a flow which triggers on the change of the queue item record. I would recommend to use the status field, e.g. status changes to 'Success'. The flow can than easily read the response content and do something with it.
Conclusion
It is pretty easy to pass information between the instance and the robot engine, this makes the better-together story so powerful for RPA within ServiceNow. Most RPA automations require some form of trigger, schedule and data - having ServiceNow as your central piece connecting the robot to enterprise data can open lots of new opportunities to automate.
Let me know what you automate and how easy (or not?) it was to get it implemented.
6 Comments
