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 84: 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 85: ConSol CM Process Designer - Properties of a business event trigger
A business event trigger has the following properties:
Figure 86: 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 87: 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 88: 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 89: 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 90: 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 91: 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 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 92: ConSol CM Process Designer - Business event trigger with following activities
Figure 93: 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 94: 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 95: ConSol CM Process Designer - Business event trigger with following automatic activity
Figure 96: ConSol CM Process Designer - Properties of a business event trigger (2)
Figure 97: 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 98: ConSol CM Process Designer - Workflow for use case 3
A business event trigger being fired means something has been changed within the ticket. So maybe you want to report what has been changed. The object which provides the required information is an object of the class TicketChanges.
The following example shows how to report if the deadline in a task ticket has been modified. If yes, and if the ticket is currently owned by an engineer, this engineer should be informed via e-mail about the date being changed.
Figure 99: Business event trigger with linked automatic activity. In the example the trigger listens to the change of the Custom Field "Deadline" in the ticket (not to be seen)
import com.consol.cmas.common.model.customfield.meta.FieldKey
import com.consol.cmas.common.model.event.ticket.support.TicketChanges
import com.consol.cmas.common.model.mail.Mail
import com.consol.cmas.core.server.service.*
import static com.consol.cmas.common.util.TemplateUtil.TICKET_SUBJECT_TEMPLATE_NAME
log.info 'SpecialTaskTicketChangedInfo started ...'
// grep ticket changes
TicketChanges changes = workflowApi.getTicketUpdateEvent().getModifications()
def ticket = workflowApi.getTicket()
def eng = ticket.engineer
def new_date
def old_date
if (changes) {
log.info 'Special task ticket ' + ticket.id + ' has been changed.'
// if deadline field has been modified, send mail to current engineer if present
if (eng) {
// field key for requested field: deadline
fk_deadl = new FieldKey("SpecialTasks_Fields","Deadline")
mod_deadl = changes.getCustomFieldChangeInfo(fk_deadl)
if (mod_deadl){
// send email to engineer
def mail = new Mail()
mail.setTargetEngineer(eng)
def replyaddress = configurationService.getValue("cmweb-server-adapter","mail.reply.to")
mail.setReplyTo(replyaddress)
def text = workflowApi.renderTemplate("SpecialTasksTicketDeadlineChangedInfo")
def text2 = 'The old date was ' + mod_deadl.previousValue.value + ' -- '
def text3 = ' The new date is ' + mod_deadl.value.value
mail.setText(text + text2 + text3)
// def ticketName = ticket.getName()
def subject = templateService.merge(TICKET_SUBJECT_TEMPLATE_NAME, [ticketName:ticket.name])
def subject2 = " Deadline changed in Special Tasks ticket!"
mail.setSubject(subject + subject2)
try {
mail.send();
} catch (Exception e){
mailStatus = false;
}
} // end if (mod_deadl)
} // end if (eng)
// end if (changes)
Code example 11: Sending an e-mail to the current engineer of the ticket if the "Deadline" field in the ticket has been changed (dates not formatted)
See section Avoid Self-Triggering Business Event Triggers.