Overview
When configuring RPA invocations in Bizagi, you may rely on the use of traces for error control and diagnostics.
Traces let you detect whenever there is an issue with the RPA invocation and retrieve further detail.
RPA traces
Whenever you are debugging an RPA invocation (in Development environments) or whenever you wish to retrieve further detail about a failed invocation, you may choose to turn on the RPA traces.
|
Keep in mind that RPA traces can be enabled anytime, but it is strongly recommended to enable them temporarily only when needed (and afterwards, disable them). Changes in this configuration will most likely require to run the Work Portal again. |
Enabling these traces is useful to track down, after an error in the application, the exact point where said error has happened. There are five points where detail is logged and you may diagnose if there is a problem with your bot's invocation, or whenever transformations were being applied to the information.
Types of traces
The following traces are logged with a chronological order, as detailed in the table below.
Chronological order |
Trace type |
Description |
|---|---|---|
1 |
Request |
Leaves a JSON file with the inputs sent to the robot before the execution of its logic. Its name has the following convention: [timestamp]_[case_identifier]_Input_[RPA_vendor]_[RPA_Process_name].json Note that timestamp is set as yyMMddHHmmss. |
2 |
Request transformed |
Leaves a JSON file with the inputs sent to the robot after the execution of its logic. Its name has the following convention: [timestamp]_[case_identifier]_Input Transformed_[RPA_vendor]_[RPA_Process_name].json Note that timestamp is set as yyMMddHHmmss. |
3 |
Response |
Leaves a JSON file with the outputs received from the robot before any transformation done by Bizagi. Its name has the following convention: [timestamp]_[case_identifier]_Output_[RPA_vendor]_[RPA_Process_name].json Note that timestamp is set as yyMMddHHmmss. |
4 |
Response transformed |
Leaves a JSON file with the outputs received from the robot after all transformations done by Bizagi. Its name has the following convention: [timestamp]_[case_identifier]_Output Transformed_[RPA_vendor]_[RPA_Process_name].json Note that timestamp is set as yyMMddHHmmss. |
5 |
Monitoring jobs |
Leaves the basic information of the monitoring of a job from its start, status check, number of remaining retries and date of the next job execution. Its name has the following convention: Rpa_Jobs_[date].log Note that the date has the following format: yyyyMMdd. However, when the month is from January (01) to September (09) and for the first 9 days of the month, the zero is not included in the date. For example, for the date 2020-12-09, the format is 2020129. |
How to trace your RPA execution?
With the following steps, we will illustrate how to use traces to detect and diagnose issues in RPA invocations.
1. Setup the traces configuration
Through the Tracing options, enable all of the Interfaces traces.
2. Re-run the bot invocation (to log the error detail)
Go to the Management Console or to the Asynchronous Activities Console and retry the invocation of the bot to have a log with detail.
Next, navigate to your Bizagi server and the RPA trace folders (in this .NET example, the location would be C:\Bizagi\Projects\[project_name]\Temporary\Trace).
In this folder you will find the job monitoring file and the detailed log of your robot.
3. Validate the traces to identify the error (one by one)
Validate information contained in these traces. The Monitoring jobs file shows the robot's attempts to execute the task and the errors recorded.
If the error concerns the inputs sent to the robot, you can check the Request file.
It is important to note that not for all cases, you could have all the files recorded.
For example, if there is an error with the inputs sent to the robot, then only the first two files (Request and Request transformed) will appear because the error occurred before having a response from the robot.
Last Updated 2/6/2024 10:12:15 PM