› Workflow › Business rules › Debug a business rule

Debug a business rule

Use the following procedure to debug a business rule.

  1. Navigate to Workflow > Business rules.

    A list of business rules is displayed.

  2. Open the business rule to debug and click Debug on the Modeling bar.

    The Debug page opens. The process type, such as business process, and the process name are displayed.

  3. Enter the initialization variable values.

    If a folder or a document initialization variable is used, you can select either option to upload the documents:

    • New: Click Browse and select one or more documents depending on the initialization variable (document or folder) used.

      • If a document variable is used, a new document instance is created and you can upload only one document.

      • If a folder variable is used, a new folder is created where you can upload multiple documents.

    • Existing: You can use an existing folder or a document to upload. For example, you may have a folder that contains multiple documents that have been classified and data extracted and you want to use it for debugging. You can provide an instance ID (document or folder) or leave it empty. (Folder: It creates empty folder with no documents; Document: It creates a default empty document)

    TotalAgility does not support the following variable types in a debug mode:

    • Complex

    • Dynamic complex

    • Checklist

    • Data backbone

    • JSON expression

    • System

    • XML

    • XML expression

  4. Click Start.
    The process map opens in debug mode in a new window as shown below. A job is created and displayed like the View job behavior in the TotalAgility Workspace. An asynchronous job is created for a business rule and a synchronization process.

    In the debug mode:

    • The nodes are always displayed in the default color (blue) even if the node colors are set at the system or business rule level.

    • For a flow rule, the orientation of the nodes is horizontal, but for a decision tree, the orientation of nodes is vertical.

    • The orientation option on the Debug toolbar is not available for a decision tree.

  5. To set a breakpoint, click the activity and select Set breakpoint.

    The red square mark in the activity indicates a breakpoint. Once you set a breakpoint, the Remove breakpoint option becomes available. To remove a breakpoint, click the activity and select the option as needed.

    When you remove or restart the breakpoint, the first breakpoint is ignored, and the execution of the activity is stopped at the next breakpoint.

  6. Click to debug the process.

    • Automatic activities including business rule activities, embedded processes, and subjobs are executed as they would in a normal mode. The execution stops at the next node that has a breakpoint set, and execution continues when you click "Go". The job progresses only when all dependents are met.

    • You must set breakpoints on SignDoc and KCM activities when debugging to force execution, otherwise, they are performed like Synchronization nodes. Setting the breakpoints allows the debugging execution to stop and wait for a callback from Signdoc and KCM servers.

  7. If the execution stops due to a breakpoint, you can step through activities to restart the job - click the node and click either option:

    • Restart next: Executes the current node and stops at the next node.

    • Restart here: Restarts the job accordingly.

  8. To view the job history, click on the Debug toolbar.
    The Job History dialog box displays the history of the job with the following details: Node name, status, a resource who performed, performed date, time spent, and cost.

    Click Close to close the Job History dialog box.

  9. Click Close to close the Debug mode.

See also: