Skip to content
  • DE

Error handling process

If an activity fails, an error handling process can be execute, to handle the bug. With this process, the persons stored in the SAR (Staff Assignment Rule) can fix the bug without the AristaFlow Monitor. For example, the authorized persons (admins) are informed by a worklist that something has failed and errors such as network/database problems need to be corrected. The process to be started in this case (error handling process) can be configured on three levels:

  • At the node
  • At the process
  • System wide

In this order, a check is made to see whether an error handling process exists. By default, no error handling is defined and the error is only logged on the server. Error handling is then only possible via the Monitor. The assignment on the node and process level takes place in the Process Template Editor in the Properties view, as shown in the next image. A suitable process is selected from the server by clicking on Select. If no error handling process is found on these levels, the system-wide configuration is used.

The system-wide error handling process is defined in the Monitor Application as shown in the next image.

The templates for error handling receive certain input parameters from the execution manager (e.g. parameters about the current execution status) and details about the error. By default, in the Installation directory of the AristaFlow Server under ../examples/errorhandling/ there are some examples for such templates. These must be allowed for execution and can be instantiated from User "system"(so Starter Rule must be e.g. Agent (username = 'system')). To do this, the template status is adjusted after it has been uploaded to the server.

The process template ErrorHandlingTemplate has the correct API, i.e. the input parameters that are necessary for the call as an error handling process. These parameters are as follows:

For your own error handling process, you can expand this template according to your needs and make it available on the server. You can then refer to it in other templates or as a standard template for the error handling process via the Monitor. The error handling process DefaultResetErrorHandling is configured so that the user can specify how the process is to be continued after the error point. You have three options to choose from:

  • Reset Activity: Cancels the changes and resets the process step to the start state.
  • Abort Instance: The process instance is aborted.
  • No Reaction: After the bug has been fixed in the Monitor, e.g. via an AdHoc change, the error handling process is completed.

Tip

You can test your error handling process with the GeneratedForm activity, as this activity provides a Fail and discard button.

If an activity fails and an exception is thrown, the node changes to the NS_FAILED state. The next image shows the execution status and history of a failed process step in the AristaFlow Monitor.

The error information is then collected and displayed to the user as an aid to error handling. This message differs depending on the type of activity and error. You can reach the error information by double-clicking on the failed node in the Instance History in the Monitor. It is also shown to the user in the Client during error handling.

After a node fails, the BPM Platform starts automatically a new, configured workflow: the stored error handling process.

Tip

If you want to retrace the execution of the template DefaultResetErrorHandling step by step or test the integrated UserForm activity, you have to authenticate yourself as a Global Worklist. Only then will the process steps appear in your work list.

In our example form (see next image) you can use the Reaction combo box to determine what should happen to the failed activity. For the further course of the interrupted process, select the desired reaction.