In diesem Kapitel werden folgende Themen behandelt:
In Geschäftsprozessen treten häufig Ereignisse auf, um die sich ein Bearbeiter im Rahmen des regulären Prozesses kümmern muss. Zum Beispiel kann es erforderlich sein, den Teamleiter zu informieren, wenn jemand die Priorität eines Tickets auf Sehr hoch stellt. Oder es muss nach dem Zuweisen eines neuen Bearbeiters zu einem Ticket überprüft werden, ob dieser Bearbeiter angemeldet ist (wenn er nicht angemeldet ist, muss das Ticket an einen anderen Bearbeiter übertragen werden). Es gibt im Arbeitsalltag eine Vielzahl an Beispielen für solche Ereignisse.
Abbildung 82: ConSol CM Process Designer - Event-Trigger
ConSol CM kann Ereignisse mithilfe von Event-Triggern erfassen und auf die folgenden Arten von Ereignissen reagieren:
Wenn das Ereignis eintritt, feuert der Event-Trigger.
Sie als Workflow-Entwickler müssen alles implementieren, was geschehen soll, wenn ein Event-Trigger gefeuert hat! Es gibt keine automatischen Aktionen. Der Event-Trigger gibt lediglich das Signal Ereignis eingetreten.
Ein Workflow kann so viele Event-Trigger haben, wie benötigt werden. Sie müssen allerdings sicherstellen, dass es im Prozess möglich ist, dass alle Event-Trigger potentiell feuern können (und dass keiner von einer Aktion abhängt, die nie auftreten kann, da ein anderer Event-Trigger (oder Zeit-Trigger) vorher gefeuert hat). Weitere Informationen dazu finden Sie im Abschnitt Prozesslogik.
Event-Trigger können nur an Bereichen hängen, nie an Aktivitäten.
Klicken Sie in der Palette auf das Event-Trigger-Symbol und ziehen Sie es in den gewünschten Bereich. Es wird automatisch an den oberen Rand des Bereichs angefügt. Sie können die Position später ändern (ziehen Sie den Trigger nach links oder rechts, um die Reihenfolge der Trigger zu ändern oder das Layout zu verbessern).
Ein Event-Trigger, der an einem Bereich hängt, kann nicht in einen anderen Bereich verschoben werden. Wenn Sie einen Event-Trigger an einen anderen Bereich anfügen möchten, entfernen Sie den bereits erstellten Trigger und erstellen Sie einen neuen Trigger für den richtigen Bereich.
Um die Eigenschaften des Triggers zu konfigurieren, wählen Sie ihn im Bearbeitungsbereich aus und setzen Sie im Eigenschaften-Editor die richtigen Werte. Siehe Abschnitt Eigenschaften eines Event-Triggers.
Sie können vom Trigger ausgehend Verbindungen zu Aktivitäten oder Entscheidungsknoten ziehen, die sich hinter dem Trigger befinden sollen. Der erste Schritt, der nach dem Event-Trigger ausgeführt wird, muss immer eine automatische Aktivität sein!
Abbildung 83: ConSol CM Process Designer - Eigenschaften eines Event-Triggers
Ein Event-Trigger kann folgende Eigenschaften haben:
Abbildung 84: ConSol CM Process Designer - Eigenschaft "Benutzerdefiniertes Feld" eines Event-Triggers
Das Skript nach Event wird nur verwendet, um das Feuern des Event-Triggers zu steuern und einzustellen! Alle Aktionen, die durchgeführt werden sollen, wenn der Trigger feuert, müssen sich in einer automatischen Aktivität hinter dem Trigger befinden! Damit wird eine gute Prozesslogik sichergestellt und Sie können den Prozess im Process Designer leichter visualisieren.
Wenn ein für den Event-Trigger relevantes Ereignis eingetreten ist, feuert dieser Trigger. Danach wird das Skript nach Event ausgeführt. Wenn es true zurückgibt, wird die folgende automatische Aktivität oder der Entscheidungsknoten mit den beiden folgenden automatischen Aktivitäten ausgeführt.
Wenn der Bearbeiter mehr als einen Ticketparameter ändert und für diese Parameter im Bereich unterschiedliche Event-Trigger definiert wurden, feuern die Event-Trigger entsprechend ihrer Reihenfolge im Bereich.
Abbildung 85: ConSol CM Process Designer - Reihenfolge des Feuerns von Event-Triggern (1)
Wenn einer der Event-Trigger das Ticket an eine neue Position verschiebt (d. h. es befindet sich danach nicht mehr in dem Bereich, in dem sich der nächste Event-Trigger befinden würde), feuert der folgende Event-Trigger nicht. Im Beispiel in der nächsten Abbildung feuert der Event-Trigger (3) nicht, wenn der Trigger Neuberechnung der Priorität gefeuert hat (2) (siehe Anwendungsfall 2 im Abschnitt Beispiele für Event-Trigger), da die nachfolgende Aktion das Ticket in eine andere Queue übergeben hat.
Abbildung 86: ConSol CM Process Designer - Reihenfolge des Feuerns von Event-Triggern (2)
Wenn sich Event-Trigger in hierarchischen Bereichen befinden, wird das Ereignis vom innersten Event-Trigger verbraucht, d. h. vom Event-Trigger im am weitesten innen liegenden Bereich. Alle Ereignisse, die nicht verbraucht wurden, werden vom nächst äußeren Bereich verarbeitet und so weiter.
Abbildung 87: ConSol CM Process Designer - Hierarchische Event-Trigger (1)
Gefeuerte Ereignisse:
| Ereignisse | Gefeuerte Trigger |
|---|---|
| Queue | Innerer |
| Queue und Bearbeiter | Innerer für beide |
| Bearbeiter | Innerer |
Abbildung 88: ConSol CM Process Designer - Hierarchische Event-Trigger (2)
Gefeuerte Ereignisse:
| Ereignisse | Gefeuerte Trigger |
|---|---|
| Queue | Äußerer |
| Bearbeiter | Innerer |
| Queue und Bearbeiter | Innerer und äußerer |
Abbildung 89: ConSol CM Process Designer - Hierarchische Event-Trigger (3)
Gefeuerte Ereignisse:
| Ereignisse | Gefeuerte Trigger |
|---|---|
| Queue | Innerer |
| Bearbeiter | Äußerer |
| Queue und Bearbeiter | Innerer (Queue) und Äußerer (nur Bearbeiter) |
Wenn ein neuer Kommentar von jemanden hinzugefügt wurde, der nicht der aktuelle (zugewiesene) Bearbeiter des Tickets ist, wird ein Overlay zum Ticket-Icon hinzugefügt. Auf diese Weise wird das Ticket markiert und der Bearbeiter kann in der Ticketliste sehen, dass es einen neuen Kommentar in einem seiner Tickets gibt. Der Kommentar kann von einem anderen Bearbeiter gemacht worden sein, der Schreibrechte auf die Queue hat, oder von einem Kunden, der über ConSol CM.Track Kommentare hinzufügen kann. Oder es ist eine E-Mail eingegangen.
Abbildung 90: ConSol CM Process Designer - Event-Trigger mit folgenden Aktivitäten
Abbildung 91: ConSol CM Process Designer - Eigenschaften eines Event-Triggers (1)
return (workflowApi.getCurrentEngineer() == ticket.getEngineer())
Code-Beispiel 9: Code des Skripts des Entscheidungsknotens
Abbildung 92: ConSol CM Web Client- Mit neuem Overlay gekennzeichnetes Ticket
Dieses Beispiel stammt aus einer ITIL-Servicedesk-Umgebung. Nach den ITIL-Standards wird die Ticketpriorität anhand von zwei Werten berechnet: Auswirkung und Dringlichkeit. Das bedeutet, dass es im Ticket zwei Felder gibt, die vom Bearbeiter geändert werden können, und die Priorität automatisch aus diesen beiden Werten berechnet wird. Die Priorität kann das als Ticketfarbe oder als schreibgeschützte Liste (oder beides) angezeigt werden.
Dieses Prinzip erfordert eine Neuberechnung der Priorität, wenn mindestens eines der beiden Felder (Auswirkung/Dringlichkeit) geändert wurde. Dazu wird ein Event-Trigger mit einer nachfolgenden Aktivität, in der die Neuberechnung durchgeführt wird, erstellt.
Abbildung 93: ConSol CM Process Designer - Event-Trigger mit nachfolgender automatischer Aktivität
Abbildung 94: ConSol CM Process Designer - Eigenschaften eines Event-Triggers (2)
Abbildung 95: ConSol CM Process Designer - Eigenschaft "Benutzerdefiniertes Feld" eines Event-Triggers (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-Beispiel 10: Code der automatischen Aktivität zur Neuberechnung der Priorität
Dies ist ein Beispiel aus einem Versand- und Auslieferungsprozess. Es werden neue Komponenten (z. B. Hardware) bestellt. Das Ticket wartet im Bereich Bestellung: Auf Lieferung warten. Wenn die Lieferung eingetroffen ist, erfasst ein anderes Team die Lieferung und setzt den Tag Ware eingegangen. Diese Änderung der Ticketdaten (Ware eingegangen von false in true) wird von einem Event-Trigger erfasst, der den Wert des entsprechenden Boolean-Felds (der Checkbox) überwacht. Nachdem der Event-Trigger gefeuert hat, wird die Checkbox (im Entscheidungsknoten) überprüft, und wenn der Wert auf true gesetzt ist, wird das Ticket in den nächsten Bereich Lieferung Komponenten geschoben. Die Bearbeiter, die für die Lieferung zuständig sind, sehen das Ticket jetzt in ihrer Sicht Für Auslieferung bereite Komponenten und können die Lieferung über Alle Komponenten geliefert bestätigen, wenn sie fertig sind.
Abbildung 96: ConSol CM Process Designer - Workflow für Anwendungsfall 3
Wenn ein Event-Trigger feuert, dann hat sich im Ticket etwas geändert. Was sich geändert hat, können Sie in einem Report festhalten. Das Objekt, das die benötigten Informationen enthält, ist ein Objekt der Klasse TicketChanges.
Das folgende Beispiel zeigt, wie Sie die Änderung der Deadline in einem Aufgabenticket für das Reporting erfassen können. Wenn die Deadline sich ändert und das Ticket aktuell einem Bearbeiter zugewiesen ist, soll dieser Bearbeiter per E-Mail darüber informiert werden, dass sich das Datum geändert hat.
Abbildung 97: Event-Trigger mit verknüpfter automatischer Aktivität. Im Beispiel überwacht der Trigger, ob sich das Benutzerdefinierte Feld "Deadline" im Ticket ändert (nicht sichtbar).
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-Beispiel 11: Senden einer E-Mail an den aktuellen Bearbeiter des Tickets, wenn sich das Feld "Deadline" im Ticket geändert hat (Daten nicht formatiert)
Siehe Abschnitt Vermeiden von sich selbst auslösenden Event-Triggern.