Process Logic

Introduction

When you create and modify workflows, it is important to know the basic principles of the workflow engine which result in the behavior of the ticket during the process. Therefore, we will give you a short overview of the basic rules of ConSol CM ticket processing.

Activities

Basic rules:

• Passing through a workflow, a ticket always waits behind the last activity, not before the next!
• Then it looks for the next activity which can be executed/passed.
• If the next possible activity is a manual activity, the ticket stays at the position behind the previous activity.
• If the next possible activity is an automatic activity or a decision node, the activity or the decision node script is executed, i.e. the ticket passes through this activity or node.
• An activity can have one or more manual activities as successor activities or an activity can have (only) one automatic activity as successor activity.
• When you save a workflow, the Process Designer automatically executes a consistency check. If there are any inconsistencies (e.g. two automatic activities originating at the same predecessor activity), an error message is displayed and the workflow cannot be saved.

Example 1:

Figure 125: ConSol CM Process Designer - Process logic example 1

• The ticket is created and waits behind the START node. (1)
• Activity1 is executed manually. The ticket waits behind Activity1. (2)
• Activity4 is executed manually. The ticket waits behind Activity4. (3)
• End1 is executed manually. The ticket is closed.

Example 2:

Figure 126: ConSol CM Process Designer - Process logic example 2

• The ticket is created and waits behind the START node. (1)
• Activity1 is executed manually. The ticket waits behind Activity1. (2)
• Activity3 is executed manually. The ticket runs automatically through the decision node and takes the FALSE or TRUE exit, depending on the result of the script. Then it waits (3). Only one activity is offered, either NO or YES .
• Either the NO or the YES is executed manually. The ticket waits behind either the NO or the YES activity . (4)
• End1 is executed manually. The ticket is closed.

Interrupts and Exceptions

In the course of a process, i.e during the time when the ticket is open and engineers work on it, there might be events which have to be taken care of. For example, when an email is received by the ticket or when a time range for an SLA has run out, it is important to register the event and to react accordingly.

There are two ways to define the reaction and behavior of the tickets. You can implement an ...

• interrupt
  This is a workflow architecture where the event is registered, one or more automatic activities are executed, and the ticket returns to its previous position in the workflow.
• exception
  This is a workflow architecture where the event is registered and, due to the following manual or automatic activities, the ticket leaves its previous position and is taken to a new position within the workflow or in another workflow.

Interrupts

Interrupts ...

• are activated by triggers.
• cause a short interruption of the process to react to the trigger event.
• use automatic activities (one or more subsequent automatic actions).
• put the ticket back to its previous position in the workflow, i.e. back to the position where it was when the interrupt event has fired.
• are often used to mark the ticket icon with an overlay, e.g. when an email has been received (see figure below) or when an escalation time has been reached.

Figure 127: ConSol CM Process Designer - Two interrupts

Exceptions

Exceptions ...

• are activated by triggers.
• move the ticket from its old position in the workflow to a new position. The latter can be in the same or in another workflow.
• cause the process to continue at the new position.

Figure 128: ConSol CM Process Designer - Exception

Loops (Errors in Workflows)

(Infinite) Loops will cause errors in a process. They cannot be detected by the Process Designer, so you could deploy a workflow which contains a loop as shown in the figure below.

However, the process engine detects such loops at run-time and throws an InfiniteWorkflowLoopException to prevent the complete system failure. You can of course see the exception in the server.log file. In the Web Client, an error message is displayed.

Figure 129: ConSol CM Process Designer - Loop in workflow

In the Web Client, an error message will be displayed shortly. It is not possible to save the ticket when an infinite loop exception would be caused.

The exception which you can see in the server.log file will contain lines like the following:

2017-08-02 10:30:46,684 ERROR [flow.engine.WorkflowEngineImpl] [Susan-917e766e-775c-11e7-a9f8-c5c4447a9199] Error during firing ticket change event: com.consol.cmas.workflow.common.InfiniteWorkflowLoopException: Path: defaultScope/Service_Desk/Forwarding_Activity-defaultScope/Service_Desk/Do_something was already executed

Business event triggers can also cause loops when the automatic activity which is attached to the trigger changes the parameter to which the trigger reacts. See section Avoid Self-Triggering Business Event Triggers.

Process Logic of Time Triggers

See section Business Logic and Initialization of a Time Trigger.

Process Logic of Business Event Triggers

See section Business Logic of Business Event Triggers .