This chapter discusses the following:
In business processes, there are often events during a regular process which have to be taken care of. For example, it might be required to inform the team lead if someone sets a ticket priority to Extra High. Or, after a change of the engineer of a ticket, it might be required to see if the engineer is logged in (if he/she is not in, the ticket has to be transferred to another engineer). There are numerous examples in business life for such events.
Figure 81: ConSol CM Process Designer - Business event trigger
ConSol CM can notice events using business event triggers and can react to the following types of events:
When the event occurs, the business event trigger fires.
You, as a workflow developer, have to implement everything that should happen as a consequence when a business event trigger has fired! There are no automatic actions. All the business event trigger does, is to give a signal event has occurred.
A workflow can contain as many business event triggers as required. However, you have to make sure that in the process it is possible that all business event triggers can fire potentially (and that one does not depend on an action which cannot ever happen, because another business event (or time) trigger has fired before). Please see section Process Logic for more information.
Business event triggers can only be attached to a scope, never to activities.
Grab the business event trigger icon in the palette and drop it into the desired scope. It is automatically attached to the top of the scope. You can modify the position afterwards (move it to the left or right to change the order of triggers or just to improve the layout).
A business event trigger which has been attached to a scope cannot be moved to another scope. In case you would like to attach a business event trigger to another scope, remove the one you have defined and create a new one for the correct scope.
To configure the properties of the trigger, select it in the editing panel and set the correct values in the Properties Editor. See the following section Properties of a Business Event Trigger.
You can draw connections from the trigger to put activities or decision nodes behind it. The first step which is executed after a business event trigger always has to be an automatic activity!
Figure 82: ConSol CM Process Designer - Properties of a business event trigger
A business event trigger has the following properties:
Figure 83: ConSol CM Process Designer - Property "Custom Field" of a business event trigger
The script after event is only used to control and fine-tune the firing of the business event trigger! Every action which should be performed when the trigger has fired has to be located in an automatic activity behind the trigger! This guarantees a good process logic and helps visualize the process in the Process Designer.
When an event has occurred which is relevant for a business event trigger, this trigger fires. Then the script after event is executed. If it returns true, the following automatic activity or decision node with two following automatic activities is executed.
If the engineer changes more than one ticket parameter and different business event triggers have been defined for those parameters at the scope, the business event triggers fire according to their order at the scope.
Figure 84: ConSol CM Process Designer - Firing order of business event triggers (1)
If one of the business event trigger actions leads the ticket to a new destination (i.e. it is no longer in the scope where the next business event trigger would be located), the following business event trigger is not fired. In the example in the next figure, business event trigger (3) will not be fired, if the Re-calculate priority trigger (2) has been fired (see Use Case 2 in section Examples for Business Event Triggers), because the subsequent actions lead the ticket to another queue.
Figure 85: ConSol CM Process Designer - Firing order of business event triggers (2)
In case there are business event triggers in hierarchical scopes, the event is consumed by the innermost business event trigger, i.e. by the business event trigger of the innermost scope. All events which have not been consumed there, are further processed by the next outer scope, then the next and so on.
Figure 86: ConSol CM Process Designer - Hierarchical business event triggers (1)
Fired events:
| Events | Triggers fired |
|---|---|
| Queue | Inner |
| Queue and Engineer | Inner for both |
| Engineer | Inner |
Figure 87: ConSol CM Process Designer - Hierarchical business event triggers (2)
Fired events:
| Events | Triggers fired |
|---|---|
| Queue | Outer |
| Engineer | Inner |
| Queue and Engineer | Inner and Outer |
Figure 88: ConSol CM Process Designer - Hierarchical business event triggers (3)
Fired events:
| Events | Triggers fired |
|---|---|
| Queue | Inner |
| Engineer | Outer |
| Queue and Engineer | Inner (queue) and Outer (engineer only) |
If a new comment has been added to the ticket by someone else, not by the current engineer (the ticket owner), then an overlay should be attached to the ticket icon. That way the ticket is marked and the engineer can see in the ticket list that there is a new comment in one of his/her tickets. The comment can be made by another engineer who has writing access to the queue or by a customer who can add comments using ConSol CM.Track access. Or an e-mail might have been received.
Figure 89: ConSol CM Process Designer - Business event trigger with following activities
Figure 90: ConSol CM Process Designer - Properties of a business event trigger (1)
return (workflowApi.getCurrentEngineer() == ticket.getEngineer())
Code example 9: Code of decision node script
Figure 91: ConSol CM Web Client- Ticket marked with new overlay
This is an example from an ITIL Service Desk environment. According to the ITIL standards, the ticket priority is calculated from two values: impact and urgency. That means, in the ticket there are two fields which can be modified by the engineer and the priority is calculated automatically from the two values. The priority might then be displayed as ticket color or as read-only list (or both).
This principle requires a re-calculation of the priority in case at least one of the two fields (impact/urgency) has been changed. This is achieved using a business event trigger with an adjacent activity where the re-calculation is performed.
Figure 92: ConSol CM Process Designer - Business event trigger with following automatic activity
Figure 93: ConSol CM Process Designer - Properties of a business event trigger (2)
Figure 94: ConSol CM Process Designer - Property "Custom Field" of a business event trigger (2)
// Re-calculate priority:
String imp_value = ticket.get("service_desk_fields.impact").getName()
String urg_value = ticket.get("service_desk_fields.urgency").getName();
ScriptProvider scriptProvider = scriptProviderService.createDatabaseProvider("calculatePriority.groovy")
//content of calculatePriority.groovy is omitted here, because it is not relevant for the current context
Code example 10: Code of automatic activity script Re-calculate priority
This is an example taken from a shipment and delivery process: new components (e.g. hardware) are ordered. The ticket waits in the scope Order: Waiting for shipment. When the shipment has arrived, an engineer of another team registers this shipment and sets the Shipment received tag. This change of ticket data (Shipment received from false to true) is registered by the business event trigger which listens to the respective boolean value (the check box). After the business event trigger has fired, the check box is checked (in the decision node), and when the value is set to true, the ticket is forwarded to the next scope Deliver components. The engineers who are responsible for the delivery now see the ticket in their view Components ready for delivery and can acknowledge the delivery when they are done with All components delivered.
Figure 95: ConSol CM Process Designer - Workflow for use case 3
See section Avoid Self-Triggering Business Event Triggers.