Workflow Activity

The workflow activity is our suggested base structure for every workflow. Therefore, it is provided as the default workflow for the MainScriptRunners in every new project. The workflow activity comes with integrated error-handling sections and allows the user to easily resolve potential errors occurring during the process execution.

The workflow activity comes with four separate sections and behaves as a try-catch block.

Section 1: Process

In Section 1, you can design the entire process inside the provided flowchart. All process steps, including decisions and different process variants, should be included.

Section 2: On handled error

In case of a handled error being thrown inside the process, the workflow execution continues with this section. Handled errors are errors deliberately identified by the user using Raise Error Activity. In most cases, handled errors are business exceptions such as process limitations for special cases and need to be followed by specific actions, i.e. sending a message to the responsible person/inbox.

By default, Clean Application Exit is executed in the beginning of this block to ensure an empty screen is shown before starting to execute the defined activity. This ensures that the block is equally usable for errors of different types and at different points in the process. At the end of the section, we have an activity that re-throws the previous error to provide this information to the user. The error remark is written in the database and can be viewed in the AM Console.

Section 3: On unhandled error

In the case of unhandled errors being triggered inside the process, the workflow execution continues with this section. Unhandled errors are identified by the system and are not previously known by the user. They are technical exceptions, such as an activity failing due to issues with the internet connection or websites not being available.

Once a system exception is thrown, the unhandled error section is executed and, because of the default TakeScreenshot activity, a screenshot will be taken. Furthermore, the Clean Application Exit is executed at the beginning of this block to ensure an empty screen before starting to execute the defined activity. This guarantees that the block is equally usable for errors of different types and at different points in the process. At the end of the section, we have a RaiseErrorActivity to re-throw the previous error to provide this information to the user. The user is free to set an error remark and ID for the error. Another Monday recommends that users re-throw the error remark thrown by the system. The default placed RaiseErrorActivity is already set to do so. The error remark and ID is written in the database and can be viewed in the AM Console.

Section 4: Finally

The Finally block inside the workflow activity contains, by default, only the execution of the clean application exit. This guarantees that all opened windows are closed when the workflow execution is finished.

The Finally block is executed if:

  • The process ends without an error
  • The process reached the on handled error section and no error is thrown inside
  • The process reached the on unhandled error section and no error is thrown inside

Below is a scheme of the workflow activity.

workflowActivitiy.png

Was this article helpful?
0 out of 0 found this helpful