×

Please give details of the problem

Skip to content

Monitoring and Debugging the Execution State of Process Requests

DigitalSuite allows you to monitor the execution of a process request. As an advanced user who is familiar with the process design, you can also update and relaunch a process request. Depending on the errors that occurred, support from the application developers is essential.

For monitoring, you use the Process Console of DigitalSuite Studio. It can be accessed from the Reports module and several other modules, for example, the ProcessModeler or the Messages module. Within the Reports module, you access the Process Console by clicking a process request in a process report. In other DigitalSuite Studio modules, an Open Console option is provided where it might be necessary to check a launched process.

Information in Process Console

Execution Path

You can view the execution path which highlights the path taken by the process request during execution. The process design is displayed along with a color-coded status for each step. Possible status are:

  • Green: The step completed successfully.
  • Amber: The step is on hold, for example, because it is waiting for a manual task to be performed by a user.
  • Red: The step failed to complete due to a problem during execution, for example, an error while connecting to a connector.
  • Gray: The step has not yet started.
  • Black: The execution of the step has been cancelled by a user or a manual task, or it has timed out.

Parameters

You can also view initial, computed, and internal parameters.

Initial parameters have been injected into the process request through input variables for the start event. They could, for example, come from a form that has been completed and submitted, an email, or a REST API call.

Computed parameters have been generated or simply updated during process execution with their latest values.

Some parameters are shown in both the initial and computed parameter lists. These were initially injected and subsequently updated during process execution. Parameters that are only in the computed parameter list were generated during process execution and not injected into the process request through input variables.

Internal parameters are used by the platform. They are set automatically at process runtime. You can view their values in the context of the process request, you cannot change the values. Click here for a list of the internal parameters used by the DigitalSuite platform.

P_engine is the engine in which the process request is running.

Additional Information

The Process Console provides the following additional information:

  • The measures and their values for the instance.
  • The name and ID of users who were dynamically added to runtime lanes during execution.
  • A log showing the errors that occurred during execution.
  • A log showing the history of changes made to the process request.

Updating Process Requests

By default, the information shown in the Process Console is read-only. To update a process request, you must first unlock the request. Once it is unlocked, you can update the execution path, computed parameters, and runtime users.

On the Execution Path tab in the Process Console, you can change the status of each process step. Changing a status is a prerequisite for retrying a step after fixing an issue encountered by the process request. For example, a connector to a third-party system may fail because the third-party system is down when the connection is attempted, or you may retry a step because of a user error.

On the Computed Parameters list of the Parameters tab, you can update or inject new computed parameters. Only computed parameters can be updated. If you need to update a variable that is only listed in the Initial Parameters list, you can create a new computed parameter with the same name.

On the Runtime Users tab, you can add or remove users from runtime roles used in the process request. A runtime lane is initially empty and populated during execution by a call to the P_add_user_to_lane FreeMarker method.

Relaunching Process Requests

You may want to relaunch a process request if, for example, an error occurred which is now fixed, or you have updated your process request.

Consider the following process request which has failed because the third-party system required by the final connector activity was unavailable when the call was made.

failed

When the third-party system becomes available, you can relaunch this process request and attempt the failed step again. For this purpose, proceed as follows:

  1. Unlock the request using Unlock in the toolbar.

  2. Decide from which step to relaunch the process.
    Usually when a process step is executed the following steps are taken: evaluate the input variables, trigger the activity (email, connector, subprocess, or manual activity), and evaluate the output variables.
    When you relaunch a process from a specific step, DigitalSuite only evaluates the output variables. This means that you usually want to relaunch the process request from the step preceding the one where the problem occurred, in the example, this is the "Validation by the Manager" step.

  3. Set the status for the chosen step to Waiting. For this purpose, click the status and choose Waiting from the list.
    waiting

  4. Set all subsequent steps to Not Started.
    not started

  5. Save the process request. Select the version in which to resume the process request. Add a comment for your changes. This is displayed in the Revisions log, which shows all changes made to the process request.
    You have the choice of either keeping the current overall status for the process request or setting it to Paused. Keeping the current status means that the request will not be relaunched. This is useful if you have only made changes to variables and/or runtime users. Setting the status to Paused prepares the request to be relaunched.

  6. After saving the process request and setting the status to Paused, you have the following options for the step in Waiting status:

    • Click the Play button to relaunch the process request.

    • Click the Cancel button to relaunch the process request by cancelling the step in Waiting status. This is required to trigger a cancel intermediary event. The Cancel button is only available for manual tasks.

    • Click the Stop button to relaunch the process request by aborting the step in Waiting status. This is required to trigger an error intermediary event.

    For details about intermediary events, refer to Intermediary Events.
    play

  7. Click Refresh from server to view an updated execution path.
    success