Zwischenereignisse
Grundlagen
Zwischenereignisse sind Wartezustände im Prozess, die nicht auf eine Benutzerinteraktion warten, sondern auf Ereignisse im CRM-System.
Icon | Aktion |
|---|---|
Eingehendes Nachrichten-Zwischenereignis | |
Ausgehendes Nachrichten-Zwischenereignis | |
Zeitliches Zwischenereignis | |
Nicht unterbrechendes zeitliches Zwischenereignis | |
Transaktionsunterbrechendes Zwischenereignis |
Eingehendes Nachrichten-Zwischenereignis
E-Mail-Eingang
Wartet der Prozess auf einen E-Mail-Import, so muss diese Mail besonderen Kriterien entsprechen, um den Prozess fortzusetzen. Diese Kriterien sind:
Kennungsschema des Betreffs: Der Aufbau der Kennung, bestehend aus festen Texten und Ziffernfolgen mit definierter Länge, die im Betreff enthalten sein müssen.
Kennung des Prozesses: Wählen Sie eine Variable aus, die zur Laufzeit die Kennung des Prozesses enthält. Die Kennung muss im Betreff der E-Mail enthalten sein, um diesen Prozess fortzusetzen, wie z.B. eine Ticketnummer oder Vertragsnummer.
Sender-Adresse (optional): Die E-Mail-Adresse des Senders. Wird hier keine Variable gesetzt, so wird die Sender-Adresse beim Import nicht geprüft.
Empfänger-Adresse (optional): Die E-Mail-Adresse eines der Empfänger. Wird hier keine Variable gesetzt, so werden die Empfänger-Adressen beim Import nicht geprüft.
Für das Kennungsschema des Betreffs können Sie feste Texte und Zahlen über die Schalter hinzufügen. Für die Kennung TICKET004711 müssen z. B. der Text TICKET und eine Zahl mit 6 Ziffern (NUMBER6) dem Schema hinzugefügt werden.
Wurde beim E-Mail-Import eine E-Mail eindeutig dem Prozess zugeordnet, so wird der Prozess weitergeführt und die importierte Aktivität als Variable container mitgegeben. Werden mehrere Prozesse eindeutig zur E-Mail identifiziert, so werden diese nacheinander fortgesetzt.
Beim Fortsetzen des Prozesses stehen die folgenden Variablen im Prozess analog zum Start-Ereignis E-Mail-Import zur Verfügung:
eventName:
ActivityImportEventcontainer: Der aus dem Mailimport generierte Aktivität -Datensatz
NewMail:
truefür einen neuen Datensatz,falsefür die Aktualisierung.Sender: Die Email-Adresse des Senders.
Recipients: Eine Liste von Email-Adressen der Empfänger.
Webservice
Ein Prozess kann nicht nur Webservice aufrufen oder durch einen Webservice gestartet werden. Das eingehende Nachrichtenereignis erlaubt es nun, den Prozess über Webservices weiterzuführen.

Beispielhafter Ablauf eines Prozess mit Webservice
Im Aufruf-Skript wird ein externer Webservice aufgerufen, um z.B. eine externe Berechnung durchzuführen. Die Berechnung kann aber erst nach einiger Zeit abgeschlossen werden, so dass ein Ergebnis nicht in der Webservice-Antwort zur Verfügung steht.
Die aktuelle Instanz-ID wird dem externen Programm über einen Parameter mitgeteilt. Mit dieser Instanz-ID kann das externe Programm später das Ergebnis über einen separaten Webservice-Aufruf dem Prozess mitteilen und ihn dadurch weiterführen.
Theoretisch ist es denkbar das eigene System über den Web Service aufzurufen und eigene Prozess hierüber weiterzuführen. Dieser Ansatz ist aber kein gutes Prozess-Design und kann an der Änderung der Netzwerkumgebung zu Laufzeitfehlern bei der Ausführung führen.
Im eingehenden Nachrichtenereignis wird der Typ Webservice und die benötigten Eingangsparameter definiert. Fehlt im Aufruf einer dieser Parameter, kann der Prozess nicht weitergeführt werden. Ebenso ist möglich Variablen des Prozesses als Ausgabeparameter im Webservice-Ergebnis zurück zu geben.
Der Webservice-Aufruf des externen Programms muss nun die Prozessinstanz-ID sowie die zwei in unserem Beispiel benötigten Eingangsparameter an das CRM übermitteln, damit der Prozess weitergeführt werden kann. Die Aufrufmethode resumeProcess ist parallel zu startProcess unter der URL http://[HOST]:[PORT]/soap/ProcessWebService?wsdl aufrufbar. Das XML-Schema beschreibt die Aufrufstruktur.
Der Prozess wird nun regulär weitergeführt und die Folgeschritte mit den übergebenen Parametern ausgeführt.
Das Ergebnis des Aufrufs sieht wie folgt aus:
Fehlt ein Aufrufparameter oder ist die angegebene ExecutionID ungültig, so bekommt der Webservice-Aufrufer eine SOAP-Fehlermeldung.
Zeitliches Zwischenereignis
Für die Konfiguration des zeitlichen Zwischenereignisses kann eine relative Zeitangabe hinterlegt werden.
Alternativ zur relativen Zeitdefinition kann eine Datumsvariable ausgewählt werden. Die Variable enthält den Datumswert als Zeichenkette im ISO 6801 Format enthalten: yyyy-MM-dd'T'HH:mm:ss. Dieses Format kann mittels der Skriptmethode DateUtils.convertISO(Date date) aus einem Datumswert erzeugt werden.
Beispiel-Code:
Date date = DateUtils.parseDate("08.10.2014T13:45","dd.MM.yyyy'T'HH:mm") //DateUtils.NOW + 1
String dateISO = DateUtils.convertISO(date)
ProcessUtils.setVariable("date", dateISO)
Ereignisbasierte Verzweigung
Das Warten auf den E-Maileingang unter Berücksichtigung der eingestellten Parameter, kann dazu führen, dass der Prozess sehr lange nicht weitergeführt wird. Für diesen Fall sollten Sie sicherstellen, dass der Prozess in einem alternativen Zweig weiterlaufen und evtl. die Anfrage an diese Mail noch einmal stellen kann. Daher sollten Sie parallel zum Nachrichten-Ereignis eine zeitliches Zwischenereignis in das Modell einfügen.

Beispielhafte ereignisbasierte Verzweigung
Der gezeigte Prozess wartet maximal 5 Tage auf den Mail-Eingang und setzt dann den Prozess automatisch fort. Eine danach eingehende E-Mail wird nun nicht mehr diesem Prozess zugeordnet.
Aktuell werden für die Zeitangabe Kalenderzeiten berücksichtigt, es erfolgt also keine gesonderte Behandlung von Arbeitszeiten, Wochenenden oder Feiertagen.
Tritt in nachfolgenden Aktionen zum zeitlichen Zwischenereignis ein Fehler auf, so versucht die Prozessausführungen die Ausführung noch 2 Mal zu Wiederholen. Diese Einstellung ist durch die Bibliothek Activiti fest vorgegeben.
Angehängtes Zwischenereignis
Das zeitliche Zwischenereignis kann per Drag and Drop an Benutzer-Aktionen oder Teilprozesse zur zeitlichen Eskalation angehängt werden.

Beispielhaftes angehängtes Zwischenereignis
Sie können genau ein Ereignis anzuheften. Ob die Aktion dadurch abgebrochen wird oder die Aktionen parallel zur Benutzer-Aktion stattfinden, kann über die Option Aktion unterbrechen eingestellt werden.
Der nicht unterbrechende Zustand dieser Option wird im Modell durch gestrichelte Linien dargestellt.
Ausgehendes Nachrichten-Zwischenereignis
Über ein ausgehendes Zwischenereignis können Aktionen auf den Client ohne Benutzerinteraktion ausgeführt werden. Diese Aktionen werden nur ausgeführt, wenn der aktuelle Benutzer des Prozesses im Client auch angemeldet ist.
Aktuell werden vier Aktionstypen angeboten:
Aktualisieren: Lädt einen Datensatz (nur Hauptbereich) im Client neu, falls dieser dort geöffnet ist.
Öffnen: Öffnet einen Datensatz in einer neuen Ebene, z.B. für die manuelle Nachbearbeitung für die Angebotserstellung.
Aktivitätenabgleich: Die Entität ist fest auf "Aktivitäten" konfiguriert.
Die über den Primärschlüssel definierte Aktivität wird dann mit der Groupware abgeglichen, sofern sie für einen Abgleich in Frage kommt.Skript ausführen: Führt ein Maskenskript im Client aus.
Für die ersten beiden Aktionstypen ist jeweils der Entitätsname aus dem Datenmodell auszuwählen und eine Variable, die den Primärschlüssel des Datensatzes enthält.