Basics
RPA Hub is a great tool to manage your RPA implementation and keep an oversight of what is happening or how well your robots are doing their work. Once you have some robots implemented there is probably a list of work for them to go through. Two scenarios are possible on how to start the robots.
a) Scheduled
Scheduled means you know exactly when and how often you require the robot to act. Assume you want to fetch some information from another system and post this information to ServiceNow, like grabbing a stock quote and pushing that to your service portal. A schedule works great in this context as there is no other trigger which can be used.
You can find more information on defining schedules on our product documentation.
b) API Triggered
The second option is that some form of event in the instance requires a robot to complete the work. An examples is resetting a password via a Service Portal request or an incident ticket requesting a restart of a service in the data center.
In this scenario you have no idea on when it is required. The trigger is a manual action by a user. You can still use a schedule and just have the robot checking in every x minutes which might be ok for some scenarios, but it adds a delay to the process which for a restart might not be great. Luckily you have ServiceNow and we can use all kind of events. Let's see how to set things up for this.
The Bot Process
When creating the bot process you have an option to define the trigger mode for this process:
In this case choose API. This will remove the scheduling options from the process and it will allow that we can start the processing of work items from Flow Designer. The caveat here is: once you choose the trigger mode, it cannot be changed anymore. You will need to create a new bot process if you change your mind.
Queue
There is nothing special on the queue, a queue is merely a save storage for work items. You can even assign more than one bot process to the same queue - one with a schedule and one api based. In case you would want a safety net to wake a robot once a day at least.
RPA Hub Spoke
Now that we have a queue and a bot process, adding items to the queue is easy. The RPA Hub spoke in Flow Designer brings a set of actions like Add WorkItem to Queue. For more information on how to use the Content field in passing information to the robot read this blog.
You might be tempted to use the Start Process action as well to immediately start the bot process - and yes, this will work great in your testing cycles as usually there will be only the one freshly added item in the queue. In a more real life scenario it looks a bit different. Your robot might currently be busy doing some other work or multiple items got added in a short amount of time. In this case the Start Process action will still complete, but the item will not be processed. It might just get stuck in the queue.
So combining the adding of items with starting the process is not a great idea. Doing some planing helps, so lets think about the triggers we need to start a bot process:
- New work has been added
- A robot has finished working and some other items are still in queue
These are actually very bespoke events we know and can handle in the platform. Creating two flows is all we need. I have added two sample flows to this blog post for you to checkout. Both flows are in global context but could be anywhere. I would recommend you import these on a developer instance to examine and re-implement them in your instance based on your instance architecture.
I'll highlight the specific gotchas in these flows now.
Start Process for new work item
This flow is triggered every time a new item is added to any queue in state Pending. It will check if the queue of this new record has an associated published bot process with a trigger mode of API, if yes the bot process will be started.
The start process will try to find an available robot and send work to this robot, if no robot is available, nothing will happen. We could even extend the logic to check for available robots first...
When a process to be started was found, the flow stops. It would not make sense to look for other processes as our robot is already busy anyway.
Reset Work Queue Item
This flow is triggered when a robot's CI record state is set to Available. Robots will do that as they start up or as they finish executing a robot process. Having a robot available is our trigger to check for work.
The flow will do two pieces, first it checks any queue item record still in progress and assigned to the robot becoming available. If for some reason the robot engine crashed, or the robot implementation did not set the queue item to Success or Failure I want to capture this and prevent the same item being processed again. To do so the flow will set any left over items to status Failure and unlock it. It is only a safety net, basically a well designed Bot Package should have done so as part of its execution.
Secondly, the flow will search for all bot processes where the newly available robot is assigned to. If any of these processes is published and API triggered, then it checks if there is any Pending item in the queue. If so, it starts the process.
Similar to before, once a process has been started the flow stops. Even if other queues would have items Pending, it would not make sense to trigger the respective processes. The robot is already busy with work, they will be picked up next time round.
The robot
Now that ServiceNow is managing our queue, the robot itself can be simplified. We essentially do not need to process records in loops and such. I would recommend for the robot to use a startup routine similar to this one:
Pick a new work item, check there was indeed a work item, if not end. If yes, do the magic with the work item. This is also the part the the robot should report a Success or Failure state.
Conclusion
Adding two simple flows will make the management of API based bot processes more reliable and simpler. The robot implementation itself does not need to worry about schedules or loops to process items. It still can, but this depends a bit on how you want to use your robot VM. If the VM is bespoke for one process only, then working on the queue as long as items are in there might be beneficial. If you use the the VM for different processes it might be more beneficial to return the control which queue to process back to the instance.
One caveat remains: If you have a big and complex process involving multiple stages, then you will need some extra logic as items in the queue might need to stay in a In Progress state even though robots become available. You will either need to split the robot implementation in different bot processes or have the Reset Work Queue Item flow to respect these special cases.
I hope you find this blog useful, let me know you thoughts and ideas to make the overall solution even more resiliant.
5 Comments
