Question
Cognizant Technology Solutions
US
Last activity: 20 Jun 2025 16:00 EDT
Pega Robotics debug mode from Robot Activity
Can we debug the Pega Robot Studio flow when they're deployed and managed via Pega Robot Manager without relying on a 'RuntimeStarted' event to kick things off?
Pegasystems Inc.
US
@RichardSimonI am not sure if I understand your question. Are you asking if you can debug an automation that you've written that is kicked off by a Robot Activity? If so, you'd use the ActivityStarted event to trigger your automation. You would then start that activity via your Pega case which would cause your bot to receive that activity and begin working. You could have a breakpoint there and step through the process.
One thing I would suggest when using Robot Activities, is to segregate them from the rest of your automation logic. I always create an automation for the activity started event (I usually name this with "AE_". This automation calls another automation whose name I prefix with "AP_" (activity procedure). These are the only two automations that use the Robot Activity Component. Inside the "AP_" automation, I have an entry point and then call my automation(s) that perform the work I need. Any properties from the Robot Activity are passed in as parameters and any results are passed back out to the Robot Activity. At the end of this automation is where I call the SetCompletionStatus method on the Robot Activity.
The automations that perform the work you need done, now no longer rely on the Robot Activity. You can test them without creating a Pega case and run them as much as needed for debugging. Once you have them fully tested, then you can hook them up to be called by your Robot Activity, minimizing the need for extra steps during testing.
@RichardSimonI am not sure if I understand your question. Are you asking if you can debug an automation that you've written that is kicked off by a Robot Activity? If so, you'd use the ActivityStarted event to trigger your automation. You would then start that activity via your Pega case which would cause your bot to receive that activity and begin working. You could have a breakpoint there and step through the process.
One thing I would suggest when using Robot Activities, is to segregate them from the rest of your automation logic. I always create an automation for the activity started event (I usually name this with "AE_". This automation calls another automation whose name I prefix with "AP_" (activity procedure). These are the only two automations that use the Robot Activity Component. Inside the "AP_" automation, I have an entry point and then call my automation(s) that perform the work I need. Any properties from the Robot Activity are passed in as parameters and any results are passed back out to the Robot Activity. At the end of this automation is where I call the SetCompletionStatus method on the Robot Activity.
The automations that perform the work you need done, now no longer rely on the Robot Activity. You can test them without creating a Pega case and run them as much as needed for debugging. Once you have them fully tested, then you can hook them up to be called by your Robot Activity, minimizing the need for extra steps during testing.
Segregating the component is necessary because it won't get instantiated unless a Pega case has been created and has passed its data to the component. If you were to use this component inside your automations, you'd be unable to test them on their own.
Cognizant Technology Solutions
US
@ThomasSasnett Hey Thomas, thank you for your quick response.
Currently, I’m using two events: RobotActivity and ProjectStarted. After completing my testing in Studio, I delete the connector with the breakpoint from the first screenshot. So, when I deploy the code, it gets triggered via the RobotActivity event.
However, my question is about testing the code only using the RobotActivity event from Studio. This is because I need to consume certain properties from Pega that are passed from the case. When using ProjectStarted, I have to manually hardcode these values.
@ThomasSasnett Hey Thomas, thank you for your quick response.
Currently, I’m using two events: RobotActivity and ProjectStarted. After completing my testing in Studio, I delete the connector with the breakpoint from the first screenshot. So, when I deploy the code, it gets triggered via the RobotActivity event.
However, my question is about testing the code only using the RobotActivity event from Studio. This is because I need to consume certain properties from Pega that are passed from the case. When using ProjectStarted, I have to manually hardcode these values.
The issue I’m facing is that when I configure a bot in Robot Manager, it always picks up the package deployed and assigned to the workgroup (as shown in the screenshot below). I feel like I might be missing some configuration that would allow Studio to directly pick up a case from the workgroup, so that it halts at the breakpoint in the RobotActivity event, as intended.
Could you please advise if there’s a way to achieve this setup?
Pegasystems Inc.
US
@RichardSimon You should not need to use the ProjectStarted event to test your automation. You can simply click the test button in Studio and run that single automation (along with any of its children). In order to test it though, you need to segregate the properties, methods, and events from the Robot Activity into their own separate automation. Think of this like layers. The outermost automation is something like "AE_10DNextGen" and contains the ActivityStarted event connect to a child automation named "AP_10DNextGen". This automation has an entry point with no parameters. From here, you use any of the Robot Activity properties you need (both inputs and outputs) and pass them into or out of the main automation. We will call this one, "10DNextGen" for short. This automation is the one you'd test in Studio. It accepts any inputs provided by the Robot Activity and returns any outputs you need to pass back to the Robot Activity. No where inside it (or its children) is the Robot Activity component used. This allows it to be tested independently. Back in "AP_10DNextGen" after you call "10DNextGen", you'd pass out any outputs back to the Robot Activity properties and then call the "SetCompletionStatus" method of the Robot Activity.
@RichardSimon You should not need to use the ProjectStarted event to test your automation. You can simply click the test button in Studio and run that single automation (along with any of its children). In order to test it though, you need to segregate the properties, methods, and events from the Robot Activity into their own separate automation. Think of this like layers. The outermost automation is something like "AE_10DNextGen" and contains the ActivityStarted event connect to a child automation named "AP_10DNextGen". This automation has an entry point with no parameters. From here, you use any of the Robot Activity properties you need (both inputs and outputs) and pass them into or out of the main automation. We will call this one, "10DNextGen" for short. This automation is the one you'd test in Studio. It accepts any inputs provided by the Robot Activity and returns any outputs you need to pass back to the Robot Activity. No where inside it (or its children) is the Robot Activity component used. This allows it to be tested independently. Back in "AP_10DNextGen" after you call "10DNextGen", you'd pass out any outputs back to the Robot Activity properties and then call the "SetCompletionStatus" method of the Robot Activity.
If you setup your automations this way, then the only thing you need to test from your Pega case, is if you've correctly hooked up your input and output parameters (and if the event fires at all). I don't believe that you can get Studio to register with Robot Manager to allow you to test it as if it were an unattended bot. You could do this with the Runtime in Studio, but at that point, it might just be easier to deploy it to your test bot and test there.
By setting up your automations in this way, you ensure that the bulk of you testing and debugging is done on the automations themselves and does not need to rely on registering a bot and then assigning it work and then waiting for that work to come to the queue and be passed to the bot, etc.
If you configure your machine as if it were an unattended bot (i.e. setting up the RegsitrationOperator and Windows User in the credential manager), then you could launch Runtime from your installation directory and it would register, but then you wouldn't be able to use the debugger in Studio. You can however load the log file from Runtime into Studio and step through it as if it were running.