Question
Starbucks
US
Last activity: 11 Mar 2020 18:08 EDT
Robot Activity - Best Practices
I've tried searching, but am unable to find any documentation on the best practices for implementing robot activities. We're looking at this from a RPA-based point of view. Our main focus was initially RPA bots utilizing RobotManager and its scheduler.
We're now exploring using case management in PRPC to trigger RobotActivities in Pega Robotics. However, there's been some debate around the level at which RobotActivities should be implemented; especially because they are incompatible with Interaction Activities, which is in our current production use-cases.
By level of implementation, I mean how granular should their functionality be defined. Given a use case that:
-Opens Adapter_A
-Downloads File_X
-Closes Adapter_A
-Performs function on File_X
-Opens Adapter_B
-Populates data into Adapter_B from File_X
-Closes Adapter_B
Would a RobotActivity be defined exactly as Interaction Activities would to replace them 1:1? This could lead to a lot of RobotActivities and WorkQueues in RobotManager to support them, since Interaction Activities are used to communicate across projects and are defined to perform small steps of the process.
I've tried searching, but am unable to find any documentation on the best practices for implementing robot activities. We're looking at this from a RPA-based point of view. Our main focus was initially RPA bots utilizing RobotManager and its scheduler.
We're now exploring using case management in PRPC to trigger RobotActivities in Pega Robotics. However, there's been some debate around the level at which RobotActivities should be implemented; especially because they are incompatible with Interaction Activities, which is in our current production use-cases.
By level of implementation, I mean how granular should their functionality be defined. Given a use case that:
-Opens Adapter_A
-Downloads File_X
-Closes Adapter_A
-Performs function on File_X
-Opens Adapter_B
-Populates data into Adapter_B from File_X
-Closes Adapter_B
Would a RobotActivity be defined exactly as Interaction Activities would to replace them 1:1? This could lead to a lot of RobotActivities and WorkQueues in RobotManager to support them, since Interaction Activities are used to communicate across projects and are defined to perform small steps of the process.
Would one RobotActivity be defined for each of the above steps, or would one suffice for the entire process? It seems the latter would be preferable so long as only RPA is needed to complete that portion of the use-case. However, would this not add a challenge on communicating across projects? Would we store all programming variables in the case and access them via the robotActivity?
Any recommendations or documentation regarding this?
Thanks!
Pegasystems Inc.
US
I suggest building granular activities with a work group for each adapter (application) and a work queue (robot activity) for each function of that adapter. You would assemble these inside your case to complete your use case.
Pros
Re-usability of bots already running
Ability to easily resume a failed process at a given step
Easier testing as you only need to test the specific functions of the adapter with each release
Cons
End-to-end time on a stop watch will take longer as steps of the case will get assigned to different bots
Harder to demo as you couldn't watch a single bot complete the entire process
Complex for a simple or one off use case
If you were to build a single WG/WQ for a given UC, it would be best suited for one-off applications or those with limited PRPC experience. Limited licensing might also be a factor here as you'd need less bots for one use case, but more overall for many use cases.