Debugging modes
Pega Robot Studio offers two different modes for testing and debugging your robotic automation: test mode and run mode. Test mode is most commonly used for testing a specific automation and any related sub-automations, while Run mode runs the entire robotics project. In both modes, you can use breakpoints to allow a developer to debug the project by stepping into, stepping over, and stepping out of desired spots in the automation.
Test mode
When working on an automation, choosing Test automation or Test automation without debugger executes the automation currently active in Pega Robot Studio. In Test mode you can test entry-point automations or event-triggered automations.
To aid with debugging, you set breakpoints at key spots in the automation to review data values during execution. Testing the automation halts execution at each breakpoint and allows you to check the data values before choosing to step into, step over, or step out of the next design block. Choosing Test automation without debugger runs the automation without halting execution at any breakpoints.
Entry-point automations
When testing entry-point automation, Pega Robot Studio prompts you to enter any input parameter values that are required for the automation to execute. In the automation Input dialog box, you can also select to launch the applications that are included in the Palette of the automation.
For example, your robotic automation project automates the workflow of a customer service representative (CSR) to find the closest store location based on a customer account number. The sub-automation that you are working on requires a ZIP code as an input and uses a web application to find the nearest store. The sub-automation that is in testing mode returns the store address for use in another sub-automation. Testing the automation prompts you to enter a ZIP code as the input and then display the store address when the automation completes.
After the test completes, the Test Complete dialog box provides an option to close all opened applications. If you leave all applications open, subsequent testing can use the same application to reduce testing time.
Event-triggered automations
An event-triggered automation is an automation that requires either user interaction with an application (such as a button click), or an application-driven action (such as the login screen) is displayed and created. The event can be from an application, a Windows Form project item, or from other sources that can raise an event, such as Excel, PDF Connector, or robot activity.
When you start the debugging test for event-triggered automations, a starting automation dialog box is displayed with the Start applications before testing check box set to True. The option starts all applications that are included in the Palette for this automation. You clear the testing check box if an automation checks whether an application is running and available or if running the application requires the developer to start the applications manually.
Once the applications start, Pega Robot Studio displays a waiting toast notification that alerts you to perform the user-driven event or wait for the application-driven event to occur.
Windows Forms and application bars are automatically displayed when the ShowOnStartup check box is selected in the Property Grid.
A Test Complete dialog is not displayed because there is no defined exit point on an event-triggered automation (such as an entry point automation). You need to manually stop the debugging by clicking Stop on the Standard toolbar. All applications remain open, but any Windows Forms or application bars close.
Run mode
Use run mode to test and debug the entire robotics project. Choosing Run all or Run all without debugger starts the whole project, regardless of which automation is currently active in Pega Robot Studio.
In the previous example, running the project starts at the beginning of the customer service representative’s workflow when they enter the customer’s account number. All running applications that are part of the project are stopped and restarted as configured in the project. The user performs any required actions, such as logging in and providing required user input or navigation. The project then runs through all automations and sub-automations and ends where the customer service representative’s workflow ends by displaying the nearest store address in a Windows form.
Running the project stops at every breakpoint that is set in the main automation or within any sub-automations. Choosing Run all without debugger runs the project without stopping at any breakpoints.
You can use the Environment override in the Run all debugging mode to simulate different testing environments and prepare for issues that can arise outside of your development environment. For example, in your application you use the Environment override designer to set up two separate environments to designate different URLs for the StartPage property. In the following figure, you can see how to set both URLs for both the DEVELOPMENT and INTEGRATION environments.
By setting the configuration environment to INTEGRATION, you can bypass the default URL and test your applications against a different URL that more closely resembles your production environment. On the Environment override designer page, clicking the Default Environment button opens the Change project environment window. In that window, you can select which environment you want to use for debugging, and then press Run All.
For more information about how to set up and use Environment overrides, see the Environment overrides topic.
Check your knowledge with the following interaction.
This Topic is available in the following Modules:
Want to help us improve this content?