Process Console Concepts

The Process Console allows you to monitor the execution state of a process request and view any errors that occurred during execution. Advanced users can update and relaunch a process request.

Table of Contents

• Process Console Concepts
  • Execution Path
  • Parameters
  • Updating a Process Request
    • Updating the Execution Path
    • Updating Computed Parameters
    • Updating Runtime Users
  • Relaunching a Process Request

Execution Path

Within the Process Console, the execution path highlights the path taken by the process request during execution. The process design is displayed along with a color-coded status for each step.

Parameters

From the Process Console, you can 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.

Updating a Process Request

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.

Updating the Execution Path

You can change the status of each process step on the Execution Path tab in the Process Console. Possible status are:

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.

Updating Computed Parameters

You can update or inject new computed parameters on the Computed Parameters list of the Parameters tab.

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.

Updating Runtime Users

A runtime lane is initially empty and populated during execution by a call to the P_add_user_to_lane FreeMarker method.

You can add or remove users from runtime roles used in the process request on the Runtime Users tab.

Relaunching a Process Request

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.

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.
   

4. Set all subsequent steps to 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.
   

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