Mit der Einführung eines Work­flow-Managements sind Ziele wie gesteigerte Effizienz, Kosteneinspa­rungen, verbesserte Arbeitsabläufe und Zu­sammenarbeit verbunden. Besonders effizient kann ein automati­sierter Workflow-Prozess dort einge­setzt wer­den, wo Arbeitsabläufe immer wieder durchlaufen werden müssen.

Der Einstieg in das Thema Workflow-Management ist mit den angebotenen Funktionen im Workflow-Management fast stufenlos möglich. Praktisch ohne Einrichtungsauf­wand und ohne großen Schulungsaufwand lassen sich Aktivitäten erfassen und bearbeiten. Die Einführung und Nutzung der kom­plexeren prozess­orientierten und ereignis­gesteuerten Work­flow-Funktionen wird durch vorgefertigte und konfigurierbare Workflow-Vorlagen (Tem­plates) wesentlich erleichtert, die ohne tiefes technischen Wissen übernommen und aktiviert werden können.

Das Workflow-Management wurde mit den systemeigenen Bausteinen entwickelt und ist somit ein Teil des ERP-Systems. Deshalb können die Anwendungen des Frameworks Workflow-Management ebenso intuitiv bedient werden, wie andere Anwendungen. Darüber hinaus werden für das Workflow-Management die grundlegenden Eigenschaften und Funktionen des Systems genutzt, wie z. B. Berechtigungen, die Aufbauorganisation und das Dokumenten-Management. Umgekehrt wird auch der Workflow selbst an vielen Stellen des ERP-Systems verwendet, so z. B. im Beziehungs-Management oder der Hintergrundverarbeitung. Durch diese überschneidungs-freie Architektur der einzelnen Komponenten sind sowohl der Schulungs- als auch der Administrationsaufwand gering. Die nahtlose Integration ermöglicht jeder Anwendung den Zugriff auf die Funktionen des Workflow-Managements, ohne dass eine komplexe Schnittstellenprogrammierung notwendig ist.

Die Workflow-Engine ist die zentrale Komponente im Workflows-Management. Die Workflow-Engine erzeugt beim Eintreten bestimmter Ereignisse Aktivitäten und ordnet den jeweiligen Bearbeitern Aufgaben zu. Die Workflow-Engine überwacht und koordiniert die Verarbeitung der Aufgaben. Bei Zeitüberschreitungen kann die Workflow-Engine Folgeaktionen einleiten, wie z. B. das Erinnern an verspätete Aufgaben, das Eskalieren der verspäteten Aufgaben an einen Vorgesetzten oder die Benachrichtigung des Prozessverantwortlichen über die Verspätung.

In diesem Dokument werden das Datenmodell des Workflow-Managements und seiner Komponente sowie technische Aspekte des Erzeugens von Aktivitäten und der Verarbeitung von Aufgaben beschrieben. Ergänzend werden die Konfiguration und Anpassung der E-Mail-Benachrichtigung durch die Workflow-Engine sowie weitere Konfigurationseinstellungen beschrieben.

Die im Workflow eingesetzte System-Skriptsprache und ihre Ele­men­te (Terme, Bedingungen und Befehle) werden in der Dokumentation Einführung: System-Skriptsprache erläutert. Der Aufbau der einzelnen Workflow-Anwendungen und die Vorgehensweisen für den Umgang damit werden in den Dokumentationen zu den Anwendun­gen beschrieben, z. B. in der Dokumentation Aktivitäten. Wie Prozessdefinitionen und Aktivitätsdefinitionen abgebildet sind und wie die gleichnamigen Anwendungen aufgebaut sind, erfahren Sie in den Dokumentationen Prozessdefinitionen und Aktivitätsdefinitionen. Eine ausführliche Beschreibung der Verarbeitung von Workflow-Aufgaben finden Sie im Dokument Einführung: Workflow-Management und im Bedienungsleitfaden.

Zielgruppe

Die Zielgruppe dieses Dokuments besteht aus Entwicklern, technischen Beratern und Workflow-Administratoren, die das Workflow-Management bei Kunden einrichten oder administrieren.

Für dieses Dokument wird das Verständnis des für den Benutzer sichtbaren Funktionsumfangs des Workflow-Managements vorausgesetzt.

Begriffsbestimmung

• Aktivitäten – Eine Aktivität beschreibt eine Tätigkeit, die durch einen oder mehrere Benutzer bearbeitet werden kann. Die Bearbeitung der Tätigkeit durch die Benutzer erfolgt aufgrund einer oder mehrerer Aufgaben, in denen die entsprechende Tätigkeit für jeden Benutzer beschrieben ist. Eine Aktivität bildet also eine Klammer um die daraus entstandenen Aufgaben und enthält erforderliche Informationen über die Aufgaben. Aktivitäten entstehen im Rahmen des Workflow-Managements oder des Beziehungs-Managements und sind Teil des Workflows.
• 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.
• Aufgabe – Eine Aufgabe im Workflow-Management stellt die Zuordnung einer aus einer Aktivität resultierenden Tätigkeit zu einem Benutzer dar. Jede Aufgabe hat einen vorgesehenen Bearbeitungszeitraum, der von der übergeordneten Aktivität bestimmt wird, sowie einen Aufgabenstatus. Beim ersten Wechsel in einen neuen Status wird der Zeitpunkt des Wechsels dokumentiert.
• Aufgabenstatus – Der Aufgabenstatus beschreibt den Zustand der Aufgabe. Der Ausgabenstatus ist abhängig vom aktuellen Zeitpunkt und dem Aufgabenstatus anderer Aufgaben der übergeordneten Aktivität. Beim ersten Wechsel in einen neuen Status wird der Zeitpunkt des Wechsels dokumentiert.
• 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.
• Exportpräfix – Jedes Comarch-ERP-Enterprise-System besitzt ein Exportpräfix. Das Exportpräfix ist beim Transport von Softwareaktualisierungen vom Entwicklungssystem bis hin zum Produktivsystem eindeutig. Im Workflow-Management entscheidet das Exportpräfix auch über die Verwendung einer Workflow-Definition. Nur Workflow-Definitionen mit dem gleichen Exportpräfix wie das des gewählten Systems dürfen verändert und aktiviert werden. Beim Erfassen von neuen Workflow-Definitionen erhält die neue Definition das Präfix des zum Zeitpunkt des Erfassens gewählten Systems.
• GUID – GUID ist die Abkürzung für Globally Unique Identifier und entspricht einem Global eindeutigen Bezeichner. Eine GUID ist eine 128-Bit Zahl, die nach dem Schema der Open Software Foundation (OSF) für verteilte Berechnungen (Distributed Computing Environment, DCE) berechnet wurde. Sie enthält u. a. die IP-Adresse der erzeugenden Rechner, eine Zeit-Komponente und eine Zufalls-Komponente. So können zwei unabhängige Rechner ohne Synchonisation immer unterschiedliche GUIDs berechnen. In Comarch ERP Enterprise werden GUIDs als Java-Byte-Arrays der Länge 16 repräsentiert und vor allem als kompakte Primär- und Fremdschlüssel in Business Objects verwendet.
• Prozess – Ein Prozess im Workflow-Management beschreibt die arbeitsteilige Ausführung eines betrieblichen Prozesses oder Teilprozesses auf Basis einer Prozessdefinition. Ein Prozess kann als Diagramm angezeigt werden, dessen Knoten die Aktivitäten und dessen Kanten den Kontrollfluss darstellen. Mithilfe der erzeugten Aktivitäten werden die einzelnen Prozessschritte bearbeitet. Der Abschluss eines Prozessschrittes kann die Bearbeitung anderer Prozessschritte auslösen. Ein Prozess hat einen festgelegten Bearbeitungszeitraum, einen Start und ein Ende.
• Prozessdefinition – Eine Prozessdefinition ist eine vollständige technische Beschreibung eines betrieblichen Prozesses oder Teilprozesses. Sie besteht aus Prozessschritten, die den Geschäftsprozess zeitlich und organisatorisch beschreiben. Eine Prozessdefinition wird als Diagramm modelliert, dessen Knoten die Aktivitätsdefinitionen und dessen Kanten den Kontrollfluss darstellen. Mithilfe der Prozessdefinition und der Aktivitätsdefinitionen werden die Eigenschaften der Prozesse und der Prozessschritte festgelegt. Prozessdefinitionen sind unabhängig von der OLTP-Datenbank und dem System, in dem sie erfasst wurden, da sie weder System- noch OLTP-spezifische Daten enthalten. Prozessdefinitionen werden in der Repository-Datenbank gespeichert.
• System-Skriptsprache – Terme, Bedingungen, Befehle und Deklarationen werden verwendet, um komplexe Zusammenhänge auszudrücken. Alle diese Ausdrücke sind Teil einer gemeinsamen Skriptsprache, die System-Skriptsprache genannt wird. Die Syntax der System-Skriptsprache lehnt sich an SQL, Pascal und Java an. Die System-Skriptsprache wird im Workflow-Management verwendet, um z. B. eine Vorbedingung oder Übergangsbedingung zu formulieren oder um Bearbeiter zu ermitteln, die nicht in einer Workflowrolle zusammengefasst sind.
• Workflowrolle – Workflowrollen sind eine Abstraktionsebene, um die vom Workflow-Management verwendete Ablauforganisation abzubilden. Workflowrollen sind unabhängig von der OLTP-Datenbank und dem System, in dem sie erfasst wurden, da sie weder System- noch OLTP-spezifische Daten enthalten. Workflowrollen werden in der Repository-Datenbank gespeichert. Einer Workflowrolle müssen Inhaber zugeordnet werden, damit diese sinnvoll verwendet werden kann. Inhaber können z. B. Benutzer, Personen, Stellen oder Organisationen sein. Die Zuordnung der Inhaber einer Workflowrolle ist datenbankspezifisch, weil bei der Zuordnung nur Objekte in dieser Datenbank benutzt werden können. In unterschiedlichen Datenbanken können einer Workflowrolle unterschiedliche Inhaber zugeordnet werden.

Architektur

Alle automatischen Statusänderungen von Aktivitäten und Aufgaben werden von der zentralen Workflow-Engine durchgeführt. Die Workflow-Engine wird in jedem System auf dem Message-Server ausgeführt. Auf jedem anderen Appli­cation-Server im System läuft nur die Ereignisbehandlung.

Der Scheduler für die Aktivitäten wird auf dem Message-Server ausgeführt. Er wird bei jeder neuen Aktivität sofort benachrichtigt. Der Scheduler ist für die Statusän­derungen beim Beginn und beim Ende des Bearbeitungszeitraums verantwort­lich. Dabei wird die vorhandene Kommunikation über die Sperrverwaltung genutzt, sodass kein zusätzlicher Kommunikationsaufwand entsteht. Durch die zentrale Verarbeitung der automatischen Statusänderungen wird die Konsistenz der Daten sichergestellt.

Ohne zusätzliche Netzwerkkommunikation für die Ereignisse kann die Ereignisbehandlung, die auf jedem Application-Server ausgeführt wird, direkt Aktivitäten erzeugen. Jeder Application-Server erzeugt also nur Aktivitäten für Ereignisse, die auch in diesem Application-Server ausgelöst wurden.

Jede einzelne OLTP-Datenbank läuft, ebenso wie die Repository-Datenbank, in einem eigenen Thread im Scheduler. Dadurch kann bei größeren Installationen der Durchsatz erhöht werden. Die Arbeitsliste des Schedulers kennt die jeweils anstehenden Aufgaben und wird bedingt durch die bereits beschriebene Archi­tektur sehr zeitnah aktualisiert. Im Allgemeinen werden Statusänderungen von Aktivitäten mit einer Verzögerung von wenigen Sekunden verarbeitet. Der Sche­duler greift erst dann auf die Datenbank zu, wenn die Arbeitsliste bis zum aktuellen Zeitpunkt abgearbeitet wurde. Durch dieses Verhalten werden eine kurze Reaktionszeit des Workflows und nur eine geringe Geschwindigkeits­ein­buße für das Gesamt­system gewährleistet.

Das andockbare Fenster Aufgaben suchen wird über die Cache-Syn­chronisation aktualisiert. Auf dem Message-Server ist das andockbare Fenster bis auf eine kurze Ver­zögerung aktuell. Auf allen anderen Application-Servern im System zeigt das andockbare Fenster neue Aktivitäten spätestens nach dem Cache-Synchronisierungs-Intervall an. Das andockbare Fenster Aufgaben suchen wird bei jeder Stan­dard-Symbolleisten-Aktion, wie beispielsweise Öffnen oder Speichern, sowie Workflow-Symbolleisten-Aktionen auto­ma­tisch aktualisiert.

Änderungen an aktiven Aktivitätsdefinitionen werden beim Speichern sofort und ohne Neustart des Systems aktiv. Spätestens nach dem Cache-Synchronisierungs-Intervall ist die Ereig­nis­behandlung aller Application-Server im System aktualisiert.

Der Scheduler kann auf einem anderen Application-Server als dem Message-Server gestartet werden. Dies wird jedoch für den Produktivbetrieb nicht empfohlen, da dies auf­grund der Cache-Synchronisierung zu unnötigen Verzögerungen bei der Abar­beitung von Aktivitäten führt. Ein Scheduler kann nur auf einem Application-Server betrieben werden. Damit ist ausgeschlossen, dass ein Scheduler auf mehr als einem Application-Server gleichzeitig ausgeführt wird.

Folgende Abbildung zeigt, wie die Workflow-Engine und die zugehörigen Komponenten beim Eintreten von Ereignissen Aktivitäten erzeugen.

Am Anfang steht das eingetretene Ereignis. Ein s. g. programmiertes Ereignis kann durch eine Anwendung ausgelöst sein. Ein Ereignis vom Typ Business Entity wird beim Einfügen, Ändern oder Löschen einer Business Object-Instanz in der Repository-Datenbank oder in einer OLTP-Datenbank durch den Persistenzdienst ausgelöst. Ein Ereignis vom Typ Benutzeraktion wird ausgelöst, wenn ein Benutzer einen Prozess über das Kontextmenü eines Business Entitys startet. Besitzt ein Ereignis einen Subtyp (z. B. Einfügen, Ändern oder Löschen beim Ereignistyp Business Entity), dann werden beim Eintreten des Ereignisses nur die Aktivitätsdefinitionen ausgewertet, welche sich für das Ereignis mit dem gleichen Subtyp registriert haben.

Ist die Übergangsbedingung erfüllt, dann erzeugt die Workflow-Engine eine Aktivität. Die Aktivität erhält ihre Merkmale wie z. B. Betreff, Priorität, Beginnzeitpunkt und geplanter Endzeitpunkt aus der Aktivitätsdefinition. Auch die Bearbeiter der Aktivität werden aus der Aktivitätsdefinition berechnet. Als Bearbeiter der Aktivität können z. B. eine Workflowrolle, eine Stelle, ein Mitarbeiter oder ein Ausdruck in der Aktivitätsdefinition ausgewählt sein. Für jeden Benutzer, der als Bearbeiter in Frage kommt, erzeugt die Workflow-Engine eine Aufgabe und ordnet diese der Aktivität zu. Die Aufgaben beziehen ihre wesentlichen Merkmale aus der Aktivität. Darüber hinaus besitzt die Aufgabe aufgabenspezifische Merkmale wie den Status und die tatsächlichen Beginn- und Endzeitpunkte.

Mithilfe des Schedulers koordiniert die Workflow-Engine die Verarbeitung der Aktivität und ihrer Aufgaben, führt deren Status fort, benachrichtigt die Bearbeiter beim Erreichen des geplanten Beginnzeitpunkts und leitet Folgeaktionen bei einer Zeitüberschreitung ein. Je nach Bearbeitungsmodus gilt die Aktivität als erledigt, wenn entweder die erste Aufgabe erledigt wird oder wenn alle zur Aktivität gehörenden Aufgaben erledigt sind.

Workflow-Objekte

Die für das Workflow-Management benötigten Daten lassen sich in folgende Grup­pen unterteilen:

• Die Prozessdefinitionen, Aktivitätsdefinitionen und Workflowrollen, die unter anderem zur Ereignisbehandlung dienen, sind unabhängig vom System und von den OLTP-Datenbanken. Sie sind in der Repository-Datenbank abgelegt und können mithilfe von Toolshell-Befehlen importiert und exportiert werden.
• Die in einem Kundensystem als Vorlage erfassten Prozessdefinitionen, Aktivitätsdefinitionen und Workflowrollen. Sie sind in der Repository-Datenbank abgelegt und lassen sich mithilfe von Softwareaktualisierungen z. B. von einem Testsystem in ein Produktivsystem transportieren.
• Den Prozessdefinitionen, Aktivitätsdefinitionen und Workflowrollen müssen konkrete Daten, wie beispielsweise einem Mitarbeiter und einem Benutzer, zugeordnet werden. Diese Zuordnung ist nicht mehr unabhängig vom System und von den OLTP-Datenbanken. Die kon­kreten Daten müssen in jedem System den Aktivitätsdefinitionen und Work­flowrollen zugeordnet werden.
• Durch Aktivitätsdefinitionen werden Aktivitäten und Aufgaben erzeugt und in derjenigen Datenbank abgelegt, in der das Ereignis ausgelöst wurde. Darüber hinaus können Benutzer auch s. g. manuell erfasste Aktivitäten erfassen. Mit diesem Datenbestand arbeitet der Benutzer, wenn er den Workflow nutzt und eine Workflow-Aufgabe bearbeitet.

Bei der Beschreibung des Datenmodells werden die technischen Namen der Business Objects verwendet. Workflow-Objekte liegen im Namensraum com.cisag.sys.workflow.obj. Workflow-Vorlagen liegen im Namensraum com.cisag.sys.repository.obj.

Aktivitätsdefinitionen

Die Aktivitätsdefinitionen verknüpfen Ereignisse mit der Erzeugung von neuen Aktivitäten. Aktivitätsdefinitionen können festlegen, ob beim Auftreten eines bestimm­ten Ereignisses eine Aktivität erzeugt werden soll und welche Merkmale diese Aktivität haben soll. Beim Auftreten eines Ereignisses prüft die Work­flow-Engine die Übergangsbedingungen derjenigen Aktivitätsdefinitionen, die auf das Ereignis reagieren. Aktivitätsdefinitionen, die auf einen anderen Subtyp als im ausgelösten Ereignis reagieren, werden dabei nicht berücksichtigt. Ist die Übergangsbedingung wahr, dann erzeugt die Workflow-Engine eine neue Aktivi­tät.

Alle für die neue Aktivität notwendigen Daten werden aus der Aktivitäts­defi­nition berechnet. Die Aktivitätsdefinition stellt somit die Vorlage für die aus ihr erzeug­ten Aktivitäten dar. Aktivitätsdefinitionen sind unabhängig von der OLTP-Datenbank und dem System, in dem sie erfasst wurden, da sie weder system­spezifische noch OLTP-spezifische Daten enthalten. Aktivitätsdefinitionen werden in der Repository-Datenbank abge­legt.

Nur aktivierte Aktivitätsdefinitionen können Aktivitäten erzeugen. Beim Aktivieren können bestimmte Eigenschaften, wie beispielsweise die Aktivitäts-Klassifikationen, datenbankspezifisch geändert werden. Da einer Workflowrolle auch datenbankspezifisch Inhaber zugeordnet werden, können zwei aus derselben Aktivitätsdefinition erzeugte Aktivitäten unterschiedliche Bearbeiter haben, wenn die Aktivitäten in unterschiedlichen Datenbanken erzeugt wurden.

Eine Aktivitätsdefinition muss in jeder Datenbank aktiviert werden, in der sie ver­wen­det werden soll. Damit können datenbankspezifisch (d. h. insbesondere auch OLTP-spezifisch) Ereignisse ausgewertet werden. Die zur Aktivierung not­wendigen Daten werden in der Datenbank gespeichert, in der die Aktivitätsdefi­ni­tion aktiviert wird. Damit ist möglich, OLTP-Datenbanken innerhalb eines Systems zu kopieren, ohne die Aktivierungen der Aktivitätsdefinitionen reorga­ni­sieren zu müssen. Verwenden Sie den Toolshell-Befehl dltwflacv, um Aktivierungen nach dem Kopieren einer Datenbank zu löschen.

Folgende Abbildung zeigt das Datenmodell der Aktivitätsdefinition. Alle Business Objects außer ActivityDefinitionExtension sind in der Repository-Datenbank abgelegt. Das Business Object ActivityDefinitionExtension repräsentiert die Aktivierung der Aktivitätsdefinition in einer spezifischen Datenbank und wird in derjenigen Datenbank abgelegt, für die die Aktivierung gilt. Im Business Object Transition sind das Ereignis, auf das die Aktivitätsdefinition reagiert, und die Übergangsbedingung abgelegt. Ist die Aktivitätsdefinition mit einer Prozessdefinition verknüpft, dann zeigt die Beziehung ProcessDefinition auf die Prozessdefinition.

• ActivityDefinition – Die Aktivitätsdefinition.
• Transition – Die Zuordnung eines Ereignisses zu der Aktivitäts­defi­nition.
• ActivityDefinitionParameter – Die Definition der Parameter und Rückgabewerte der Aktivitätsdefinition.
• ActionParameter – Die Übergabewerte für die mit der Aktivitätsdefinition verknüpfte Anwendung.
• ActivityDefinitionExtension – Die Daten zur Datenbank-spezifischen Aktivierung der Aktivitätsdefinition.
• ProcessDefinition – Stellt die Aktivitätsdefinition einen Knoten in einer Prozessdefinition dar, dann umfasst das Datenmodell auch eine Verknüpfung zur Prozessdefinition.

Wie in der Abbildung zu erkennen, besteht die Datenbank-spezifische Aktivierung ActivityDefinitionExtension auch aus den Aktivitäts-Klassifikationen 1‑5. Diese Klassifikationen können mithilfe der Anwendung Aktivitätsdefinitionen aktivieren zugeordnet werden. Eine Zuordnung ist auch für nicht aktivierte Aktivitätsdefinition, die z. B. Aktionsknoten einer Prozessdefinition darstellen, möglich.

Aktivitäten und Aufgaben

Die Aktivitäten mit ihren Aufgaben sind die Objekte, die für einen Benutzer, der eine Aktivität bzw. eine Aufgabe bearbeitet, sicht­bar werden. Aktivitäten können direkt durch den Benutzer oder durch eine Anwendung (wie z. B. im Beziehungs-Management) erfasst werden (s. g. manuell erfasste Aktivitäten). Aktivitäten können auch durch eine Serienaktivität, eine Prozessdefinition oder durch die Ereignisbehandlung der Workflow-Engine erzeugt werden.

Ist die Aktivitätsdefinition nicht mit einer Prozessdefinition verknüpft, dann unterscheidet die Workflow-Engine zwischen folgenden Typen von Aktivi­täten (s. g. Standalone-Aktivitäten):

• Einzelaktivitäten
• Serienvorlagen
• Serienaktivitäten

Eine Einzelaktivität bildet eine einzelne Tätigkeit für einen oder mehrere Bearbeiter ab. Eine Serienvorlage erzeugt zu festge­legten Zeitpunkten Serienaktivitäten. Der Unter­schied zwischen Serien- und Ein­zel­aktivität liegt in der Beziehung zu der Serienaktivität, die bei der Einzelaktivität nicht vorhanden ist.

Der Ausgangsstatus einer Serienvorlage ist Geplant. Beim Erreichen des Bearbeitungszeitpunkts wechselt sie in den Status Zu bearbeiten und die Workflow-Engine nimmt die Serienvorlage in Bearbeitung. Dabei erzeugt die Workflow-Engine eine neue Serienaktivität aus der Serienvorlage. Die für die Serienaktivität benötigten Merkmale werden dabei aus der Serienvorlage kopiert, ohne das die Deklarationen erneut ausgewertet werden.

Eine Aktivitätsdefinition, die nicht mit einer Prozessdefinition verknüpft ist, kann die Aktivitätstypen E-Mail-Nachricht und Funktionsaufruf verwenden.

Eine Aktivitätsdefinition vom Typ E-Mail-Nachricht versendet eine E-Mail-Nachricht an einen oder mehrere Empfänger, ohne dabei eine Aktivität zu erzeugen. Da die Aktivität auch den Nachweis über die Verarbeitung und somit über die versendete E-Mail darstellt, wird empfohlen, eine Prozessdefinition mit einem E-Mail-Knoten dann zu verwenden, wenn ein Nachweis erforderlich ist.

Eine Aktivitätsdefinition vom Typ Funktionsaufruf gibt ein mithilfe der Deklarationen berechnetes Ergebnis zurück, ohne eine Aktivität zu erzeugen. Sie können z. B. dazu verwendet werden, um Java-Methoden auch in Prozessdefinitionen auswerten zu können, die die System-Skriptsprache verwenden. Beispielsweise kann eine Aktivitätsdefinition, welche die System-Skriptsprache verwendet, eine Aktivitätsdefinition vom Typ Funktionsaufruf mithilfe des Befehls callaufrufen. Verwendet der Funktionsaufruf JavaScript, dann kann dieser z. B. eine Java-Methode aufrufen, die die aktuelle Bestandsmenge eines Artikels auf einem Lagerort berechnet, und anschließend das Ergebnis der aufrufenden Aktivitätsdefinition zur Verfügung stellen.

Ist eine Aktivitätsdefinition ein Knoten in einer Prozessdefinition, dann unterscheidet die Workflow-Engine grundsätzlich auch zwischen

• Aktionsknoten und
• Ereignisknoten.

Ein Aktionsknoten ist ein Prozessschritt, der eine Tätigkeit für einen oder mehrere Bearbeiter darstellt. Aktivitäten, die von einem Aktionsknoten erzeugt wurden, können von einem oder mehreren Benutzern, von einem Verarbeitungsauftrag oder vom System bearbeitet werden. Ein Ereignisknoten ist ein Prozessschritt, der ein prozessrelevantes Ereignis statt einer Tätigkeit darstellt. Zu den Ereignisknoten zählen z. B. das Startereignis, das Endereignis und das Fehlerereignis. Aktivitäten, die von einem Ereignisknoten erzeugt wurden, werden vom System bearbeitet.

Die Aktionsknoten werden in den folgenden Typen unterteilt, um eine bestimmte Tätigkeit abzubilden, wie z. B. eine Entscheidung zu treffen oder eine E-Mail-Nachricht zu versenden:

• Benutzerknoten
• Serviceknoten
• Skriptknoten
• E-Mail-Knoten
• Interaktiver E-Mail-Knoten
• Webservice-Knoten
• Auswahlknoten
• Entscheidungsknoten
• Präsentationsknoten

Die Ereignisknoten werden in den folgenden Typen unterteilt:

• Startereignis
• Fehlerereignis
• Endereignis
• Zwischenereignis
• Nicht-terminierendes Endereignis
• Timer-Ereignis

Alle Aktivitäten können zu beliebigen Business Entitys eine Verknüpfung besit­zen. Diese Verknüpfungen werden einerseits verwendet, um die Aktivität zu doku­mentieren, und andererseits, um zu ermitteln, mit welcher Anwendung die Akti­vität bzw. die Aufgabe bearbeitet werden kann. Einschränkend gilt, dass die Verknüpfungen in der gleichen Datenbank vorhanden sein müs­sen.

Aktivitäten besitzen Aufgaben. Eine Aufgabe ist immer einem Bearbeiter zugeordnet. Je nach Aktivitätstyp kann der Bearbeiter das System, ein Verarbeitungsauftrag oder ein oder mehrere Benutzer sein. Mit der Aufgabe ist auch gespeichert, wer sie bearbeiten soll. Für eine Aktivität, die von Benutzern bearbeitet wird, existieren so viele Aufgaben wie die Aktivität Bearbeiter hat, d. h. für jeden Bearbeiter wird eine eigene Aufgabe erzeugt.

Aktivitäten und Aufgaben können sowohl in der OLTP-Datenbank als auch in der Repository-Datenbank gespeichert werden. Aktivitäten können nicht in der Konfigurations- oder OLAP-Datenbank gespeichert werden. Wenn eine Aktivität in der OLTP-Datenbank gespeichert ist, so bezieht sie sich auf eine Tätig­keit, die spezifisch für diese OLTP-Datenbank ist. Aktivitäten in der Repository-Datenbank beziehen sich auf Tätigkeiten, die spezifisch für die Repository-Datenbank bzw. OLTP-übergreifend sind.

Da Aktivitäten nur mit Objekten in der gleichen Datenbank verknüpft werden können, kann eine Aktivität nicht mit einem Konfigurations- oder OLAP-Objekt verknüpft werden.

Folgende Abbildung zeigt das Datenmodell der Aktivität und der mit der Aktivität verknüpften Aufgabe (Workitem).

• Activity – Alle Aktivitäten werden in einem Business Object gespeichert. Aktivitätsdefinitionen vom Typ E-Mail-Nachricht erzeugen keine Aktivität.
• Workitem – Die Aufgaben der Aktivität. Jede Aufgabe, die nicht vom System oder einem Verarbeitungsauftrag bearbeitet wird, ist genau ei­nem Benutzer zugeordnet. Aktivitäten vom Typ Serienvorlage besitzen keine Aufgaben.
• ActivityAttachment – Verknüpfung zwischen einem beliebigen Business Entity und der Aktivität. Das Business Entity und die Aktivität müssen in derselben Datenbank gespeichert sein.
• ActivityParameters – Durch Aktivitätsdefinitionen erstellte Aktivitäten können Parameter besitzen, die zur Auswertung der Bedingungen benötigt werden. Alle Parameter werden als Blob in einem Datensatz gespeichert.
• Process – Stellt die Aktivität einen Knoten in einem Prozess dar, dann umfasst das Datenmodell auch eine Verknüpfung zum Prozess.

Erledigte Aktivitäten archivieren vergangene Tätigkeiten. Zu diesem Zweck enthält eine Aktivität die Zeitpunkte, an denen der Status das erste Mal einen bestimmten Wert angenommen hat. Die mit der Aktivität verknüpften Aufgaben enthalten die für die Bearbeitung der Aufgabe relevanten Zeitpunkte. Mithilfe der erledigten Aktivitäten und deren Aufgaben kann somit nachvollzogen wer­den, welche Tätigkeit zu welchem Zeitpunkt bearbeitet wurde. Der Benutzer, dessen Aufgabe zum Erledigen der Aktivität geführt hat, wird im Attribut completeUserder Aktivität festgehalten. Dieser Wert steht bereits in der Funktion closein den Deklarationen zur Auswertung bereit.

Aktivitäten enthalten alle zur Verarbeitung notwendigen Informationen. Das bedeutet insbesondere für solche Aktivitäten, die durch Aktivitätsdefinitionen erzeugt wurden, dass eine Änderung der Aktivitätsdefinition keinen Einfluss auf vorhandene Aktivitäten hat. Die Aktivität enthält jedoch eine Referenz auf die Aktivitätsdefinition, die bei Abfragen und Auswertungen genutzt werden kann.

Da Aktivitä­ten eine wichtige Historie bilden, können diese nicht durch den Benutzer, son­dern nur mit einer besonderen Berechtigung und über die Reorganisation gelöscht werden.

Prozessdefinitionen

Eine Prozessdefinition verknüpft Aktivitätsdefinitionen, die zusammen einen Prozess darstellen. Eine Prozessdefinition wird ebenso wie eine Aktivi­täts­definition über ihre Identifikation und das Exportpräfix eindeutig identi­fi­ziert.

Die Aktivitätsdefinition des Startknotens legt fest, ob beim Auftreten eines bestimm­ten Ereignisses ein Prozess erzeugt werden soll und welche Merkmale dieser Prozess haben soll. Reagiert der Startknoten nicht auf einem Ereignis, dann kann der Prozess nur manuell gestartet werden. Zwischenereignisknoten können nicht zum Starten eines Prozesses verwendet werden. Beim Erreichen eines Zwischenereignisknotens wird eine Aktivität vom Typ Zwischenereignis erzeugt. Diese Zwischenereignis-Aktivität erzeugt einen neuen Token (Prozessfluss) jedes Mal, wenn das in der Aktivitätsdefinition hinterlegte Ereignis ausgelöst wird und die Übergangsbedingung erfüllt ist.

Alle für den Prozess notwendigen Daten werden aus der Prozessdefinition und der Aktivitätsdefinition des Startknotens berechnet. Die Prozessdefinition stellt somit die Vorlage für die aus ihr erzeug­ten Prozesse dar. Prozessdefinitionen sind unabhängig von der OLTP-Datenbank und dem System, in dem sie erfasst wurden, da sie weder sys­tem­spezifische noch OLTP-spezifische Daten enthalten. Prozessdefinitionen werden in der Repository-Datenbank gespeichert.

Eine Aktivitätsdefinition muss in jeder Datenbank aktiviert werden, in der sie ver­wen­det werden soll. Beim Aktivieren einer Prozessdefinition werden stellvertretend für die Prozessdefinition die Aktivitätsdefinition des Startknotens sowie die Aktivitätsdefinitionen eventueller Zwischenereignisse ohne eingehende Kanten aktiviert.

Folgende Abbildung zeigt das Datenmodell der Prozessdefinition. Alle Business Objects sind in der Repository-Datenbank gespeichert.

• ActivityDefinition – Eine Aktivitätsdefinition eines Knotens der Prozessdefinition.
• ProcessDefinition – Die Prozessdefinition.
• ProcessDefinitionDeclarations – Die Deklarationen der Prozessdefinition.
• ProcessDefinitionParameter – Definition der in der Prozessdefinition definierten Prozessvariablen.

Prozesse

Der Prozess fasst alle zum Prozess gehörenden Aktivitäten mit ihren Aufgaben zusammen. Der Prozess sowie alle dazugehörigen Aktivitäten und Aufgaben müssen in der gleichen Datenbank gespeichert werden. Ein Prozess kann nicht Aktivitäten in zwei verschiedenen OLTP-Datenbanken besitzen.

Folgende Abbildung zeigt das Datenmodell eines Prozesses.

• Activity – Aktivitäten, die aus den mit den Knoten verknüpften Aktivitätsdefinitionen erzeugt wurden.
• Process – Der Prozess.
• ProcessComment – Die für den Prozess erfassten Kommentare.
• ProcessToken – Der Token ist eine interne Repräsentation des Kontrollflusses.

Ist in der Aktivitätsdefinition zum Startknoten ein Ereignis hinterlegt, dann kann der Prozess nur von diesem Ereignis ausgelöst werden. Ist ein Ereignis vom Typ Benutzeraktion hinterlegt, dann kann der Prozess nur über das Kontextmenü des im Startknoten hinterlegten Business Entitys gestartet werden. Ist in der Aktivitätsdefinition kein Ereignis hinterlegt, dann kann der Prozess nur manuell gestartet werden. Entweder kann der Prozess dann in der Anwendung Prozesse gestartet werden oder auch im andockbaren Fenster Benutzermenü und Favoriten. Im andockbaren Fenster Benutzermenü und Favoriten kann der Prozess nur gestartet werden, wenn die Prozessdefinition aus einer Prozessdefinitions-Vorlage erzeugt wurde, die mit einer interaktiven Anwendung der besonderen Verwendung Prozessdefinition verknüpft ist. Ist ein Benutzer nicht berechtigt, diese Anwendung zu starten, dann erscheint sie nicht im Benutzermenü. Die Berechtigungen für die mit der Prozessdefinitions-Vorlage verknüpften Anwendung werden auch in der Anwendung Prozesse angewendet. Somit kann eine mit der Prozessdefinitions-Vorlage verknüpfte Anwendung mit der Anzeige-Einstellung Keine Anzeige für die Vergabe von Berechtigungen zum Starten von Prozessinstanzen in der Anwendung Prozesse verwendet werden.

Prozesse können nicht direkt bearbeitet werden. Die Bearbeitung erfolgt über die mit dem Prozess verknüpften Aktivitäten und Aufgaben. Welche Aktivitäten erzeugt werden, wird vom Kontrollfluss bestimmt. Der Kontrollfluss wird von Tokens repräsentiert, die entlang der Kanten geführt werden, welche die Knoten miteinander verbinden. Jedes Mal, wenn ein Token einen Knoten erreicht, wird eine neue Aktivität gemäß der zum Knoten zugehörigen Aktivitätsdefinition erzeugt und der Token von der Aktivität konsumiert. Beim Erledigen der Aktivität wird ein neuer Token erzeugt und entlang der ausgehenden Kante weitergeleitet. Besitzt der Knoten keine ausgehende Kante, dann wird kein neuer Token erzeugt.

Mithilfe von s. g. Gateways kann der Kontrollfluss aufgeteilt (verzweigt) und wieder zusammengeführt werden. In Abhängigkeit des Verzweigungstyps und der Übergangsbedingung wird für jede ausgehende Kante der Verzweigung entweder ein Token erzeugt oder kein Token erzeugt. Eine Zusammenführung kann je nach Typ entweder einen Token aus einer einzigen Kante oder einen Token aus jeder der eingehenden Kanten konsumieren. Danach erzeugt die Zusammenführung einen neuen Token und leitet diesen entlang der ausgehenden Kante weiter. Wird der Kontrollfluss mithilfe einer Rückkoppelung so aufgeteilt und zusammengeführt, dass ein Knoten von mehreren Kontrollflüssen erreicht wird, dann wird für jeden Token eine neue Aktivität erzeugt.

Sobald der Kontrollfluss den Endknoten erreicht, endet der Prozess und alle erzeugten aber noch nicht erledigten Aktivitäten werden automatisch unbearbeitet erledigt. Entsteht bei der Ausführung des Prozesses bzw. beim Bearbeiten einer Aktivität ein nicht behebbarer Fehler, dann wird der Kontrollfluss über den Fehlerknoten geleitet und eine Aktivität für den Fehlerknoten erzeugt. Nach dem Erledigen der mit dem Fehlerknoten verbundenen Aktivität endet der Prozess. Ein Fehler entsteht auch dann, wenn der Prozess nicht länger über genügend Tokens verfügt, sodass der Kontrollfluss den Endknoten nicht mehr erreichen kann. Es gibt keinen besonderen Endstatus für einen Prozess, der über den Fehlerknoten endet, aber der Fehlercode und die Fehlerbezeichnung werden im Prozess gespeichert und können auch in den beiden Cockpit-Anwendungen für Prozesse abgefragt werden. Der Kontrollfluss wird auch dann über den Fehlerknoten geleitet, wenn in der Funktion createin den Deklarationen einer Aktivitätsdefinition, die zur Prozessdefinition gehört, der Befehl abortverwendet wird. In einem Startknoten führt der Befehl abortdazu, dass keine Prozessinstanz erzeugt wird.

Bei Bedarf kann ein Prozess auch per Benutzer-Aktion unbearbeitet erledigt werden. In diesem Fall wird der Kontrollfluss direkt zum Endknoten geleitet und der Prozess erhält den Endstatus Unbearbeitet erledigt.

Ein Prozess besitzt Aktivitäten mit zugeordneten Aufgaben. Ist einem Benutzer eine Aufgabe zugeordnet, dann ist dieser Benutzer automatisch dazu berechtigt, über die Aufgabe auch den Prozess zu öffnen, um dort z. B. Kommentare zu erfassen. Im Prozess können auch der Auslöser und der Verantwortliche (als Benutzer oder als Workflowrolle) hinterlegt sein. Die Prozessdefinition legt fest, über welche Berechtigungen diese und weitere Rollen im Prozess verfügen. Darüber können einem Benutzer auch besondere Fähigkeiten für das Framework Workflow-Management zugeordnet werden, die dem Benutzer erlaubt, unabhängig von den Berechtigungseinstellungen in der Prozessdefinition Prozesse zu öffnen und Aktivitäten und Aufgaben zu bearbeiten. Weitere Informationen zu den Berechtigungen von Prozessdefinition finden Sie in der Dokumentation Prozessdefinitionen.

Mithilfe der Aktion [Berechtigungen auf Prozesse anwenden] in der Anwendung Aktivitätsdefinitionen aktivieren lassen sich die in der Prozessdefinition aktuell eingestellten Berechtigungen auf bereits erzeugte Prozessinstanzen übertragen. Diese Funktion ist z. B. dann nützlich, wenn sich die für die Prozessdefinition relevante Ablauforganisation geändert hat, oder wenn der Prozessverantwortliche ein Benutzer und keine Workflowrolle ist und die Verantwortung auf einen neuen Benutzer übertragen werden soll.

Anders als eine Aktivität kann ein Prozess nicht mit beliebigen Business Entitys verknüpft werden. In den beiden Cockpit-Anwendungen für Prozesse können dennoch Prozesse über das bevorzugt verknüpfte Business Entity abgefragt werden. Dabei gelten die Verknüpfungen des Startknotens auch für den Prozess. Möchten Sie z. B. Prozesse über einen verknüpften Vertriebsauftrag abfragen können, dann können Sie im Startknoten mithilfe des Befehls addAttachmentden Vertriebsauftrag mit dem Prozess verknüpfen. Die zuerst erstellte Verknüpfung gilt als die bevorzugte Verknüpfung. Bei manchen Ereignistypen, wie Business Entity und Benutzeraktion, wird das in parameters.objectreferenzierte Business Object automatisch mit dem Startknoten verknüpft. Auch der Betreff des Prozesses wird über den Startknoten definiert. Auch wenn das System der Bearbeiter des Startknotens ist, ist es daher wichtig, dem Startknoten einen aussagekräftigen Betreff zu vergeben, z. B. mithilfe des Befehls formatSubject

Erledigte Prozesse archivieren vergangene Tätigkeiten. Bei manchen Prozessen ist eine Aufbewahrung verpflichtend. Um zu verhindern, dass solche Prozesse vorzeitig reorganisiert werden, kann eine Aufbewahrungsfrist in der Prozessdefinition festgelegt werden. Die Hintergrundanwendung Prozesse reorganisieren zieht die Aufbewahrungsfrist von dem Alter des Prozesses ab. Werden beispielsweise Prozesse, die älter als 52 Wochen sind, reorganisiert, dann muss ein Prozess mit einer Aufbewahrungsfrist von 104 Wochen mindestens drei Jahre bzw. 156 Wochen alt sein, um von der Reorganisation berücksichtigt zu werden.

Workflowrollen

Workflowrollen sind eine Abstraktionsebene, um die vom Work­flow verwendete Ablauforganisation abzubilden. Eine Workflowrolle wird ebenso wie eine Aktivi­täts­definition über ihre Identifikation und das Exportpräfix eindeutig identi­fi­ziert.

Eine Workflowrolle besitzt selbst keine für die Bearbeitung von Aktivitäten und Aufgaben relevanten Daten. Einer Workflowrolle müssen Inha­ber zugeordnet werden, damit diese sinnvoll verwendet werden kann. Die Zuordnung der Inhaber einer Workflowrolle ist datenbankspezifisch, da bei der Zuordnung Business Objekte in dieser Datenbank benutzt werden können. In unter­schied­lichen Datenbanken hat eine Workflowrolle im Allgemei­nen unterschiedliche Inhaber.

Soll ein Prozess oder eine Aktivität von der Aufbauorganisation bearbeitet werden, dann kann der Workflowrolle eine Organisation bzw. Multi-Site-Organisation als Inhaber zugeordnet werden. Besonders für Genehmigungsprozesse kann es sinnvoll sein, die Bearbeitung als eine Matrix von Workflowrollen und Stellen zu definieren.

Die Zuordnung der Inhaber ist zeitabhängig: Jede Zuordnung eines Inhabers besitzt ein Gültigkeitsintervall. Nur während dieses Zeitraums wird die Zuord­nung zur Auflösung hinzugezogen. Damit lassen sich für die Zukunft geplante Änderungen bei den Inhabern erfassen.

Folgende Abbildung zeigt das Datenmodell der Workflowrolle. Das Business Object WorkflowRole ist in der Repository-Datenbank gespeichert. Das Business Object WorkflowRoleElement ist in derjenigen Datenbank gespeichert, für die die Zuordnung der Inhaber gilt.

• WorkflowRole – Workflowrolle.
• WorkflowRoleElement – Datenbank-spezifische Zuordnung eines Inhabers zu einer Workflowrolle.
• WorkflowSystemCustomizing – Customizing-Funktion Workflow-Management mit Beziehungen für die Workflowrolle der Workflow-Administratoren in der Repository-Datenbank und in OLTP- Datenbanken.

In früheren Releases konnten die Inhaber einer Workflowrolle durch einen Ausdruck definiert werden, der bei der Auflösung dieser Workflowrolle ausgewertet wird. Insbesondere bei der Eskalations­behandlung konnten Workflowrollen, die auf Ausdrücken basierten, die Handhabung und das Verständnis erleichtern. Seit der Einführung der Script-Engine für JavaScript besteht diese Möglichkeit nicht mehr, da solche Workflowrollen nicht von allen Script-Engines auswertbar wären. Stattdessen können die Bearbeiter der Aktivität (bzw. die Bearbeiter bei einer Zeitüberschreitung) durch einen Ausdruck in der Aktivitätsdefinition berechnet werden.

Kann beim Erzeugen einer Aktivität kein Bearbeiter ermittelt werden, z. B. weil die verwendete Workflowrolle keine Inhaber besitzt, dann wird die Aktivität der Inhaber einer der in der Customizing-Funktion Workflow-Management hinterlegten Workflowrollen für Administratoren zugeordnet.

Workflow-Definitionen transportieren

Workflow-Vorlagen

In einem Kundensystem können Workflow-Definitionen (Prozessdefinitionen, Aktivitätsdefinitionen und Workflowrollen) als Vorlage gespeichert werden. Workflow-Vorlagen werden im Namensraum com.cisag.sys.respoitory.obj der Repository-Datenbank abgelegt. Die Identifikationen und Speicherorte weichen jedoch jeweils voneinander ab. Auch die Auswirkungen sind verschieden. Während Workflow-Definitionen dem Erzeugen von Prozessen und Aktivitäten dienen, dienen die Workflowrollen-Vorlagen der vereinfachten Administration.

Damit aus einer Workflow-Vorlage später eine Workflow-Definition erzeugt werden kann, besitzen die Workflow-Vorlagen ein ähnliches Datenmodell wie die der Workflow-Definitionen, wie folgende Abbildung des Datenmodells der Aktivitätsdefinitions-Vorlage zeigt.

Sie können eine Workflow-Vorlage wie folgt erfassen:

• Öffnen Sie eine vorhandene Workflow-Definition in der jeweiligen Workflow-Anwendung (Prozessdefinitionen, Aktivitätsdefinitionen oder Workflowrollen) und speichern Sie sie als Vorlage.
• Öffnen Sie die Workflow-Anwendung und wählen Sie Ja im Feld Vorlage aus. Drücken Sie auf [Neu], um eine neue Vorlage zu erfassen.
• Öffnen Sie die Anwendung Entwicklungsobjekte und erfassen Sie ein neues Entwicklungsobjekt mit dem Typ der gewünschten Workflow-Vorlage. Drücken Sie anschließend auf den Button, um in die jeweilige Workflow-Anwendung zu wechseln und geben Sie dort die weiteren Merkmale der Workflow-Definition an.

Wählen Sie die Vorgehensweise, die am besten zu Ihren Anforderungen passt. Möchten Sie eine bereits vorhandene Workflow-Definition als Vorlage speichern, dann öffnen Sie die Workflow-Definition und führen die Aktion aus. Möchten Sie eine neue Workflow-Definition erfassen, dann sind alle drei Vorgehensweisen möglich. Z. B. könnten Sie eine neue Vorlage erfassen. Sie könnten auch eine neue Workflow-Definition erfassen und sie nach erfolgreichem Testen als Vorlage speichern.

Um die referentielle Integrität der Entwicklungsobjekte sicherzustellen, müssen Sie alle von einer Prozessdefinition bzw. Aktivitätsdefinition referenzierten Workflowrollen zuerst als Vorlage speichern, bevor Sie die Prozessdefinition bzw. Aktivitätsdefinition als Vorlage speichern können. Beim Speichern der Prozessdefinition bzw. Aktivitätsdefinition als Vorlage werden alle referenzierten Workflowrollen durch die mit der Workflowrolle verknüpfte Workflowrollen-Vorlage ersetzt. Beim Speichern einer Prozessdefinition als Vorlage, werden zudem alle mit der Prozessdefinition verknüpften Aktivitätsdefinitionen automatisch als Vorlage gespeichert. Sie müssen also nicht die Aktivitätsdefinitionen für die Ereignis- und Aktionsknoten explizit als Vorlage speichern. Wegen der referenziellen Integrität wird dies ohnehin vom System unterbunden.

Beim Erfassen einer Workflow-Vorlage wird ein neues Entwicklungsobjekt erzeugt und einer Entwicklungsaufgabe zugeordnet. Gibt es bereits eine offene Entwicklungsaufgabe für das Entwicklungsobjekt, dann wird diese Entwicklungsaufgabe verwendet. Ansonsten wird eine neue Entwicklungsaufgabe automatisch erzeugt. Solange die Entwicklungsaufgabe offen ist, können Sie die Workflow-Vorlage ändern und speichern, ohne dass eine neue Version der Workflow-Vorlage entsteht. Sobald die Entwicklungsaufgabe aktiviert ist, wird beim Ändern und Speichern der Workflow-Vorlage eine neue Vorlagen-Version automatisch erzeugt. Gleichzeitig wird auch eine neue Entwicklungsaufgabe erzeugt und mit der Workflow-Vorlage verknüpft. Entwicklungsaufgaben für Workflow-Vorlagen lassen sich mithilfe der Aktion [Entwicklungsaufgaben aktivieren…] in der Anwendung Cockpit: Produktivsystem-Entwicklungsobjekte aktivieren. Mit dem Aktivieren erfolgt auch ein Neustart des Systems, um die neuen Entwicklungsobjekte dem System bekannt zu machen.

Das Cockpit: Produktivsystem-Entwicklungsobjekte kann auch verwendet werden, um die als Entwicklungsobjekt erzeugten Workflow-Vorlagen vom Quellsystem in nachfolgende Systeme zu transportieren. So kann z. B. eine Prozessdefinition, die in einem Kunden-Testsystem erfasst und dort als Vorlage gespeichert wurde, in das Kunden-Produktivsystem transportiert werden. Als Transportmedium werden Softwareaktualisierungen verwendet, die in den nachfolgenden Systemen installiert werden. Eine Workflowrollen-Vorlage kann wahlweise mit oder ohne Inhaber transportiert werden. Da Workflow-Vorlagen in der Repository-Datenbank gespeichert werden, kann eine Workflowrollen-Vorlage nur Inhaber von Typen besitzen, die nicht in der OLTP-Datenbank gespeichert sind. Eine Workflowrollen-Vorlage kann daher nur Inhaber der Typen Benutzer und Benutzergruppe besitzen. Beim Installieren wird das Zielsystem neu gestartet. Verwenden Sie daher die Aktion [Installation planen], um die Softwareaktualisierungen zeitgesteuert zu installieren. Weiterführende Informationen zu diesem Thema finden sie in den Dokumentationen Einführung: Softwarelogistik, Entwicklungsobjekte und Cockpit: Produktivsystem-Entwicklungsobjekte.

Da eine Workflow-Vorlage nicht ausgeführt werden kann, müssen Sie aus der Vorlage eine Workflow-Definition erzeugen und aktivieren, um die Vorlage testen zu können. Die erzeugte Workflow-Definition wird dabei automatisch mit der Vorlage verknüpft. War der Test nicht erfolgreich oder Sie möchten die Vorlage anpassen, dann sollten Sie die Änderungen direkt in der Workflow-Vorlage und nicht in der Workflow-Definition durchführen. Wenn Sie aus der geänderten Vorlage eine neue Workflow-Definition mit der gleichen Identifikation erzeugen, dann werden die Änderungen auf die vorhandene Workflow-Definition übertragen. Wiederholen Sie diese Vorgehensweise, bis die Workflow-Vorlage nicht mehr angepasst werden muss. Falls die Anwendung der Workflow-Definition (Prozessdefinitionen, Aktivitätsdefinitionen oder Workflowrolle) die Aktion [Vorlage aktualisieren] anbietet, dann können Sie eventuelle Änderungen in der Workflow-Definition auf die Workflow-Vorlage übertragen. Wie beim Speichern entsteht dabei eine neue Vorlagen-Version, falls keine offene Entwicklungsaufgabe für das Vorlagen-Objekt existiert.

Workflow-Vorlagen, die in einem vorgelagerten System erfasst wurden, können in nachgelagerten Systemen nicht geändert werden. In welchem System eine Workflow-Vorlage erfasst wurde, erkennen Sie am Namensraum der Vorlage. Nur wenn der Namensraum dem aktuellen System entspricht, lässt sich die Vorlage ändern.

Eine mit dem ERP-System ausgelieferte oder von einem der Partner erstellte und ausgelieferte Workflow-Vorlage muss in der Regel an den spezifischen Anforderungen jedes einzelnen Kunden angepasst werden. Beispielsweise müssen die in den Aktivitätsdefinitionen hinterlegten Workflowrollen durch kundenspezifische Workflowrollen ersetzt werden. Da Sie ausgelieferte Workflow-Vorlagen nicht ändern können, können Sie stattdessen die Vorlage in Ihrem Testsystem duplizieren. Beim Duplizieren wird eine neue Vorlage unter dem Namensraum Ihres Systems angelegt und einer automatisch erzeugten Entwicklungsaufgabe zugeordnet. Danach lässt sich die neue Workflow-Vorlage direkt im Testsystem wie oben beschrieben ändern. Als alternative Vorgehensweise können Sie aus der ausgelieferten Workflow-Vorlage eine Workflow-Definition zu erzeugen. Führen Sie aber keine Änderungen in dieser Workflow-Definition durch, da sie ja bereits mit einer Vorlage verknüpft ist und daher nicht erneut als Vorlage gespeichert werden kann. Stattdessen duplizieren Sie die erzeugte Workflow-Definition, führen Ihre Änderungen durch und speichern die geänderte Workflow-Definition anschließend als eine neue Vorlage. In der Regel sind ausgelieferte Prozessdefinitions-Vorlagen so implementiert, dass sie mithilfe von konstanten Werten in den Deklarationen der Prozessdefinition angepasst werden können. Dort befinden sich auch Anleitungen zum Anpassen und zur Inbetriebnahme der Prozessdefinition.

Beim Erzeugen einer Workflow-Definition aus einer Vorlage wird die neue Workflow-Definition automatisch mit der Vorlage verknüpft. Beim Speichern einer Workflow-Definition als Vorlage kann die Workflow-Definition nur dann mit der Vorlage verknüpft werden, wenn diese Möglichkeit im Aktionsdialog explizit angeboten wird. Wird die Aktion nicht angeboten, dann können Sie eine Verknüpfung dennoch herstellen, indem Sie aus der Vorlage eine neue Workflow-Definition mit der gleichen Identifikation wie die Workflow-Definition erzeugen, aus der die Vorlage entstanden ist. Beim Überschreiben der vorhandenen Workflow-Definition wird diese automatisch mit der Vorlage verknüpft. Eine aus einer Workflow-Vorlage erzeugte Workflow-Definition kann nicht geändert werden, um sicherzustellen, dass die Workflow-Definition der Vorlage entspricht.

Wenn eine ins Kunden-Produktivsystem transportierte und dort aktivierte Workflowrollen-Vorlage korrigiert oder an geänderte Anforderungen angepasst werden soll, sollte die Workflow-Vorlage im vorgelagerten Kunden-Testsystem angepasst werden. Nachdem die daraus entstandene neue Vorlagen-Version erfolgreich getestet wurde, kann die Entwicklungsaufgabe aktiviert und die Installation im Kunden-Produktivsystem geplant werden.

Sollte es notwendig sein, eine aus einer Workflow-Vorlage erzeugte Workflow-Definition sofort und ohne Verzögerung korrigieren zu müssen, kann die Workflow-Definition im Kunden-Produktivsystem mithilfe der Aktion [Vorübergehend bearbeiten] für die Bearbeitung geöffnet werden. Danach sind durchgeführte Änderungen sofort wirksam. Die Workflow-Definition bleibt bis zum nächsten Aktualisieren aus der Vorlage editierbar. Ist in der Workflow-Definition im Kunden-Produktivsystem die Funktion für die automatische Aktualisierung im Karteireiter Vorlageneinstellungen aktiviert, dann wird die Workflow-Definition beim Installieren bzw. beim Aktivieren einer neuen Vorlagen-Version automatisch aktualisiert. Ist die Funktion nicht aktiviert, dann wird die Workflow-Definition erst beim Ausführen der Aktion [Gemäß Vorlage erzeugen oder aktualisieren] im Aktionen-Menü der Standard-Symbolleiste aktualisiert.

Beim Aktualisieren einer vorhandener Workflowrolle aus der Workflowrollen-Vorlage können der Workflowrolle neue Inhaber gemäß der Vorlage hinzugefügt werden. Vorhandene Inhaber, die der neuen Vorlagen-Version nicht zugeordnet sind, bleiben in der Workflowrolle erhalten.

Das Aktualisieren einer aus einer Vorlage erzeugten Prozessdefinition kann negative Auswirkungen auf offene Prozessinstanzen haben.

Um solchen Laufzeitfehlern vorzubeugen, ist es in der Regel sinnvoller, die Funktion für die automatische Aktualisierung der Prozessdefinition nicht zu aktivieren und stattdessen eine neue Prozessdefinition aus der neuen Vorlagen-Version mit der Aktion [Gemäß Vorlage erzeugen oder aktualisieren] gezielt zu erzeugen. Die neu erzeugte Prozessdefinition sollte dabei eine eigene Identifikation erhalten. Anschließend wird die neue Prozessdefinition aktiviert und die vorhandene Prozessdefinition deaktiviert. Neue Prozessinstanzen verwenden die aus der neuen Vorlagen-Version erzeugte Prozessdefinition. Eventuelle Prozessinstanzen, die aus der vorhandenen Prozessdefinition erzeugt wurden, verwenden aber weiterhin die alte Prozessdefinition und können zu Ende ausgeführt werden.

Ein Laufzeitfehler kann auch nach einem Release-Wechsel entstehen. Speichert eine Aktivität ein Business Object mit einem kunden-spezifischen Attribut, das im alten Release als Extension und im neuen Release als Supplement implementiert ist, dann kann die Aktivität das Business Object nicht deserialisieren und ein Laufzeitfehler entsteht. In solchen Fällen können die Toolshell-Befehle dltwflactund dltwflprcverwendet werden, um Aktivitäten bzw. Prozesse, die nicht mehr verarbeitet werden können, aus der Datenbank zu löschen.

Wird später festgestellt, dass die neue Vorlagen-Version fehlerhaft ist, dann kann eine beliebige vorherige Version wiederhergestellt werden. Öffnen Sie dazu die Workflow-Vorlage und wählen im Feld Version die Version aus, die wiederhergestellt werden soll. Führen Sie anschließend die Aktion [Gemäß Vorlage erzeugen oder aktualisieren] aus. Wird der Name einer vorhandenen Workflow-Definition vergeben, dann wird diese durch die ausgewählte Version ersetzt. Um Ausführungsfehler bei offenen Prozessinstanzen zu verhindern, vergeben Sie eine neue, eindeutige Identifikation. Aktivieren Sie daraufhin die neu erzeugte Prozessdefinition und deaktivieren Sie die bereits vorhandene Prozessdefinition.

Wird eine Workflow-Vorlage als abgelehnt (deprecated) markiert, dann wird eine Warnmeldung beim Aktivieren einer Prozessdefinition oder einer Aktivitätsdefinition ausgegeben, wenn diese mit der gespeicherten Workflow-Vorlage verknüpft ist oder eine abgelehnte Workflowrollen-Vorlage verwendet. Um eine Workflow-Vorlage abzulehnen, erzeugen Sie eine neue Vorlagen-Version und öffnen diese in der Anwendung Entwicklungsobjekte. Führen Sie anschließend die Aktion [Ablehnen] aus. Nach dem Aktivieren der Entwicklungsaufgabe kann die abgelehnte Vorlagen-Version ins nachgelagerte System transportiert und dort installiert werden.

In der Anwendung Entwicklungsobjekte lassen sich Workflow-Vorlagen auch löschen. Da Workflow-Vorlagen als Entwicklungsobjekte in der Repository-Datenbank gespeichert werden, können sie nicht im herkömmlichen Sinn gelöscht werden. Stattdessen entsteht eine neue s. g. Löschversion. Diese Löschversion kann wie eine normale Vorlagen-Version aktiviert und in ein nachgelagertes System transportiert werden. Wird beim Aktivieren einer mit einer abgelehnten Workflow-Vorlage verknüpften Prozessdefinition oder Aktivitätsdefinition eine Warnmeldung ausgegeben, wird bei einer gelöschten Workflow-Vorlage eine Fehlermeldung ausgegeben, welche die Aktivierung verhindert. Auch können aus einer mit einer gelöschten Vorlage verknüpften Prozessdefinition oder Aktivitätsdefinition keine Instanzen erzeugt werden. Aus einer mit einer gelöschten Vorlage verknüpften Workflowrolle werden keine Inhaber ermittelt.

Import und Export per Toolshell-Befehl

Um eine Workflow-Definition aus einem vorgelagerten in ein nachgelagertes System zu transportieren, stehen die Workflow-Vorlagen als bevorzugtes Mittel zur Verfügung. Soll eine Workflow-Vorlage in ein System transportiert werden, das nicht vom Quellsystem mit Softwareaktualisierungen versorgt wird, dann können die Toolshell-Befehle expwflund impwflverwendet werden. Der Transport mithilfe dieser Befehle ist vorwärts- aber nicht rückwärtskompatibel. Besitzt das Zielsystem einen niedrigeren Release-Stand, ist ein Transport u. U. nicht mehr möglich. In einem solchen Fall kann die Workflow-Definition im Zielsystem nur noch neu erfasst werden.

Der Transport mithilfe der Toolshell-Befehle ist nicht NLS-fähig. Mehrsprachige Texte, wie z. B. die Bezeichnung und die Betreffzeile in einer Aktivitätsdefinition, werden in der Hauptsprache der Repository-Datenbank transportiert.

Workflowrollen können mithilfe des Toolshell-Befehls

expwfl -f:<str> [-role:<str-1> ... -role:<str-n>*]exportiert werden. Der Platzhalter <str>steht für die zu erzeugende Exportdatei und die Platzhalter <str-1>bis <str-n>stehen für die Identifikationen der Workflowrollen, die exportiert werden sollen. Workflowrollen, die von einer Prozessdefinition oder Aktivitätsdefinition referenziert werden, werden zusammen mit der Prozessdefinition bzw. Aktivitätsdefinition automatisch exportiert und importiert. Der Export berücksichtigt keine Workflowrollen-Inhaber.

Um Aktivitätsdefinitionen und Prozessdefinitionen zu exportieren, verwenden Sie den Parameter definitionbzw. processDefinitionstatt role. Beim Exportieren einer Prozessdefinition werden alle verknüpften Aktivitätsdefinitionen automatisch mit exportiert.

Mithilfe des Befehls

impwfl -f:<str>können die exportierten Workflowrollen in ein Zielsystem importiert werden. Weitere Informationen zum Export und Import von Workflow-Definitionen finden Sie in den Dokumentationen Workflow-Definitionen exportieren (expwfl) und Workflow-Definitionen importieren (impwfl).

Workflow-Definitionen, die in einem System mit einem anderen Exportpräfix erfasst wurden, müssen erst übernommen werden, bevor sie verwendet werden können. Beim Übernehmen wird die Workflow-Definition kopiert. Die Kopie erhält dabei das Exportpräfix des aktuellen Systems. Importierte Workflow-Definitionen mit einem vom aktuellen System abweichenden Exportpräfix dienen nur als Vorlage für die im System aktiven Workflow-Definitionen. Um dies im Datenmodell abzubilden, wird eine Workflow-Definition durch eine Identifikation und durch das Exportpräfix des Systems eindeutig identifiziert, auf dem die Workflow-Definition erstellt wurde. Das Exportpräfix des aktuellen Systems wird in der Anwendung System­cock­pit in der Ansicht System angezeigt.

Aktivitäten und Aufgaben bearbeiten

In diesem Abschnitt werden die technischen Details für die Verarbeitung von Akti­vitäten und Aufgaben im Workflow erklärt. Die grundlegende Verarbeitung von Aktivitäten und Aufgaben wird dabei als bekannt vorausgesetzt.

Die Dokumente Einführung: Workflow-Management, Aktivitäten und das Kapitel Workflow-Management im Bedienungsleitfaden beschreiben die Verarbeitungs­mög­lichkeiten und die Statusänderungen von Aktivitäten und Aufgaben.

Bearbeiten von Aktivitäten

Eine Aktivität kann über das andockbare Fenster Aufgaben suchen oder über eine URL in Bearbeitung genommen werden. Im andockbaren Fenster Aufgaben suchen nehmen Sie eine Aktivität mithilfe der Aktion [Öffnen] im Kontextmenü der Aufgabe in Bearbeitung. Damit der Bearbeiter der Akti­vität die mit der Aktivität verbundene Tätigkeit durchführen kann, wird eine pas­sen­de Anwendung geöffnet. Welche Anwendung dazu geöffnet wird, wird wie folgt bestimmt:

1. Wenn die Aktivität aus einer Aktivitätsdefinition erstellt wurde und dort eine Anwendung eingetragen ist, wird die dort eingetragene Anwendung geöffnet.
2. Wenn die Aktivität mindestens eine Verknüpfung besitzt, wird das Objekt mit der bevorzugten Verknüpfung geöffnet. Die Anwendung, die für dieses Objekt geöffnet wird, kann vom Benutzer eingestellt werden.
3. Wenn weder eine bevorzugte Verknüpfung existiert noch durch eine Aktivi­tätsdefinition eine Anwendung hinterlegt ist, dann wird die Aktivität selbst in der Anwendung Aktivitäten geöffnet.

Ist die Anwendung Aktivitäten nicht bereits geöffnet, dann werden die wichtigsten Informationen aus der Aktivität, wie z. B. der Betreff und die Bezeichnung sowie eventuelle Nachrichten zur Aufgabe, im andockbaren Fenster Aktivitätsinformationen angezeigt.

Die zu einer Aktivität gehörenden Aufgaben können im Einzelbearbeitungsmodus oder im Mehrfachbearbeitungsmodus bearbeitet werden. Bei der Einzelbearbeitung wird beim Erledigen einer Aufgabe auch die Aktivität erledigt. Wird die Aufgabe unbearbeitet erledigt, dann erhält auch die Aktivität den Status Unbearbeitet erledigt. Bei der Mehrfachbearbeitung müssen alle Bearbeiter ihre Aufgaben erledigen oder unbearbeitet erledigen, bevor die Aktivität als erledigt gilt. In diesem Fall gilt die Aktivität als erledigt, wenn mindestens eine Aufgabe erledigt wurde. Wurden alle Aufgaben unbearbeitet erledigt, dann gilt auch die Aktivität als unbearbeitet erledigt. Es muss also mindestens eine erledigte Aufgabe geben, damit die Aktivität als erledigt gilt. Die Mehrfachbearbeitung kann entweder parallel oder sequenziell erfolgen. Bei der parallelen Mehrfachbearbeitung können die Bearbeiter ihre Aufgabe gleichzeitig bearbeiten. Bei der sequenziellen Mehrfachbearbeitung werden alle weiteren noch offenen Aufgaben gesperrt, sobald ein Bearbeiter seine Aufgabe in Bearbeitung nimmt. Erledigt der Benutzer die Aufgabe (mit oder ohne Bearbeitung) oder stellt er sie zurück, dann werden die gesperrten Aufgaben wieder entsperrt. Somit wird sichergestellt, dass zu jedem Zeitpunkt maximal ein Benutzer die Aktivität bearbeitet.

Ist in der Aktivitätsdefinition der durchgehende Bearbeitungsmodus eingestellt, dann verhindert eine Vorbedingung die durchgehende Bearbeitung. Eine durchgehende Bearbeitung ist nur dann möglich, wenn folgende Bedingungen erfüllt sind:

• Die Aktivität besitzt keine Vorbedingung.
• Die Aktivität beginnt in 0 Millisekunden.
• Der Benutzer, der die Aktivität erledigt ist auch einer der Bearbeiter der Nachfolge-Aktivität.

Im Verlauf der Bearbeitung können zu einer Aktivität weitere Aufgaben hinzukommen. Dies kann manuell durch Einbeziehung neuer Bearbeiter erfolgen oder automatisch bei einer Zeitüberschreitung des Bearbei­tungszeitraumes.

Statusänderungen und Bedingungen

Die Status einer Aktivität werden sowohl manuell durch den Benutzer als auch automatisch durch die Workflow-Engine geändert. Die durch den Benutzer initiierten Statusänderungen basieren meist darauf, dass der Benutzer Aufga­ben in Bearbeitung nimmt oder erledigt. Beim Erreichen beziehungsweise Über­schreiten des Bearbeitungszeitraums ändert die Workflow-Engine die Status.

Aktivitäten, die aus einer Aktivitätsdefinition erzeugt sind, können eine Vorbedingung besitzen. Die Vorbedingung einer Aktivität drückt aus, ob die mit der Aktivität ver­bundene Tätigkeit bereits ausgeführt wurde oder überflüssig geworden ist. Die Vorbedingung wird bei jeder Statusänderung der Aktivität geprüft. Wenn die Vorbedingung nicht mehr erfüllt ist, wird der Status der Aktivität auf Unbearbeitet erledigt geändert.

Nicht jede Statusänderung einer Aufgabe führt zu einer Statusänderung der Aktivität. Wird z. B. eine Aktivität im Bearbeitungsmodus Mehrfachbearbeitung verarbeitet, dann wechselt die Aktivität nur dann in den Status In Bearbeitung, wenn die erste Aufgabe in Bearbeitung genommen wird. Nimmt ein weiterer Bearbeiter eine Aufgabe in Bearbeitung, dann bleibt der Status der Aktivität In Bearbeitung. Ebenso wechselt eine Aktivität im Bearbeitungsmodus Mehrfachbearbeitung erst mit dem Erledigen der letzten Aufgabe in den Status Erledigt bzw. Unbearbeitet erledigt. Der Benutzer, der durch das Erledigen einer Aufgabe auch die Aktivität erledigt hat, wird im Attribut completeUserder Aktivität gespeichert. Dieses Attribut steht bereits in der Funktion closefür Auswertungen zur Verfügung.

In einem Startknoten führt eine nicht erfüllte Vorbedingung dazu, dass der Prozess nicht startet. Besitzt der Startknoten Ergebnisse, dann wird die Funktion validatevor der Funktion createausgeführt. Somit lassen sich Benutzereingaben prüfen, bevor die Prozessinstanz erzeugt wird.

Hat eine Aktivität einen oder mehrere Benutzer als Bearbeiter, dann wird beim Erledigen der Aktivität die Nachbedingung ausgewertet. Ist die Nachbedingung nicht erfüllt, kann der Benutzer seine Aufgabe nicht erledigen, wenn dies auch zum Erledigen der Aktivität führen würde. Eventuelle Meldungen für den Benutzer können mithilfe des Befehls sendMessagesowohl in der Vorbedingung als auch in der Nachbedingung ausgegeben werden. In diesem Fall sollten Sie in der Aktivitätsdefinition für das Feld Vorbedingung bzw. Nachbedingung die Einstellung Deklaration auswählen, da Befehle nur in Deklarationen verwendet werden können.

Aktivitäten ohne Bearbeiter

Einer Aktivität können evtl. keine Bearbeiter zugeordnet werden. Dies ist bei­spielsweise mög­lich:

• wenn der Bearbeiter eine Workflowrolle ohne Inhaber ist,
• wenn der Bearbeiter eine Person ohne einen zugeordneten Benutzer ist,
• wenn der Bearbeiter eine Stelle ist und bei der Auflösung der Partnerbeziehungen keine Stellvertreter bzw. keine Vor­gesetzten gefunden wer­den
• oder wenn der Bearbeiter eine Prozessrolle ist (wie z. B. der Prozessverantwortliche), und diese Prozessrolle unbesetzt ist.

Eine Aktivität ohne Bearbeiter besitzt auch keine Aufgaben und kann daher von niemandem bearbeitet werden. Aus diesem Grund muss einer Aktivität immer mindestens ein Bearbeiter zugeordnet werden.

Wenn beim Erzeugen einer Aktivität kein Bearbeiter gefunden wird, so werden die in der Customizing-Funktion Workflow-Management hinterlegten Workflowrollen für Administratoren verwendet. Wenn auch mit diesen Workflow­rollen keine Bearbeiter ermittelt werden können, so wird der Administrator als Bear­beiter eingetragen. Der Workflow-Administrator bzw. der Administrator können herausfinden, aus wel­chem Grund kein Bear­beiter gefunden wurde, und die Aufgabe an einen geeigneten Benutzer weiterleiten.

Serienaktivitäten und Serienvorlagen

Serien werden als spezielle Aktivitäten im System abgebildet. Eine Aktivität vom Typ Serienvorlage dient als Kopiervorlage für die daraus erzeugten Serienaktivitäten. Der Beginn des Bearbeitungszeitraums der Serie ist der Zeitpunkt, zu dem eine neue Serienaktivität erzeugt werden soll. Sobald die Serienaktivität erzeugt wurde, wird der Beginn des Bearbeitungszeitraumes auf den Zeitpunkt geän­dert, zu dem die nächste Serienaktivität erzeugt werden soll. Wenn keine Serien­aktivität mehr erzeugt werden soll, erhält die Serienvorlage den Status Erledigt.

Beim Erzeugen der Serienaktivität aus der Serienvorlage werden die Deklarationen nicht erneut ausgewertet. Die Serienaktivität erhält somit ihre Merkmale incl. Betreff und Bezeichnung aus der Serienvorlage. Beim Erzeugen der Serienaktivität werden die Vorbedingung und die Serienbedingung ausgewertet. Ist die Vorbedingung nicht erfüllt, dann wird die Serienaktivität übersprungen. Ist die Serienbedingung nicht erfüllt, wird die gesamte Serie beendet.

Um mehr Flexibilität zu erreichen, kann statt eine Aktivitätsdefinition vom Typ Serienvorlage eine Prozessdefinition mit einem Timer-Ereignis verwendet werden. Im Timer-Ereignis kann, genau wie bei einer Serienvorlage, ein Serienmuster hinterlegt werden. Für jeden Zeitpunkt des Serienmusters erzeugt das Timer-Ereignis einen neuen Token und leitet diese über die ausgehende Kante an den oder die nächsten Knoten weiter.

Hintergrundverarbeitung

Beim Erfassen von Verarbeitungsaufträgen wird bei der Nutzung des internen Schedulers eine Aktivität erzeugt. Diese Aktivität kann entweder eine Einzelaktivität oder eine Serie sein. Wenn der Bearbeitungszeitraum der Aktivität erreicht ist, wird der zugeordnete Verarbeitungsauftrag gestartet. Die Akti­vität wird erledigt, wenn der Verarbeitungsauftrag erfolgreich ausgeführt wurde.

Die auf Basis einer Aktivitätsdefinition erzeugten Aktivitäten können Verarbei­tungsaufträge erzeugen und auslösen und darüber Hintergrundanwendungen aus­führen. Dazu wird in der Aktivitätsdefinition ein Verarbeitungsauftrag als Bearbeiter eingetragen. Beim Erzeugen der Aktivität wird auch der Verarbeitungsauftrag erzeugt. Beim Statuswechsel von Geplant auf Zu bearbeiten wird der Ver­arbeitungsauftrag freigegeben.

Wann die Aktivität erledigt wird, hängt von der Einstellung Auf Verarbeitungsauftrag warten in der Aktivitätsdefinition ab. Ist die Checkbox nicht aktiviert, wird die Aktivität sofort nach dem Erzeugen des Verarbeitungsauftrags erledigt. Ist die Checkbox aktiviert, dann wird die Aktivität erst nach dem Ausführen des Verarbeitungsauftrags erledigt. Im ersteren Fall erhält die Aktivität den Status Erledigt, wenn der Verarbeitungsauftrag fehlerfrei erzeugt werden konnte. Im letzteren Fall erhält die Aktivität den Status Erledigt, wenn der Verarbeitungsauftrag erfolgreich ausgeführt werden konnte. Ansonsten erhält die Aktivität den Status Unbearbeitet erledigt. Der Status der Aktivität ist somit unabhängig von Fehlern, die bei der Ausführung des Verarbeitungsauftrags auftreten.

Damit ein Verarbeitungsauftrag erfolgreich erfasst werden kann, muss die Aktivitätsdefinition die Hintergrundanwendung, den Benutzer und die Warteschlange bestimmen. Die Hintergrundanwendung und ihre Parameter werden in dem Karteireiter Anwendung hinterlegt. Den für den Verarbeitungsauftrag zu verwendenden Benutzer und die Warteschlange werden mithilfe der Befehle setJobUserund setJobQueuein den Deklarationen bestimmt. Die Befehle ersetzen die Vorgabewerte aus der Customizing-Funktion Workflow-Management. Achten Sie darauf, dass der für den Verarbeitungsauftrag verwendete Benutzer berechtigt ist, die Hintergrundanwendung auszuführen, da die Hintergrundverarbeitung sonst mit einem Fehler abbricht.

Ist die Checkbox Auf Verarbeitungsauftrag warten in der Aktivitätsdefinition aktiviert, dann stehen die Ergebnisse der Hintergrundanwendung in der Funktion closezur Verfügung. Folgende Deklaration wertet das Ergebnis der Aktion CreateCountListsder Hintergrundanwendung Inventur-Aktionen veranlassen (com.cisag.app.inventory.physical.log.PhysicalInventoryCountProcessing) aus, und gibt die erzeugte Inventurzählliste im Protokoll aus:

function close(state as Number)
{
var rp as HashMap; /* result parameters */
var clGenerated as Number; /* count lists generated */
var clGuids as Guid[]; /* count list guids */
var cl as CisObject(com.cisag.app.inventory.physical.obj.PhysicalInventoryCountList);

rp := cast(HashMap, getJobResult().resultParmeters);
clGenerated := cast(Number, rp.ResultNumberOfSuccessfulResults);
clGuids := cast(Guid[], rp.ResultPhysicalInventoryCountListGuids);

echo(format(clGenerated, "0") + " count list(s) generated:");
for (g : clGuids) {
cl := getByPrimaryKey(CisObject(com.cisag.app.inventory.physical.obj.PhysicalInventoryCountList), g);
echo(cl->PhysicalInventory->Type:code + "-" + cl->PhysicalInventory:number + " " + cl:number);
}
}

In der Regel befindet sich das Ergebnis in Parameter resultParmeters

Welche Ergebnisse eine Hintergrundanwendung besitzt, wird im Eigenschaftendialog des Verarbeitungsauftrags im Karteireiter Ausführung angezeigt, nachdem die Hintergrundanwendung ausgeführt wurde.

In dem Karteireiter Auftrag im Eigenschaftendialog befinden sich auch die Übergabeparameter. Möchten Sie eine Aufgabe mithilfe einer Hintergrundanwendung automatisieren, wie z. B. das Versenden einer Auftragsbestätigung nach dem Freigeben eines Vertriebsauftrags, dann können Sie einen Vertriebsauftrag erfassen und freigeben. Anschließend führen Sie die Aufgabe, welche automatisiert werden soll im Hintergrund aus und fragen die Übergabeparameter ab. Geben Sie auf dem Karteireiter Anwendung der Aktivitätsdefinition die gleichen Parameterwerte wie im Eigenschaftendialog ein. Die Dokumentation Verarbeitungsaufträge enthält weitere Informationen zu diesem Thema.

In dem Karteireiter Anwendung der Aktivitätsdefinition werden nur die im Entwicklungsobjekt deklarierten Anwendungsparameter angezeigt. Nur diese deklarierten Anwendungsparameter lassen sich in einer Aktivitätsdefinition verwenden. Fehlt ein wichtiger Anwendungsparameter im Entwicklungsobjekt oder sind gar dort gar keine Anwendungsparameter deklariert, dann können Sie die Hintergrundanwendung Hintergrund-Anwendungen im Workflow aufrufen (com.cisag.app.general.log.Activity2BatchJob) verwenden, um die eigentliche Hintergrundanwendung aufrufen. Geben Sie dazu im Karteireiter Anwendung der Aktivitätsdefinition die Hintergrundanwendung Hintergrund-Anwendungen im Workflow aufrufen ein. Im Anwendungsparameter ProcessParametersgeben Sie den technischen Namen incl. Namensraum der aufzurufenden Hintergrundanwendung ein. Die Anwendungsparameter der aufzurufenden Hintergrundanwendung übergeben Sie als eine Hashtabelle im Anwendungsparameter Parameters. Die Parameterwerte weisen Sie in den Deklarationen zu. Weitere Informationen finden Sie in der Dokumentation Hintergrund-Anwendungen im Workflow aufrufen.

Erzeugt die Aktivität ein Belegdokument oder ein Berichtsdokument, dann werden die Benutzereinstellungen für den Verarbeitungsauftrag verwendet. Die Belegerzeugung muss aber die zu verwendende Belegdokument-Vorlage kennen. Setzen Sie daher immer den Befehl setJobVoucherDocumentOutputOptions(true)ab, um die Standard-Belegdokument-Vorlage des Belegempfängers zu verwenden. Hat der Befehlsparameter den Wert true, dann werden die Ausgabeeinstellungen aus der Belegdokument-Vorlage statt die des Benutzers verwendet. Bis zum Release 6.2 sind die Ausgabeeinstellungen aus der Belegdokument-Vorlage zwingend zu verwenden. Ab dem Release 6.3 können Sie auch die Befehle setJobVoucherDocumentOutputOptions(false)und setJobDeliveryMethodabsetzen, um die Ausgabeeinstellungen des Benutzers für ein bestimmtes Ausgabemedium zu verwenden. Ab dem Release 6.3 stehen zudem weitere Befehle zur Verfügung, um einzelne Ausgabeeinstellungen des Benutzers anzugeben, ähnlich wie im Karteireiter Ausgabeeinstellungen im Anwendungsdialog. Wurde bei einer Belegerzeugung der Befehl setJobVoucherDocumentOutputOptions(true)abgesetzt um die Standard-Belegdokument-Vorlage des Belegempfängers zu verwenden, dann kommt die Ausgabeeinstellung des Benutzers nur dann zum Tragen, wenn in der Belegdokument-Vorlage die Einstellung Aus Benutzereinstellungen ausgewählt ist. Das Dokument System-Skriptsprache: Workflow-Funktionen beschreibt im Kapitel Funktionen für Service-Knoten diese und andere Befehle, die in Aktivitätsdefinitionen mit einem Verarbeitungsauftrag als Bearbeiter verwendet werden können.

Fehlerzustand einer Aktivität

Tritt innerhalb der Workflow-Engine ein Fehler bei der Bearbeitung einer Akti­vität auf, dann wird die Aktivität gestoppt und erhält den Fehlerstatus Fehlerhaft. Die Akti­vität ist von der weiteren Bearbeitung in der Workflow-Engine ausgeschlos­sen. Dadurch wird verhindert, dass die Workflow-Engine immer wieder ver­sucht, Aktivitäten zu verarbeiten, die zu Fehlern führen. Gestoppte Aktivitäten können manuell weiterbearbeitet, d. h. beispielsweise erledigt werden.

Mit den Anwendungen Cockpit: Aktivitäten/OLTP-Datenbank und Cockpit: Aktivitäten/Repository-Datenbank können gestoppte Aktivitäten gesucht werden. Wurde die Ursache des Fehlers behoben, können mit der Anwen­dung Aktivitäten die Aktivitäten mit dem Fehlerstatus Fehlerhaft wieder gestar­tet werden.

Ereignisse auswerten

Ereignisse bilden die Basis für das Erzeugen von Aktivitäten aus Aktivitätsdefinitionen. Ein Ereignis wird aufgrund einer Zustandsänderung in einer Anwendung, vom System oder von einem Benutzer aus­gelöst. Ein Ereignis tritt zu einem Zeitpunkt auf und enthält zusätz­li­che Parameter, die das Ereignis weiter beschreiben.

Die Ereignisbehandlung der Workflow-Engine verarbeitet Ereignisse mit mög­lichst kurzer Verzögerung. Ereignisse werden asynchron verarbeitet. Sie wer­den also nicht gleichzeitig mit dem Auslösen des Ereignisses verarbeitet, son­dern erst, wenn die Ursache bereits abgeschlossen ist, die zum Auslösen des Ereignisses geführt hat. Damit kann diese Ursache bereits durch andere Ände­rungen hinfällig geworden sein. In einer Aktivitätsdefinition kann mithilfe der Vorbe­dingung geprüft werden, ob die Existenz einer Aktivität noch gerecht­fertigt ist.

Ereignisse werden nicht persistent gespeichert. Wird der Application-Server, auf dem das Ereignis ausgelöst wurde, heruntergefahren oder anderweitig beendet, bevor das Ereignis ausgewertet wurde, geht das Ereignis verloren und die Aktivität kann nicht mehr erzeugt werden.

Programmierte Ereignisse

Für spezielle Anwendungsfälle können Ereignisse direkt in einer Anwendung oder in eine Logikklasse eingebaut werden. Diese s. g. programmierten Ereignisse können auch im Rahmen einer Adaption beziehungsweise Branchenlösung durch Partner hin­zugefügt werden. Ein programmiertes Ereignis wird vom Entwickler in den Java-Quell­code einer Anwendung eingebaut.

Ein programmiertes Ereignis ist ein Entwicklungsobjekt und wird mit der Anwendung Entwicklungsobjekte erfasst. Zum Auslösen eines programmierten Ereignisses ist eine Programmierschnittstelle vorhanden.

Programmierte Ereignisse können beliebige Parameter besitzen. Welche Parameter ein programmiertes Ereignis besitzt, können Sie in der Anwendung Entwicklungsobjekte einsehen.

Das Auslösen eines programmierten Ereignisses kostet im Allgemeinen relativ wenig Zeit. Jede Aktivitätsdefinition, die ein Ereignis auswertet, kostet im Vergleich dazu relativ viel Zeit. Beim Erfassen einer Aktivitätsdefinition sollte beachtet werden, dass die Auswertung der Übergangsbedingung Zeit benötigt. Ereignisse, die von keiner Aktivi­täts­definition ausgewertet werden, verursachen also kein Geschwindig­keits­problem.

Je spezifischer ein Ereignis ist und je seltener es aus­ge­löst wird, desto geringer ist die Leistungseinbuße. Sehr spezifische Ereignisse haben jedoch nur einen sehr spezifischen Anwendungszweck. Dagegen können unspezifische Ereignisse mithilfe von Bedingungen in der Aktivitätsdefinition eingeschränkt werden. Das Auswerten dieser Bedingungen ist jedoch aufwändi­ger als die Prüfung in der Anwendung, die das Ereignis auslöst. Bei der Ent­schei­dung, wie spezifisch ein Ereignis ist, sollte die Geschwindigkeit gegen die Ver­wendbarkeit des Ereignisses abgewogen werden. Für sehr spezifische Ereignisse sowie für Ereignisse, die eine aufwendige Auswertung in der Übergangsbedingung voraussetzen und öfters ausgelöst werden, wird daher empfohlen, im Rahmen einer Adaptierung ein eigenes programmiertes Ereignis zu implementieren.

Welche programmierten Ereignisse in Ihrem System vorhanden sind und in Aktivitätsdefinitionen verwendet werden, können Sie in der Anwendung Cockpit: Programmierte Ereignisse abfragen.

Ereignis Business Entity geändert

Die System-Engine löst das Ereignis Business Entity geändert beim Erfassen, Ändern oder Löschen einer Business-Object-Instanz aus. Mithilfe dieses vom Sys­tem bereitgestellten Ereignisses können einfache Aufgabenstellungen gelöst werden. Problematisch bei Ereignissen dieses Typs ist, dass sie relativ unspezi­fisch ausgelöst werden. Das heißt, dass bei jeder Änderung der Business-Object-Instanz ein Ereignis ausgelöst wird. Dieses Ereignis ist nicht immer ursächlich mit einem spezifischen betriebswirtschaftlich motivierten Vorgang verknüpft. Im Allgemeinen soll aber auf ganz bestimmte Vorgänge reagiert werden. Das ist einer der Gründe, weshalb eine Aktivitätsdefinition mit einer Übergangsbe­din­gung mit dem Ereignis verknüpft werden kann.

Aus der Aktivitätsdefinition wird nur dann eine Aktivität erstellt, wenn das betref­fende Ereignis eintritt und die Übergangsbedingung erfüllt ist. Für die Auswer­tung des Ereignisses, das heißt insbesondere auch für die Übergangs­bedingung, sind der alte und neue Status des geänderten Objekts zugreifbar.

Der Ereignisparameter oldObjectenthält eine Kopie der Business Object-Instanz unmittelbar vor der Datenbanktransaktion, die zum Auslösen des Ereignisses geführt hat. Der Ereignisparameter newObjectenthält eine Kopie der Business Object-Instanz unmittelbar nach der Datenbanktransaktion. Der Parameter objectverweist auf die Business Object-Instanz. Die Verwendung von objectführt daher zu einem Vergleich mit dem zum Zeitpunkt der Auswertung aktuellen Zustand der Business Object-Instanz. Da Ereignisse asynchron verarbeitet werden, ist es wichtig, die für die Aufgabenstellung passenden Ereignisparameter in der Übergangsbedingung zu verwenden.

Mehrsprachfähige Attribute werden in der für die Datenbank eingestellte Sprache übergeben. Wird z. B. die Bezeichnung eines Artikels in einer der installierten Nebensprache geändert, wird zwar das Ereignis Business Entity mit dem Subtyp Ändern ausgelöst, aber parameters.oldObject:descriptionund parameters.newObject:descriptionbesitzen beide den gleichen Wert, nämlich die Bezeichnung in der Hauptsprache der Datenbank.

Besonders beim Erstellen von Prozessdefinitionen und Aktivitätsdefinitionen kann es nützlich sein, ein ausgelöstes Ereignis mithilfe der Funktion echozu protokollieren, um sicherzustellen, dass das Ereignis erwartungskonform ausgelöst wurde. Da die Funktion echoimmer den Wert truezurückgibt, könnte die Übergangsbedingung in vorherigen Beispiel wie folgt erweitert werden:

echo(definition:code) and echo("transition condition") and echo(event) and (parameters.oldObject:status <> parameters.newObject:status)

Der Befehl echogibt das Ereignis in die Protokolldatei auf dem Application-Server aus, wo das Ereignis ausgelöst wurde. Wird echoin einer Vorbedingung verwendet, dann erfolgt die Ausgabe in die Protokolldatei auf dem Application-Server, wo die Workflow-Engine bzw. der Scheduler läuft. Der Parameter definitionreferenziert die Aktivitätsdefinition. Die Prozessdefinition kann z. B. über die Beziehung definition->ProzessDefinitionreferenziert werden. In der Funktion createkann auch die für die Aktivitätsinstanz gezogene Nummer activity:numberabgefragt werden. In einem Startknoten steht die Nummer des Prozesses noch nicht zur Verfügung, da beim Aufruf der Funktion createdie Prozessinstanz noch nicht erzeugt wurde.

Ein Ereignis vom Typ Business Entity unterscheidet zwischen dem den s. g. Subtypen Einfügen, Ändern und Löschen einer Business Object-Instanz. Wählen Sie daher den für die Aufgabenstellung passenden Subtyp in der Aktivitätsdefinition. In derselben Aktivitätsdefinition können Sie auch unterschiedliche Subtypen für dasselbe Business Object auswählen.

Beachten Sie, dass ein Ereignis mit dem Subtyp Löschen nur dann ausgelöst wird, wenn eine Business Object-Instanz aus der Datenbank gelöscht wird. Für Business Objects, für die ein Löschkennzeichen gesetzt werden kann (wie z. B. das Business Object Partner) bedeutet dies, dass ein Ereignis mit dem Subtyp Löschen erst bei der Partner-Reorganisation ausgelöst wird. Möchten Sie auf das Setzen des Löschkennzeichens reagieren, dann können Sie z. B. folgende Übergangsbedingung für ein Ereignis mit dem Subtyp Ändern verwenden:

isNull(parameters.oldObject.updateInfo.deleteUser) and not isNull(parameters.newObject.updateInfo.deleteUser)

Da das Löschkennzeichen in den Attributen updateInfo.deleteUserund updateInfo.deleteTimefestgehalten wird, ist diese Übergangsbedingung erfüllt, wenn die geänderte Business Object-Instanz kein Löschkennzeichen vor, aber ein Löschkennzeichen nach der Änderung hatte.

Einige Belegdokumente werden mithilfe mehrerer Datenbanktransaktionen erzeugt. So wird z. B. eine Ausgangsrechnung zuerst ohne eine Nummer erzeugt. Erst in einer weiteren Datenbanktransaktion wird eine Belegnummer aus dem Nummernkreis gezogen und in der Ausgangsrechnung gespeichert. Soll z. B. eine Benachrichtigung für erzeugte Ausgangsrechnungen mit einem Bruttobetrag, der 10.000 Euro übersteigt erfolgen, und die Aktivitätsdefinition reagiert auf das Ereignis mit dem Subtyp Einfügen, dann ist es wahrscheinlich, dass zum Zeitpunkt der Auswertung die Nummer der Ausgangsrechnung noch unbekannt ist. Damit die Benachrichtigung erst dann erfolgt, wenn die Ausgangsrechnung komplett erzeugt ist, kann die Aktivitätsdefinition auf das Ereignis mit sowohl dem Subtyp Einfügen als auch Ändern reagieren. Die Übergangsbedingung des Ereignisses mit dem Subtyp Einfügen

parameters.newObject:number<>""und die Übergangsbedingung des Ereignisses mit dem Subtyp Ändern

parameters.oldObject:number="" and parameters.newObject:number<>""stellen sicher, dass nur eine Benachrichtigung erfolgt.

Manche Belegdokumente werden blockweise verarbeitet. So wird z. B. ein Vertriebsauftrag in Blöcken von 16 Positionen verarbeitet. Jeder Block von 16 Positionen stellt eine eigene Datenbanktransaktion dar. Sie können dies z. B. daran erkennen, dass nach dem Erfassen von 16 Vertriebsauftragspositionen, der Vertriebsauftrag automatische gespeichert wird. Ein anderer Hinweis auf die blockweise Verarbeitung ist, wenn das Attribut statusBackupim Business Object des Belegs vorhanden ist. Soll der Status eines Belegdokuments geändert werden und das Belegdokument besitzt mehr Positionen, als in einem Block verarbeitet werden können, dann wird das Belegdokument mit dem ersten Block in den Status Ungültig überführt, und der bisherige Status wird im AttributstatusBackupgespeichert. Erst mit der Verarbeitung des letzten Blocks wird das Belegdokument in den neuen Status Freigegeben überführt und der Wert im Attribut statusBackupgelöscht.

Eine mögliche Übergangsbedingung für eine Aktivitätsdefinition, die auf einen Statuswechsel eines Belegdokuments von z. B. In Bearbeitung (1) auf den neuen Status Freigegeben (2) reagieren soll, könnte daher wie folgt aussehen:

(parameters.oldObject:status=1 and parameters.newObject:status=2) or
(parameters.oldObject:status=6 and parameters.newObject:status=2 and parameters.oldObject:statusBackup=1)

Der zweite Teil der Übergangsbedingung prüft, ob der Status von dem Wert Ungültig (6) auf Freigegeben (2) wechselt und der im Attribut statusBackupgespeicherte bisherige Status In Bearbeitung (1) ist. Der besseren Übersicht halber könnte die Übergangsbedingung auch auf zwei Ereignisse mit dem Subtyp Ändern aufgeteilt werden.

Das Ereignis „Business Entity geändert“ kann auch auf Dependents des Business Entitys angewendet werden. In diesem Fall sind zusätzlich zu dem alten und neuen Status des geänderten Dependents (in den Parametern oldObjectund newObject) auch der alte und neue Status des zugehörigen Business Entitys (in den Parametern oldEntityund newEntity) verfügbar. Welche Parameter Ereignisse vom Typ Business Entity besitzen, können Sie im Kapitel Informationsauswertung der Dokumentation Einführung: System-Skriptsprache nachlesen.

Entsteht bei der Auswertung der Übergangsbedingung ein Fehler, dann gilt die Übergangsbedingung als nicht erfüllt. In diesem Fall wird also keine Aktivität erzeugt. Im Gegensatz dazu gilt eine Vorbedingung mit einem Fehler als erfüllt. Konnte eine Aktivität erfolgreich erzeugt werden, dann führt ein Fehler in der Vorbedingung nicht zu einem automatischen Erledigen der Aktivität ohne Änderung.

Das Ereignis Business Entity geändert ist meist relativ unspezifisch. Wenn Sie dieses Ereignis nutzen, sollten Sie die Leistungsfähigkeit des Gesamtsystems berücksichtigen.

Wenn eine Aufgabenstellung mit dem Ereignis Business Entity geändert zu sehr großen Geschwindigkeitseinbußen führt, kann möglicherweise ein spe­zielles programmiertes Ereignis das Problem effizienter lösen. Programmierte Ereignisse bedeuten jedoch immer Anpassungsprogrammierung und somit einen höheren Aufwand in der Erstellung und Wartung.

Welche Ereignisse vom Typ Business Entity in Ihrem System in Aktivitätsdefinitionen verwendet werden, können Sie mithilfe der Detailsuche Ereignisdefinitionen in der Anwendung Cockpit: Aktivitätsdefinitionen ermitteln.

Ereignis Benutzeraktion

Ein Ereignis vom Typ Benutzeraktion wird ausgelöst, wenn ein Benutzer einen Prozess über den Eintrag Prozess starten im Kontextmenü eines Business Entitys startet. Der Typ Benutzeraktion steht nur in Aktivitätsdefinitionen zur Verfügung, die ein Startereignis oder ein Zwischenereignis einer Prozessdefinition darstellen. Für den Eintrag im Kontextmenü wird die Bezeichnung der Prozessdefinition verwendet.

Ist die Übergangsbedingung nicht erfüllt, kann der Prozess nicht gestartet werden und der entsprechende Eintrag im Kontextmenü des Business Entitys ist deaktiviert. Folgende Übergangsbedingung unterbindet die Benutzeraktion in einem Vertriebsauftrag mit dem Status In Bearbeitung (1):

parameters.object:status<>1

Wird der Prozess im Kontextmenü des Benutzers nicht angezeigt, dann kann die Ursache sein, dass die Prozessdefinition nicht aktiviert ist. Ist die Prozessdefinition mit einer Prozessdefinitions-Vorlage verknüpft, bei der eine Anwendung der besonderen Verwendung Prozessdefinition hinterlegt ist, dann kann es auch daran liegen, dass der Benutzer nicht berechtigt ist, diese Anwendung zu öffnen.

Eine Benutzeraktion kann auch mithilfe von Workflowrollen berechtigt werden. Beispielsweise führt folgende Übergangsbedingung dazu, dass nur Inhaber der Workflowrolle MANAGERS den Prozess starten können. Bei allen anderen Benutzern ist der Eintrag im Kontextmenü deaktiviert:

contains(resolveRole("MANAGERS"), parameters.userGuid)Liefert die Auswertung der Übergangsbedingung den Wert null zurück, dann gilt die Übergangsbedingung als nicht erfüllt, und der Prozess kann nicht gestartet werden. Führt die Auswertung der Übergangsbedingung zu einem Laufzeitfehler, dann wird gleich beim Auswählen des Eintrags im Kontextmenü eine Fehlermeldung angezeigt.

Individuelle Meldungen können in der Funktion validateausgegeben werden, da diese Funktion auch dann aufgerufen wird, wenn die Aktivitätsdefinition keine Ergebnisse besitzt. Eine Warn- oder Fehlermeldung in der Funktion createverhindert dagegen immer das Starten.

Welche Parameter Ereignisse vom Typ Benutzeraktion besitzen, können Sie im Kapitel Informationsauswertung der Dokumentation Einführung: System-Skriptsprache nachlesen.

Welche Aktivitätsdefinitionen ein Ereignis vom Typ Benutzeraktion in Ihrem System verwenden, können Sie mithilfe der Detailsuche Ereignisdefinitionen in der Anwendung Cockpit: Aktivitätsdefinitionen abfragen.

Kein Ereignis

Eine Aktivitätsdefinition ohne Ereignisdefinition reagiert nicht auf ein Ereignis. Folglich werden auch keine Aktivitäten erzeugt. Stellt die Aktivitätsdefinition den Startknoten eines Prozesses dar, dann kann der Prozess nur manuell gestartet werden. Da ein solcher Prozess keine Übergangsbedingung besitzt, kann die Aktivitätsdefinition nur mithilfe von einer Prozessdefinitions-Vorlage und einer Anwendung der besonderen Verwendung Prozessdefinition berechtigt werden.

Wie auch bei einem Ereignis vom Typ Benutzeraktion können individuelle Meldungen in der Funktion validateausgegeben werden. Eine Warn- oder Fehlermeldung in der Funktion createverhindert dagegen immer das Starten. Wird der Prozess über die Anwendung Prozesse manuell gestartet, werden eventuelle Meldungen vom Typ Information dem Benutzer nicht angezeigt, da das andockbare Fenster Meldungen beim Laden der gestarteten Prozessinstanz geleert wird.

Welche Parameter beim Starten von einem Prozess ohne ein Ereignis zur Verfügung stehen, können Sie im Kapitel Informationsauswertung der Dokumentation Einführung: System-Skriptsprache nachlesen.

Hintergrundanwendung Ereignisse Auslösen

Die Hintergrund-Anwendung Ereignisse auslösen (com.cisag.sys.workflow.log.EventGenerator) löst das Ereignis Durch Hintergrundanwendung “Ereignisse auslösen” ausgelöstes Ereignis com.cisag.pgm.workflow.InstanceEventfür alle durch eine OQL-Anweisung ausgewählten Business-Object-Instanzen aus. Die Hintergrund-Anwendung kann mithilfe eines Verarbeitungsauftrags einmalig oder z. B. gemäß eines Serienmusters 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. Weitere Informationen erhalten Sie in der Dokumentation Ereignisse auslösen.

Die Workflow-Engine prüft die Übergangsbedingung aller Aktivitätsdefinitionen, die auf das ausgelöste Ereignis mit dem gleichen Subtyp reagieren. Reagieren z. B. 10 Aktivitätsdefinitionen auf das Ereignis Ereignis für OLTP-Datenbank auslösen com.cisag.pgm.workflow.GenericOLTPEventohne einen Subtyp (Subtyp 0) und das Ereignis wird durch die Hintergrundanwendung Ereignisse auslösen (com.cisag.sys.workflow.log.EventGenerator) für 1.000 Kunden ausgelöst, dann werden 10.000 Übergangsbedingungen ausgewertet. Dies kann zu erheblichen Leistungseinbußen und Verzögerungen zwischen dem Auslösen des Ereignisses und dem Erzeugen der Aktivität führen.

Ereignisse werden der Reihe nach ausgewertet, sie werden aber nicht in der Datenbank persistent gespeichert. Wird der Application-Server, auf dem das Ereignis ausgelöst wurde, heruntergefahren, bevor alle Ereignisse ausgewertet sind, gehen die nicht ausgewerteten Ereignisse verloren. Versuchen Sie daher, sowohl die Anzahl der Aktivitätsdefinitionen, die auf den gleichen Subtyp des Ereignisses reagieren, als auch die Anzahl der ausgelösten Ereignisse insgesamt zu minimieren. Statt in der Hintergrundanwendung Ereignisse auslösen ein Ereignis für jeden Kunden auszulösen und erst in der Übergangsbedingung zu entscheiden, ob eine Aktivität erzeugt werden soll oder nicht, ist es oft besser, Ereignisse möglichst zielgerecht auszulösen. Damit werden insgesamt weniger Ereignisse ausgelöst und die Übergangsbedingungen sind einfacher oder sogar leer. Wenn eine einfache Übergangsbedingung nicht per OQL abgebildet werden kann, dann kann anstatt der Hintergrundanwendung Ereignisse auslösen eine Prozessdefinition verwendet werden. Beispielsweise könnte ein Skriptknoten die Kunden auswerten und für jeden Kunden, für den eine Aktivität erzeugt werden soll, mithilfe der Funktion fireEventein Ereignis auslösen. Falls in Ihrem eingesetzten Release das Ereignis Ereignis für OLTP-Datenbank auslösen einen Subtyp anbietet, sollten Sie für jeden Anwendungsfall einen eigenen Subtyp verwenden, der auf dieses Ereignis reagiert.

Business Objects verändern

Workflow-Aktivitäten haben in der Regel nur lesenden Zugriff auf Business Objects. Sobald eine Aktivität eine Methode in Java aufruft, die versucht, eine Business Object-Instanz zu verändern, entsteht eine Ausnahmesituation (Exception) und die Aktivitätserzeugung bricht mit einem Fehler ab. Das Workflow-Management bietet mit den Workflow-Attributen und den benutzerdefinierten Feldern (weiteren Feldern) zwei Möglichkeiten, Informationen aus einer Aktivität dauerhaft in einem Business Object zu speichern. Diese zwei Möglichkeiten werden in diesem Kapitel beschrieben. Weitere Informationen zur Verwendung von Workflow-Attributen und benutzerdefinierten Feldern in Aktivitätsdefinitionen erhalten Sie in der Dokumentation System-Skriptsprache: OLTP-Funktionen.

Workflow-Attribute

Workflow-Attribute lassen sich auf einem System mit der Versionierungsstufe 7 und der Verwendung als Produktiv-Testsystem oder Produktivsystem erfassen. Dazu ist keine Programmierung und sind keine Programmierkenntnisse notwendig. Ähnlich wie ein benutzerdefiniertes Attribut wird auch ein Workflow-Attribut mithilfe eines Business Objects gespeichert, das mit dem Typ Managed Supplement klassifiziert ist.

Ein Managed Supplement mit benutzerdefinierten Attributen besitzt die Verwendung Standard und ein Managed Supplement mit Workflow-Attributen besitzt die Verwendung Workflow. Sie können beliebig viele solcher Workflow-Supplements erfassen. Workflow-Attribute auf mehrere Workflow-Supplements zu verteilen hat den Vorteil, dass wenn eine Aktivität Workflow-Attribute zum ersten Mal speichert und dadurch eine neue Instanz des Workflow-Supplements erzeugt, Workflow-Attribute, die zu anderen Workflow-Supplements gehören, nicht mit Standardwerten vorbelegt werden. Zu viele Workflow-Supplements für dasselbe Business Object zu erfassen, könnte die Leistung des Systems vermindern, da zusammen mit dem Business Object auch dessen Supplements von der Datenbank geladen werden. Wenn Workflow-Attribute für unterschiedliche Workflow-Prozesse im selben Workflow-Supplement erfasst sind, ist es von Vorteil, wenn jeder Workflow-Prozess über ein Workflow-Attribut verfügt, dessen Standardwert darauf hinweist, ob eine Prozessinstanz den Workflow-Attributen Werte zugewiesen hat oder nicht.

Ein Beispiel für ein solches Workflow-Attribut ist der Genehmigungsstatus eines Beschaffungsauftrags. Eine leere Zeichenkette bedeutet, dass noch kein Genehmigungsprozess für den Beschaffungsauftrag gestartet wurde. Startet der Benutzer den Genehmigungsprozess, dann sollte der Startknoten dem Workflow-Attribut einen Wert ungleich dem Standardwert zuweisen, wie z. B. In Prüfung. Anstatt einer Zeichenkette könnte der Genehmigungsstatus auch mit numerischen Werten abgebildet werden. In diesem Fall würde der Standardwert 0 bedeuten, dass noch kein Genehmigungsprozess für den Beschaffungsauftrag existiert, und der Wert 1 könnte bedeuten, dass sich der Beschaffungsauftrag in Prüfung befindet.

Workflow-Attribute können zu anpassbaren Anwendungen hinzugefügt und angezeigt werden, vorausgesetzt das Managed Supplement gehört zur Objektsicht der Anwendung. Anders als ein benutzerdefiniertes Attribut ist ein Workflow-Attribut nicht editierbar, weder in der Anwendung noch über den Import. Nur Aktivitätsdefinitionen können Workflow-Attributen einen Wert zuweisen. Somit gibt es eine klare Trennung der Zuständigkeiten zwischen den benutzerdefinierten Attributen und den Workflow-Attributen.

Benutzerdefinierte Felder

In vielen Anwendungen lassen sich in dem Karteireiter Weitere Felder benutzerdefinierte Felder anlegen, um Zusatzinformationen zu dem mit der Anwendung verknüpften Business Entity zu erfassen. Die benutzerdefinierten Felder sind grundsätzlich auf das jeweilige Business Entity (und ggf. eine bestimmte Ansicht) bezogen. Benutzerdefinierte Felder besitzen einen Feldtyp. Für jeden Feldtyp existieren entsprechende Funktionen in der System-Skriptsprache. Meist wird auch eine weitere Funktion für Feldtypen mit einer Werteliste angeboten. Die Funktionen sind in folgende Kategorien eingeteilt:

• Getter-Funktionen geben den Wert eines benutzerdefinierten Feldes zurück.
• Setter-Funktionen weisen einem benutzerdefinierten Feld einen Wert zu.
• Die Reset-Funktion setzt ein benutzerdefiniertes Feld auf dessen Standardwert zurück.
• Validate-Funktionen prüfen, ob ein Wert einem weiteren Feld zugewiesen werden darf oder nicht.

Wie die beiden Beispiele zeigen, setzt sich der Schemaname aus dem Präfix EXT gefolgt vom Namen des Business Entitys zusammen.

E-Mails versenden

Eine E-Mail-Nachricht ist eine E-Mail, die als Bestandteil eines Workflows versendet wird. Ein Beispiel einer E-Mail-Nachricht ist eine E-Mail, um einen Kunden über einen neuen Liefertermin zu informieren. Eine E-Mail-Benachrichtigung ist eine E-Mail, die beim Eintreten bestimmter Prozesszustände automatisch versendet wird, um die Prozessbeteiligten darüber zu informieren. Lesen Sie in diesem Kapitel, wie Sie den Versand von E-Mail-Nachrichten und E-Mail-Benachrichtigungen konfigurieren können.

E-Mail-Nachrichten

Aktivitätsdefinitionen vom Typ E-Mail-Nachricht, E-Mail-Knoten oder Interaktiver E-Mail-Knoten können E-Mail-Nachrichten versenden. Besitzt die Aktivitätsdefinition einen oder mehrere Benutzer als Bearbeiter, dann wird für jeden Benutzer eine E-Mail-Nachricht an die in der Anwendung Systemcockpit hinterlegte E-Mail-Adresse des Benutzers versendet. Ist in der Aktivitätsdefinition der Bearbeiter System ausgewählt, dann müssen Sie den Empfänger mithilfe des Befehls setMailRecipientsToangeben. Wahlweise können Sie auch die Befehle setMailRecipientsCCund setMailRecipientsBCCverwenden. Besitzt die E-Mail-Nachricht mehrere Empfänger, dann trennen Sie die E-Mail-Adressen durch ein Komma. Als Antwort-E-Mail-Adresse wird die in der Anwendung E-Mail-Server hinterlegte E-Mail-Adresse des als Standard gekennzeichneten E-Mail-Servers verwendet. Diese und weitere Merkmale der E-Mail-Nachricht lassen sich auch per Befehl in den Deklarationen angeben. Eine Beschreibung der Befehle für E-Mail-Nachrichten finden Sie in der Dokumentation System-Skriptsprache: Workflow-Funktionen.

Eine Aktivitätsdefinition vom Typ E-Mail-Nachricht erzeugt keine Aktivität. Da die Aktivität auch den Nachweis für die versendet E-Mail-Nachricht darstellt, ist eine Prozessdefinition mit einem E-Mail-Knoten zu bevorzugen, wenn ein Nachweis erforderlich ist.

Ist in der Aktivitätsdefinition ein anderer Bearbeiter als System ausgewählt, dann werden die E-Mails in der Inhaltssprache des jeweiligen Empfängers versendet. Ist der Bearbeiter System ausgewählt, dann wird die Standard-Sprache des Systems verwendet. Um eine E-Mail-Nachricht in der Sprache eines Partners, der kein Benutzer des Systems ist, zu versenden, können Sie die Befehle zum Ändern der Inhalts- und Anzeigesprachen verwenden. Folgendes Beispiel ändert die Anzeigesprache auf die Korrespondenzsprache des Partners 10010:

var language := loadPartner("10010")->Language:isoCode;
if (not isNull(language)) {
setNLSDisplayLanguage(language);
}

Die if-Bedingung bewirkt, dass die Anzeigesprache nur dann geändert wird, wenn im Partner eine Korrespondenzsprache hinterlegt ist. Eine Beschreibung der Funktionen zum Ändern der Anzeige- und Inhaltssprache sowie einige Verwendungsbeispiele finden Sie in der Dokumentation System-Skriptsprache: Allgemeine Funktionen.

E-Mail-Benachrichtigungen

Die Workflow-Engine kann die Benutzer über relevante Statusänderungen einer ihm zuge­ordneten Aufgabe benachrichtigen. E-Mails können zu den folgenden Zeit­punkten versendet werden:

• Wenn die Aktivität den Status Zu bearbeiten erhält, können E-Mail-Benachrichtigungen an alle Benutzer mit einer Aufgabe versendet werden.
• Wenn die Aktivität den Status Verspätet oder Verspätet in Bearbeitung erhält, können E-Mail-Benachrichtigungen an alle Benutzer versendet werden, die ihre Aufgabe noch nicht erledigt haben.
• Wenn die Aktivität den Status Verspätet oder Verspätet in Bearbeitung erhält, kann eine E-Mail-Benachrichtigung an den oder die Prozessverantwortlichen versendet werden.
• Wenn der Prozess den Status Verspätet erhält, dann kann eine E-Mail-Benachrichtigung an den oder die Prozessverantwortlichen versendet werden.
• Wenn im Prozess ein Fehler auftritt und der Prozess über den Fehlerknoten endet, dann kann eine E-Mail-Benachrichtigung an den oder die Prozessverantwortlichen versendet werden.
• Wenn im Prozess ein Fehler auftritt und der Prozess über den Fehlerknoten endet, dann kann eine E-Mail-Benachrichtigung an den oder die Workflow-Administratoren versendet werden.
• Wenn eine Aufgabe an einen anderen Benutzer weitergeleitet wird, dann kann eine E-Mail-Benachrichtigung an diesen Benutzer versendet werden.
• Wenn eine Aufgabe an einen anderen Benutzer weitergeleitet wird, dann kann eine E-Mail-Benachrichtigung an den ursprünglichen Benutzer versendet werden, um ihn über Statusänderungen der weitergeleiteten Aufgabe zu informieren.

Darüber hinaus kann eine Prozessdefinition auch weitere E-Mail-Knoten umfassen, die zu beliebigen Zeitpunkten oder beim Eintreten beliebiger Prozesszustände E-Mails an die Prozessbeteiligten versenden. Beispielsweise könnte ein E-Mail-Knoten den oder die Prozessverantwortlichen informieren, wenn ein Prozessschritt oder Checkpoint im Prozessverlauf zu spät erreicht wird und dadurch der gesamte Prozess zu eskalieren droht. Auch könnten Aktivitätsdefinitionen im Prozess Befehle wie setActivityWorkDurationund setActivityPriorityverwenden, um die geplante Bearbeitungsdauer oder die Priorität der zu erzeugende Aktivität mithilfe der Ausführungszeiten der bisherigen Prozessschritte zu berechnen. Wurde der vorherige Checkpoint zu spät erreicht, dann wird die Bearbeitungsdauer entsprechend verkürzt oder die Priorität erhöht.

Ob tatsächlich zu entsprechenden Zeitpunkten eine E-Mail-Benachrichtigung an einen Benutzer versendet wird, hängt sowohl von den Einstellungen in der Aktivitätsdefinition bzw. Prozessdefinition als auch von den Benutzereinstellungen des Empfängers ab.

In den Benutzereinstellungen kann für die OLTP-Datenbank und die Repository-Datenbank eingestellt werden, ob E-Mail-Benachrichtigungen versendet werden sollen und wenn ja, ab inklusive welcher Priorität.

Bei Aktivitätsdefinitionen wird durch die Einstellung Bearbeiter benachrichtigen und Bearbeiter nach Zeitüberschreitung benachrichtigen mit dem Wert Immer oder Nie die Benutzereinstellung nicht berücksichtigt. Die Aktivitätsdefinition und die Prozessdefinition bieten ähnliche Felder an, um auch den Prozessverantwortlichen und die Workflow-Administratoren zu benachrichtigen.

E-Mail-Vorlagen

Der Workflow versendet E-Mails im HTML-Format. Alle vom Workflow versen­deten E-Mails werden aus einer datenbankabhängigen E-Mail-Vorlage erzeugt, die mit kontextuellen Daten parametrisiert werden kann.

Ablageort

Die deutschsprachige Standard-E-Mail-Vorlage wird unter dem Namen Mailtemplate_de.html im Knowledge Store des aktuellen Systems abgelegt, und zwar im Order Documents/Workflow des Standard-Arbeitsbereichs, der wie die aktuelle Datenbank heißt. Für andere Sprachen muss der ISO-Code de im Dateinamen durch den gewünschten ISO-Code ersetzt werden. Der Know­ledge Store unterscheidet Groß- und Kleinschreibung. Daher muss die Datei genau die angegebene Schreib­weise haben.

Je nach Verwendungskontext werden andere Vorlagen für E-Mail-Benachrichtigungen verwendet. Existiert die Vorlage im Order Documents/Workflow nicht, dann wird eine Standardvorlage aus der Stringtable com.cisag.sys.workflow.template.MailTemplates verwendet.

Verwendungskontexte

Folgende Liste zeigt welche Vorlage in welchem Verwendungskontext verwendet wird:

• ActivityTimeoutTemplate – Diese Vorlage wird bei der Zeitüberschreitung einer Aktivität verwendet, um die Benutzer mit einer offenen Aufgabe darüber zu informieren. Diese Vorlage wird auch für eventuelle durch eine Folgeaktion hinzugefügte Bearbeiter verwendet. Konnte keine Vorlage gefunden werden, dann wird die Vorlage aus der Stringtable mit der Konstanten ACTIVITY_TIMEOUTverwendet.
• AdhocMailtemplate – Dies ist die Standardvorlage für Aktivitäten, die nicht durch die Workflow-Engine erzeugt, sondern von einem Benutzer erfasst wurden. Diese Vorlage kann daher Bezug auf den Erfasser der Aktivität nehmen. Konnte keine Vorlage gefunden werden, dann wird die Vorlage aus der Stringtable mit der Konstanten ADHOCverwendet.
• DelegationBeginMailtemplate –Diese Vorlage wird an den Vertreter bei dem Beginn einer Abwesenheit versendet. Diese Vorlage kann daher Parameter enthalten, die sich auf die Vertretung bzw. die Abwesenheit beziehen. Konnte keine Vorlage gefunden werden, dann wird die Vorlage aus der Stringtable mit der Konstanten DELEGATION_BEGINverwendet.
• DelegationEndMailtemplate – Diese Vorlage wird an den Vertreter versendet, wenn eine Abwesenheit beendet wird. Diese Vorlage kann daher Parameter enthalten, die sich auf die Vertretung bzw. die Abwesenheit beziehen. Konnte keine Vorlage gefunden werden, dann wird die Vorlage aus der Stringtable mit der Konstanten DELEGATION_ENDverwendet.
• MailOnlyMailtemplate –Dies ist die Standardvorlage für Aktivitäten, die aus einer Aktivitätsdefinition vom Typ E-Mail-Nachricht oder E-Mail-Knoten erzeugt wurden. Die Vorlage sollte keine Parameter enthalten, die sich auf die Aufgabe, die Aktivität oder den Prozess beziehen. Konnte keine Vorlage gefunden werden, dann wird die Vorlage aus der Stringtable mit der KonstantenMAIL_ONLYverwendet.
• Mailtemplate – Dies ist die Standardvorlage für Aktivitäten, die aus einer Aktivitätsdefinition erzeugt wurden und nicht mit einem Prozess verknüpft sind. Diese Vorlage sollte keine Parameter enthalten, die sich auf den Prozess beziehen. Die Vorlage wird beim Statuswechsel der Aktivität auf Zu bearbeiten verwendet, um die Benutzer mit einer Aufgabe darüber zu informieren. Konnte keine Vorlage gefunden werden, dann wird die Vorlage aus der Stringtable mit der Konstanten DEFAULTverwendet.
• ProcessErrorTemplate – Diese Vorlage wird beim Beenden eines Prozesses über den Fehlerknoten verwendet, um den Prozessverantwortlichen bzw. die Workflow-Administratoren darüber zu informieren. Diese Vorlage kann z. B. Parameter enthalten, die sich auf den Fehler beziehen. Konnte keine Vorlage gefunden werden, dann wird die Vorlage aus der Stringtable mit der Konstanten PROCESS_ERRORverwendet.
• ProcessMailtemplate – Dies ist die Standardvorlage für Aktivitäten, die aus einer Aktivitätsdefinition erzeugt wurden und Knoten eines Prozesses sind. Diese Vorlage kann daher Parameter enthalten, die sich auf den Prozess beziehen. Diese Vorlage wird beim Statuswechsel der Aktivität auf Zu bearbeiten verwendet, um die Benutzer mit einer Aufgabe darüber zu informieren. Konnte keine Vorlage gefunden werden, dann wird die Vorlage aus der Stringtable mit der Konstanten DEFAULTverwendet.
• ProcessTimeoutTemplate – Diese Vorlage wird bei der Zeitüberschreitung eines Prozesses verwendet, um den Prozessverantwortlichen darüber zu informieren. Konnte keine Vorlage gefunden werden, dann wird die Vorlage aus der Stringtable mit der Konstanten PROCESS_TIMEOUTverwendet.
• TaskTrackingTemplate – Diese Vorlage wird verwendet, um einen Benutzer, der eine Aufgabe weitergeleitet hat, über künftige Statusänderungen der Aufgabe zu informieren. Konnte keine Vorlage gefunden werden, dann wird die Vorlage aus der Stringtable mit der Konstanten TASK_TRACKINGverwendet.

Statusabhängige Vorlagen

In manchen Verwendungskontexten können auch statusabhängige Vorlagen verwendet werden. Beispielsweise kann eine andere Vorlage für weitergeleitete Aufgaben, als für Aufgaben, die durch die Workflow-Engine zugeteilt wurden, verwendet werden. Statusabhängige Vorlagen werden im gleichen Verzeichnis wie die anderen Vorlagen abgelegt, jedoch wird dem Namen der konstante Wert des jeweiligen Status drangehängt.

Folgende Vorlagen unterstützen statusabhängige Namen:

• AdhocMailtemplate
• Mailtemplate
• ProcessMailtemplate

Auswahl der Sprache

Die Anzeigesprache des Benutzers entscheidet darüber, welche Vorlagendatei verwendet wird. Existiert keine Vorlagendatei für den Verwendungskontext in der Anzeigesprache des Benutzers, dann wird die Vorlagendatei in der Anzeigesprache des Systems verwendet.

Befehl setMailTemplate

Mithilfe des Befehls setMailTemplatein den Deklarationen einer Aktivitätsdefinition können Sie eine beliebige E-Mail-Vorlage verwenden. Genau wie bei den Standardvorlagen müssen auch die eigenen Vorlagen im Ordner Documents/Workflow im Knowledge Store des aktuellen Systems abgelegt sein und der Name mit einem Unterstrich und dem ISO-Code der Sprache enden.

Die Anzeigesprache des Benutzers entscheidet darüber, welche der möglichen Vorlagendateien mit dem angegebenen Namen verwendet wird. Wird der Name Standard an den Befehl übergeben und in den Benutzereinstellungen ist Englisch (en) als Anzeigesprache hinterlegt, dann wird die Vorlagendatei Standard_en.html verwendet. Ist in den Benutzereinstellungen des Empfängers eine Inhaltssprache hinterlegt, für die es keine Vorlagendatei mit dem angegebenen Namen gibt, dann wird die Vorlagendatei für die Standard-Sprache des Systems verwendet. Der Befehl setMailTemplatefunktioniert nicht nur in Aktivitätsdefinitionen der Aktivitätstypen E-Mail-Nachricht, E-Mail-Knoten und Interaktiver E-Mail-Knoten, sondern gilt in allen Aktivitätstypen für E-Mail-Benachrichtigungen durch die Workflow-Engine.

Um keine E-Mail-Vorlage zu verwenden, übergeben Sie eine leere Zeichenkette an den Befehl wie folgt:

setMailTemplate("")In diesem Fall wird die E-Mail-Vorlage mit der Konstanten EMPTYaus der Stringtable com.cisag.sys.workflow.template.MailTemplates verwendet. Wird eine nicht vorhandene E-Mail-Vorlage übergeben, dann wird die Standard-E-Mail-Vorlage aus der Stringtable com.cisag.sys.workflow.template.MailTemplates mit der Konstanten DEFAULTverwendet.

HTML-Formatierung

Sie können HTML-Tags verwenden, um die E-Mail-Vorlage zu formatieren. Eine E-Mail-Vorlage auf Deutsch könnte z. B. wie folgt aussehen:

<html>
<title>Neue Aufgabe: {$code} {$subject}</title>
<body>
<p>Hallo {$recipient},</p>
<p>Sie Sind der neue Bearbeiter der Aufgabe <a href="{$workitemUrl}">{$subject}</a> im Status &quot;{$state}&quot;.</p>
<p>Die Aufgabe soll mit der Priorit&auml;t &quot;{$priority}&quot; bearbeitet und bis {$endTime} erledigt werden. Weitere Informationen entnehmen Sie bitte der Aktivit&auml;t<a href="{$activityUrl}">{$code}</a> sowie folgender Aufgabenbeschreibung:</p>
<p><dir>{$description}</dir></p>
</body>
</html>

Die URLs müssen direkt als URL, z. B. in einer Referenz, eingetragen werden.

Der Titel der HTML-Seite wird als Betreff der versendeten E-Mail verwendet. Der Parameter descriptionhat einen HTML-Inhalt. Der Inhalt dieses Parame­ters kann eigene HTML-Formatierungen enthalten. Verwenden Sie hierzu den Befehl formatDescriptionHTML. Eine ausführliche Beschreibung des Befehls finden Sie in der Dokumentation System-Skriptsprache: Workflow-Funktionen.

Vorlagenparameter

Wie das Beispiel in Kapitel HTML-Formatierung zeigt, können E-Mail-Vorlagen Parameter wie z. B. {$subject}enthalten. Die Parameter wer­den in geschweiften Klammern mit führendem Dollarzeichen angegeben. Die umgebende Formatierung bestimmt auch, wie der Text bzw. der Inhalt des Parameters formatiert wird.

Die folgende Liste zeigt Parameter, die sich auf Aufgaben beziehen:

• actionUrl – URL, die die Aktion [Öffnen] für die Aufgabe ausführt. Dabei wird jedoch nicht, wie bei [Öffnen] üblich, in den Workflow-Modus gewechselt.
• forwardUser – Vollständiger Name des Benutzers, der die Aufgabe weitergeleitet hat.
• forwardText – Beim Weiterleiten der Aufgabe erfasster Text.
• oldState – Status der Aufgabe unmittelbar vor dem Ereignis, welches zum Versenden der Benachrichtigung geführt hat.
• state – Status der Aufgabe.
• user – Vollständiger Name des Bearbeiters der Aufgabe.
• workitemUrl – URL, die die Aktion [Öffnen] für die Aufgabe ausführt.

Die folgende Liste zeigt Parameter, die sich auf Aktivitäten beziehen:

• activityUrl – URL, die die Aktion [Aktivität] für die Aufgabe ausführt.
• code – Nummer der Aktivität.
• createUser – Vollständiger Name des Benutzers, der die Aktivität erfasst hat. Dieser Parameter kann z. B. für die Benachrichtigung bei einer manuell erfassten Aktivität verwendet werden.
• database – Name der Datenbank, in der das Ereignis ausgelöst wurde, welches zum Versenden der Benachrichtigung geführt hat.
• definition – Name der Aktivitätsdefinition.
• description – Beschreibung der Aktivität mit Formatierungen.
• endTime – Ende des Bearbeitungszeitraumes der Aktivität.
• priority – Priorität der Aktivität.
• startTime – Beginn des Bearbeitungszeitraumes der Aktivität.
• subject – Betreff der Aktivität.

Die folgende Liste zeigt Parameter, die sich auf Prozesse beziehen:

• processUrl – URL, die die Aktion [Prozess] für die Aufgabe ausführt.
• processCode – Nummer des Prozesses.
• processSubject – Betreff des Prozesses.
• processInitiator – Auslöser des Prozesses.
• processOwner – Prozessverantwortlicher.
• processComments – Anzahl der Kommentare, die für den Prozess erfasst sind.
• processStartTime – Beginn des Bearbeitungszeitraumes des Prozesses.
• processEndTime – Ende des Bearbeitungszeitraumes des Prozesses.
• processError – Beschreibung der Fehlerursache, wenn ein Prozess über den Fehlerknoten beendet wird.
• definition – Name der Aktivitätsdefinition.

Die folgende Liste zeigt Parameter, die sich auf den Empfänger der E-Mail-Nachricht beziehen:

• greeting – Persönliche Begrüßung für den Benutzer, an den die Benachrichtigung versendet wird.
• recipient – Vollständiger Name des Benutzers, an den die Benachrichtigung versendet wird.
• valediction – Persönliche Abschlussformel für den Benutzer, an den die Benachrichtigung versendet wird.

Die folgende Liste zeigt Parameter, die sich auf eine Abwesenheit beziehen:

• absentWorker – Der Benutzer, dessen Abwesenheit beginnt oder endet.
• delegatedWorkitems – Anzahl offener Aufgaben des abwesenden Benutzers, die in Delegation verarbeitet werden können.
• endOfDelegation – Ende der Abwesenheit.
• startOfDelegation – Beginn der Abwesenheit.

Benachrichtigung bei Prozesskommentaren

Bei dem Erfassen eines neuen Kommentars in einem Prozess bietet der Aktionsdialog drei Checkboxen an, um die Inhaber folgender Prozessrollen zu benachrichtigen:

• Prozessverantwortlicher
• Auslöser
• Beteiligte

Die Benachrichtigung erfolgt in diesem Falle nicht mithilfe von Standard-E-Mail-Vorlagen. Stattdessen löst die Anwendung das programmierte Ereignis com.cisag.pgm.workflow.ProcessCommentCreatedaus. Das Ereignis wird einmal für jeden Inhaber der ausgewählten Prozessrollen ausgelöst. Der Ereignisparameter recipiententhält die GUID des Benutzers, der benachrichtigt werden soll. Weitere Parameter enthalten Informationen zum Erfasser, zum Kommentar und zu der Prozessinstanz.

• creator – GUID des Benutzers, der den Kommentar erfasst hat.
• processDefinition – Identifikation (Code) der Prozessdefinition.
• recipient – GUID des Benutzers, der benachrichtigt werden soll.
• comment – Referenz auf den Prozesskommentar (Business Object com.cisag.sys.workflow.obj.ProcessComment).
• process – Referenz zu der Prozessinstanz (Business Object com.cisag.sys.workflow.obj.Process).
• startNode – Referenz zum Startknoten (Business Object com.cisag.sys.workflow.obj.Activity).

Konfiguration

In diesem Kapitel werden relevante Einstellungen für das Workflow-Management beschrieben. Für eine Beschreibung der Einstellungen der System-Skriptsprache lesen Sie bitte die Dokumentation Einführung: System-Skriptsprache. Für eine Beschreibung der Customizing-Einstellungen lesen Sie die Dokumentation Funktion: Workflow-Management.

Aktivitäts-Scheduler auf einem beliebigen ERP-System-Application-Server

Zu Testzwecken kann der Aktivitäts-Scheduler auf einem anderen Application-Server (SAS) als dem Message-Server gestartet werden. Für den produktiven Einsatz wird dies nicht empfohlen. Insbesondere zur Kontrolle von Debug-Ausgaben durch den Befehl echokann es jedoch in einem Test- oder Entwicklungssystem hilfreich sein, den Scheduler auf einem lokalen Application-Server zu starten. Auf dem Message-Server wird der Scheduler angehalten, wenn auf einem anderen Application-Server ein Scheduler gestartet wird. Sobald der Application-Server mit dem Scheduler been­det wird, nimmt der Scheduler auf dem Mes­sage-Server seine Arbeit wieder auf. Nur ein Application-Server im System kann den Sche­du­ler vom Message-Server übernehmen.

Die Option workflowEngineMaster bewirkt beim Starten eines Application-Servers, dass der Sche­duler auf diesem Application-Server läuft. Beim Message-Server ist diese Angabe nicht not­wendig.

Ziel-Server für Verknüpfungen

Die vom Workflow versendeten E-Mails können Verknüpfungen (Links) auf Aufgaben, Aktivitäten und beliebige Business Entitys enthalten. Sie können konfigurieren, auf welchen Application-Server diese Verknüpfungen zeigen sollen, d. h. auf welchem Server die Verknüpfung ausgeführt werden soll.

In Systemen mit einem Application-Server ist keine weitere Konfiguration notwendig. Der Ziel-Server ist der Application-Server, auf dem die Workflow-Engine läuft.

Wenn ein System mehrere Application-Server umfasst, tragen Sie bei allen Application-Servern im Feld Ziel-Server für Link-Attribute einen Dialog-Application-Server ein. Dieser Server wird für alle Verknüpfungen in Workflow-E-Mails verwendet, die vom Message-Server versendet werden.

Wenn der Ziel-Server abhängig von dem Benutzer ist, dann können Sie mithilfe der Workflow-Rollen benutzerspezifische Ziel-Server zuordnen.

Maximale Anzahl an Aktivitäten

Enthält eine Prozessdefinition eine Schleife, sodass der Prozessfluss von einer Aktivitätsdefinition zurück auf dieselbe Aktivitätsdefinition geleitet werden kann, dann könnte eine fehlerhafte Übergangsbedingung auf dem Karteireiter Übergänge dazu führen, dass die Workflow-Engine immer mehr Aktivitäten für den Prozess erzeugt, bis die Datenbank voll wird und das System abstürzt.

Um dies zu verhindern wird die Anzahl der Aktivitäten in einem Prozess auf 1.000 begrenzt. Versucht der Prozess mehr Aktivitäten zu erzeugen, dann endet der Prozess über den Fehlerknoten mit den Fehler „WFL-00582 Die maximale Anzahl an Aktivitäten ist überschritten.“

Bei Bedarf kann die maximale Anzahl der Aktivitäten mithilfe der Property com.cisag.sys.workflow.process.MaxActivitiesgeändert werden.

Aktivitätsinformationen anpassen

Die Anwendung Aktivitätsinformationen liefert einen einfachen und schnellen Überblick über eine Workflow-Aktivität in einem andockbaren Fenster. Die Anwendung wird automatisch geöffnet, wenn eine Aufgabe geöffnet wird und die übergeordnete Aktivität mit einer Anwendung oder einem Business Object verknüpft ist. Dadurch bleiben sowohl das zu bearbeitende Business Object als auch die wichtigsten Informationen zur Aktivität immer sichtbar. Das Layout der Anwendung und damit auch die angezeigten Felder können mit der anpassbaren Oberfläche verändert werden.

Die Anwendung Aktivitätsinformationen ist zwar anpassbar, aber wird sie als andockbares Fenster geöffnet, lässt sie sich nicht anpassen. Um die Anwendung anzupassen, öffnen Sie die Anwendung mit einem Application-Server, der folgende Property verwendet:

com.cisag.pgm.base.CisInfoApplicationOpenDialog=NeverUm die Anwendung als andockbares Fenster zu öffnen, verwenden Sie den Wert Always:

com.cisag.pgm.base.CisInfoApplicationOpenDialog=AlwaysBesitzt die Property den Wert Always, dann verwendet das andockbare Fenster die mit Standard gekennzeichnete Anwendungsansicht.