Diese Dokumentation beschreibt, wie Sie mithilfe der Hintergrund-Anwendung Ereignisse auslösen Workflow-Ereignisse für ausgewählte Instanzen eines Business Objects in einer OLTP-Datenbank auslösen können.
Wie sich Aktivitätsdefinitionen für die ausgelösten Ereignisse registrieren können, um daraus Aktivitäten zu erzeugen, lesen Sie in der Dokumentation Aktivitätsdefinitionen.
Begriffsbestimmung
- Aktivitätsdefinition – Eine Aktivitätsdefinition ist die Vorlage für die aus ihr erzeugten Aktivitäten. Ist eine Aktivitätsdefinition aktiviert, dann erzeugt die Workflow-Engine beim Eintreten des registrierten Ereignisses eine neue Aktivität, sofern die Übergangsbedingung erfüllt ist. Aktivitätsdefinitionen sind unabhängig von der OLTP-Datenbank und dem System, in dem sie erfasst wurden, da sie weder System- noch OLTP-spezifische Daten enthalten. Aktivitätsdefinitionen werden in der Repository-Datenbank gespeichert.
- Ereignisse – Ereignisse bilden die Basis für das Erzeugen von Aktivitäten aus Aktivitätsdefinitionen im Workflow-Management. Ereignisse können ausgelöst werden aufgrund von Datenänderungen durch das System, von einer Anwendung oder durch eine Benutzeraktion. Ereignisse enthalten Parameter, die das Ereignis beschreiben. Um beim Eintreten eines Ereignisses eine Aktivität zu erzeugen, muss sich eine aktivierte Aktivitätsdefinition für dieses Ereignis registriert haben und die Übergangsbedingung muss erfüllt sein.
- Hintergrund-Anwendung – Eine Hintergrund-Anwendung ist eine Anwendung, die ohne Interaktion mit einem Benutzer ausgeführt wird. Sie kann entweder durch einen Verarbeitungsauftrag, durch einen CORBA-Aufruf oder durch eine andere Anwendung geöffnet werden.
- Verarbeitungsauftrag – Ein Verarbeitungsauftrag umfasst die notwendigen Informationen für die verzögerte Ausführung einer Hintergrund-Anwendung durch eine Verarbeitungs-Warteschlange.
Beschreibung
Die Hintergrund-Anwendung Ereignisse auslösen löst das Ereignis com.cisag.pgm.workflow.InstanceEvent
(Durch Hintergrundanwendung Ereignisse auslösen ausgelöstes Ereignis) für alle durch eine OQL-Anweisung ausgewählten Business-Object-Instanzen aus. Die Hintergrund-Anwendung kann mithilfe eines Verarbeitungsauftrags einmalig oder regelmäßig ausgeführt werden. Mithilfe von Aktivitätsdefinitionen, die sich für das ausgelöste Ereignis registriert haben, können Aktivitäten erzeugt werden.
Parameter der Hintergrundanwendung
Die Hintergrund-Anwendung hat folgende Parameter:
Parameter | Erläuterung |
Identifikation | Wählen Sie eine Identifikation, um die von diesem Verarbeitungsauftrag ausgelösten Ereignisse in der Übergangsbedingung einer Aktivitätsdefinition zu identifizieren und von ausgelösten Ereignissen anderer Verarbeitungsaufträge zu unterscheiden. |
Business Object | Wählen Sie das Business Object aus, für das die Ereignisse ausgelöst werden sollen. Das Business Object muss in der OLTP-Datenbank gespeichert sein. Ereignisse für Business Objects in der Repository-Datenbank können nicht ausgelöst werden. |
SELECT FROM … o WHERE | Geben Sie ein OQL-Fragment für die WHERE-Klausel einer OQL-Anweisung ein. Optional können Sie eine anschließende ORDER BY-Klausel eingeben, um die Reihenfolge der ausgelösten Ereignisse zu definieren. Das Business Object wird mit dem Alias „o“ identifiziert.
Mit Hilfe der WHERE-Klausel können Sie die Instanzen einschränken, für die Ereignisse ausgelöst werden. Wenn Sie eine Einschränkung in der WHERE-Klausel nicht ausdrücken können, müssen Sie diese in der Übergangsbedingung in der Aktivitätsdefinition umsetzen. Beachten Sie dabei, dass jedes Ereignis vom Application-Server verarbeitet werden muss und somit etwas Zeit kostet. Schränken Sie daher die Instanzen vorzugsweise durch die WHERE-Klausel ein. Weitere Informationen zu OQL-Anweisungen finden Sie in der Dokumentation OQL-Syntax im Abschnitt Einfache Abfrage über getObjectIterator. |
Parameter des ausgelösten Ereignisses
Das Ereignis com.cisag.pgm.workflow.InstanceEvent
hat folgende Parameter:
Parameter | Erläuterung |
identification |
Mithilfe der Identifikation im Parameter identification können Sie Ereignisse, die von unterschiedlichen Verarbeitungsaufträgen ausgelöst wurden, in der Aktivitätsdefinition voneinander unterscheiden. Sie können die Identifikation des Ereignisses beim Erfassen des Verarbeitungsauftrags frei wählen. Die Identifikation darf maximal 25 Zeichen umfassen. |
objectInstance |
Mithilfe des Parameters objectInstance können Sie das Business-Object in der Aktivitätsdefinition auswerten, beispielsweise in der Übergangsbedingung oder in den Deklarationen.
Ist in der Aktivitätsdefinition die Skriptsprache System-Skriptsprache eingestellt, dann müssen Sie die Funktion Beispiel cast(CisObject( com.cisag.app.general.obj.Partner), parameters.objectInstance):worker |
objectName |
Der technische Name des Business Objects im Parameter objectName ist ein zusätzliches Unterscheidungskriterium, falls die Identifikation im Parameter identification nicht eindeutig ist. |
Beispiel
Der Bearbeiter einer noch nicht erledigten Supportanfrage der Art REQ soll benachrichtigt werden, wenn die Supportanfrage seit mindestens sieben Tagen unverändert im Status Informationen erwünscht auf demselben Mitarbeiter steht.
Zu diesem Zweck erfassen Sie eine Prozessdefinition und registrieren Sie auf dem Karteireiter Ereignisse der Aktivitätsdefinition des Startknotens das programmierte Ereignis com.cisag.pgm.workflow.InstanceEvent
. Wenn für die Aktivitätsdefinition die Skriptsprache System-Skriptsprache eingestellt ist, dann geben Sie folgende Übergangsbedingung ein:
parameters.identification = "INFORMATION_REQUIRED" AND days(cast(CisObject(com.cisag.app.internal.obj.SupportRequest), parameters.objectInstance):updateInfo.updateTime, now()) > 7
In der Übergangsbedingung wird zunächst die Identifikation geprüft. Danach wird geprüft, ob das letzte Änderungsdatum der Supportanfrage älter als sieben Tage ist. Diese Bedingung reicht aus, um zu ermitteln, ob die Supportanfrage seit mindestens sieben Tagen bei demselben Bearbeiter auf Informationen wartet, denn bei jedem Statusänderung und Bearbeiterwechsel wird auch das Attribut updateInfo.updateTime
geändert.
Danach öffnen Sie die Hintergrund-Anwendung Ereignisse auslösen und erfassen einen Verarbeitungsauftrag, der für alle Supportanfragen im Status Informationen erwünscht (numerische ID: 15) ein Ereignis auslöst:
Parameter | Wert |
Identifikation | INFORMATION_REQUIRED |
Business Object | com.cisag.app.internal.obj.SupportRequest |
SELECT FROM … o WHERE |
o:orderNumber like 'REQ-%' AND o:status = 15 |
Wenn Sie die Hintergrund-Anwendung als Serie ausführen, werden Aktivitäten gemäß dem gewählten Serienmuster erzeugt.
Um die Anzahl der ausgelösten Ereignisse zu minimieren und somit unnötige Last zu vermeiden, sollten Sie die Übergangsbedingungen möglichst gleich in der OQL-Anweisung prüfen. Mit der folgenden OQL-Anweisung müssten Sie z. B. nur die Identifikation in der Übergangsbedingung prüfen:
o:"type" IN ( SELECT SRT:"guid" FROM com.cisag.app.internal.obj.SupportRequestType SRT WHERE SRT:"code" = 'REQ') AND o:"status" IN (15) AND o:"updateInfo.updateTime" < SYSTEMTIME - (toTimeStamp('GMT', 2017,1,8,0,0,0,0) - toTimeStamp('GMT', 2017,1,1,0,0,0,0)) ORDER BY o:"orderNumber" ASC