Die DPE (Dynamic Process Engine) stellt eine dynamische Workflowkompente zur Verfügung.

Wie nachfolgende Abbildung verdeutlicht, gibt es drei grundlegende Workflow-Modelle:

• den sequentiellen Workflow, bei dem die einzelnen Prozessschritte mehr oder weniger starr nach einem vorgegebenen Schema definiert sind
  • der Prozess hat einen definierten Anfang und ein definiertes Ende
  • der Prozess ist klar definiert und Änderungen kommen nur selten vor

• den zustandsgesteuerten Workflow, bei dem die einzelnen Prozesszustände lose miteinander verknüpft werden
  • Schnelle Reaktionsfähigkeit bei Ausnahme- und Sonderfällen des Geschäftsalltages
  • Einfacher Ausbau des Workflows um auf neue Ereignisse reagieren zu können (z.B. die Erfassung von Aufträgen soll künftig auch direkt vom Kunden über das Internet – neue Ereignisquelle – ermöglicht werden)

• den regelbasierten Workflow, der es ermöglicht nach unterschiedlichen Regeln verschiedene Aktivitäten durchzuführen
  • Additiv: zu den bestehenden Standardregeln kommen zusätzliche Regeln hinzu
  • Alternativ: anstatt der bestehenden Standardregeln werden neue Regeln definiert und ausgeführt

Die DLE/DPE vereint die beiden Workflowkonzepte „zustandsgesteuerter“ und „regelbasierter“ Workflow.

Die DPE ist somit speziell für Branchen, Organisationen und Prozessumfelder mit hoher Dynamik und hochgradigen Ansprüchen, was Flexibilität bzgl. Änderungen und Erweiterungen betrifft, entwickelt worden. Im Folgenden wird auf den zustandsgesteuerten Workflow näher eingegangen. Der regelbasierte Workflow wird im Kapitel „Bricks und Ordner“ eingehend diskutiert.

Die Grundelemente jedes Zustandsmodells sind Zustände, Ereignisse, Aktionen und Transitionen (Statusübergänge). Einzelne Objekte - in der DPE als Todos (Aufgaben) bezeichnet – können verschiedene Zustände annehmen. Beispielsweise kann eine Todo den Zustand „Offen“, „In Bearbeitung“, „Abgeschlossen“, usw. haben. Ist eine Todo in einem bestimmten Zustand, können verschiedene Ereignisse (manuell, zeitgesteuert, regelgesteuert, …) auf diese Todo einwirken und Aktionen auslösen. Die Aktionen können dann zu einer Transition (Zustandsänderung) führen (oder auch nicht). D.h., die Todo geht beispielsweise vom Zustand „Offen“ in den Zustand „In Bearbeitung“ über.

Nachfolgendes Beispiel soll dies nochmal verdeutlichen. Es zeigt die Abbildung von Zuständen und Aktionen eines zustandsbasierenden Workflows in der DPE. Das Beispiel beschreibt den Prozess eines Qualitätsmanagementsystems. Das essentielle Objekt (Todo) des Systems ist vom Typ Fehler. Ein Fehler kann, wie das Zustandsdiagramm zeigt, mehrere Stati haben (Offen, In Abklärung, In Nacharbeit, Erledigt). Wird ein Fehler erfasst, ist dieser zunächst im Zustand „Offen“. Von einem Zustand können nun verschiedene Aktionen ausgeführt werden. Hinter jeder Aktion steht ein Brick (Programmierbaustein) der ein Fehlerobjekt je nach Bricklogik (prüft ob alle notwendigen Bedingungen erfüllt sind) in einen anderen Zustand bringt oder auch nicht (Abklären, Sonderfreigabe, …). Neben Aktionen die eine Zustandsänderung nach sich ziehen, gibt es auch Aktionen die den Zustand eines Fehlerobjektes nicht ändern. Beispiele hierfür sind die Aktionen „Drucken“, „Dokumente Anzeigen“, etc.

Innerhalb der DPE lassen sich zustandsgesteuerte Prozesse, wie in folgender Darstellung ersichtlich, eins zu eins aus einem Prozessschaubild abbilden. Die Informationen die in der DPE zur Abbildung benötigt werden sind: der Todo-Typ (z.B. Fehler-Objekt, Auftrag, …), die möglichen Stati, die eine Todo annehmen kann, sowie die Aktionen die für jeden Status möglich sind. Die eigentliche Logik der Aktionen (welche Bedingungen müssen erfüllt sein, damit eine Aktion ausgeführt wird) wird in Bricks hinterlegt.

Innerhalb der DPE bilden die Todos (Aufgaben) den Kernpunkt. Eine Todo wird durch die DLE beim Durchlaufen eines Bricks erstellt und ist an einen Adressaten, die ausführende Organisationseinheit, gerichtet. Bei dem Adressaten kann es sich dabei um eine organisatorische Einheit (Abteilung, Gruppe, etc.) handeln. Sie kann aber auch an die DPE selber gerichtet sein. In diesem Fall wird die DPE automatisch zu dem gewünschten Durchführungszeitpunkt diese Todo abarbeiten. Dies geschieht, indem zu dem entsprechenden Zeitpunkt wiederum die DLE aufgerufen wird, die dann mit der normalen Brickausführung für ein Todo dynamische Logik abarbeitet. So lassen sich sehr einfach wiederkehrende Aufgaben und zeitversetzte Prüfungen realisieren.

Gleiches gilt für die Abarbeitung durch Personen. Anhand einer Todo Liste, die alle für eine Person offenen Todos enthält, wählt der Benutzer die für die Aufgabe durchzuführende Aktion und ruft damit wiederum die DLE auf.

Auf diese Weise lassen sich einfach und schnell dynamische Prozessabläufe erstellen, die flexibel an sich ändernde Anforderungen anpassbar sind.

Nachfolgendes Beispiel soll die Arbeitsweise der DPE verdeutlichen. Bei dem Beispiel handelt es sich um einen Geschäftsfall aus der Logistikbranche. Mit der DPE sollen Termine die auf Sendungen hinterlegt sind, geprüft werden.
Sendungen (Aufträge) müssen beim Spediteur auf die einzelnen LKWs disponiert werden. Bei Sendungen die mit einem Fixtermin versehen sind, muss dieser Termin berücksichtigt und die Sendung dementsprechend priorisiert behandelt werden. In dem Beispiel soll die DPE die Berücksichtigung des Fixtermins sicherstellen. 3 Stunden vor dem Fixtermin soll mittels DPE geprüft werden, ob die Sendung bereits den Status „disponiert“ hat, ansonsten soll der Disposition eine Aufgabe geschickt werden, die zum sofortigen Disponieren der Sendung auffordert.

Die einzelnen Schritte sind anschließend noch einmal zusammengefasst.

Wenn eine Sendung im System erfasst wird prüft die DLE ob ein Fixtermin vorgegeben ist. Falls Ja, wird eine Überwachungsaufgabe generiert, die 3 Stunden vor dem Termin prüft, ob die Sendung bereits disponiert wurde.

3 Stunden vor einem Fixtermin für eine Sendung, führt die DPE die Überwachungsaufgabe durch.

Falls die Sendung bis dahin disponiert wurde, wird die Überwachungsaufgabe in den Status „erledigt“ überführt. Falls die Sendung bis 3 Stunden vor dem Fixtermin noch nicht disponiert wurde, wird eine neue Aufgabe für die Disposition erstellt, die auf das Terminproblem hinweist. Jeder Mitarbeiter der Abteilung Disposition bekommt die Aufgabe angezeigt und kann entsprechend darauf reagieren.

Wie in den meisten Workflowsystemen müssen auch in der DPE auf organisatorische Einheiten verlinkt und der Zugriff auf Daten ermöglicht werden.

Damit auf Organisationseinheiten referenziert werden kann, muss die Organisation zunächst in den Stammdaten der DLE/DPE hinterlegt werden. Der organisatorische Aufbau des Unternehmens ist auf folgender Abbildung ersichtlich.

An der Spitze der Firmenhierarchie steht die Konzerngruppe, mit derzeit einem Konzern, der wiederum eine Firma hat. Die Firma besitzt eine Niederlassung – Niederlassung Austria – mit den Abteilungen Auftragsbearbeitung, Warenausgang und Disposition. Der Disposition ist ein Mitarbeiter mit der Benutzer-Id „MAMA“ zugeordnet.

Die sendungsbezogenen Daten die von den Mitarbeitern der einzelnen Abteilungen erfasst und geändert werden befinden sich in der stark vereinfachten, separaten Datenbanktabelle SENDUNG mit den Attributen ID, ABSENDER, EMPFAENGER, INHALT, GEWICHT, GEFAHRENGUT, FIXTERMIN und FAHRZEUG. Das Feld ID enthält die eindeutige Sendungsnummer. Im Feld ABSENDER ist die Absenderadresse und Feld EMPFAENGER die Empfänger-Adresse einer Sendung eingetragen. Im Feld INHALT ist der Sendungsinhalt, sprich die Warenbezeichnung, eingetragen. Im Feld GEWICHT ist das Sendungsgewicht hinterlegt. Über das Feld GEFAHRENGUT kann eine Sendung als Gefahrengut deklariert werden. Ist ein Fixtermin gegeben, muss dieser unter FIXTERMIN eingetragen werden. Beim Disponieren einer Sendung wird dieser ein Fahrzeug zugeordnet, das in FAHRZEUG geschrieben wird. Auf der Datenbank sind bereits Fahrzeuge eingetragen, aus denen in der Dispo-Maske einer Sendung ausgewählt werden kann. Die Tabellenstruktur ist bewusst für das Beispiel leicht gehalten.
Die Einbindung der Daten erfolg über Metadaten (siehe technische Dokumentation). Anschließende Abbildung zeigt die Erfassungsmaske einer Sendung. Die Felder mit gelben Hintergrund, sind Pflichtfelder und müssen vom Sachbearbeiter ausgefüllt werden.

Todo-Typen müssen einer Kategorie von Aufgaben zugeordnet werden. Diese müssen bereits vor dem Neuanlegen einer Todo im System vorhanden sein. Nach der Installation der DLE/DPE verfügt die DPE bereits über die Kategorien „Check“ für Prüfungen und „Systemjob“ für Aufgaben die im Hintergrund automatisch über die DPE ausgeführt werden. Während die Prozesse Terminkontrolle und Terminproblem der Kategorie Prüfungen (Check) zugeordnet werden können, wird für die Abbildung der Zustände von Sendungsobjekten eine Kategorie mit dem Namen „Objekt“ erstellt.

Sind die Kategorien im System bekannt, können nun die unterschiedlichsten Todo-Typen definiert werden. Für das Beispiel sind das die Typen Terminkontrolle, das Terminproblem sowie die Sendung. Alle Drei werden dem Paket Logistik zugeordnet. Die Terinkontrolle und das Terminproblem gehören zur Kategorie Prüfung (Check), der Typ Sendung ist der Kategorie Objekt zugeordnet.

Jeder Status ist einer Statusgruppe zugeordnet. Per Default werden von der DPE die Gruppen „PLANNED“, „OPEN“, „INWORK“ „FINISHED“, „DONE“, „NEGDONE“ und „CANCELED“ bereitgestellt, die für den Großteil der Anwendungen ausreichend sind. Möchte man eine zusätzliche Statusgruppe definieren, kann dies über den Menüpunkt „Paketdaten/Todo-Definitionen/Statusgruppen“ der DLE-Administration jederzeit gemacht werden.

Auch Stati sind teilweise vordefiniert. Für unser Beispiel fehlt allerdings der Status „disponiert“ (siehe Abb. Zustandsgesteuerter Lebenszyklus einer Sendung). Dieser kann über die Stati-Maske neu erstellt werden.

Todo-Aktionen führen den eigentlichen Statuswechsel durch. Hinter einer Aktion steht gewöhnlich ein Brick, in dem Vor- und Nachbedingungen eines Statusübergangs geprüft und mit zusätzlicher Programmierlogik verschiedenster Art versehen werden kann.

Eine Aktion wird über die Bearbeitungsmaske „Paketdaten/Todo-Definitionen/Aktionen“ definiert. Hier muss zunächst ein Aktionsname, aus den Bestehenden, und der jeweilige TODO-Typ gewählt werden. Zudem muss das zugehörige Paket für die Aktion bestimmt werden. Über das Feld Aufruf kann definiert werden, wer die Aktion aufrufen darf. Mögliche Werte sind „Manuell oder durch DLE“ – Die Aktion kann manuell durch einen Benutzer (aus der Todo Liste) oder durch einen DLE Aufruf (Kommando: DPE Aktion ausführen) im Brick aufgerufen werden. „Durch DLE“ – die Aktion kann nur durch einen DLE Brick Aufruf ausgelöst werden. „Nur durch Applikation“ – die Aktion wird nur durch die aufrufende Applikation gestartet. In unserem Beispiel soll der Sachbearbeiter die Möglichkeit haben, über die Todo-Liste eine Aktion, in diesem Fall „disponieren“, auszulösen. Daher wird für die Aktion „disponieren“ das Feld Aufruf auf „Manuell oder durch DLE“ gesetzt.
Soll ein Brick aufgerufen werden der nicht im Ordner Aktionen im Paket DPE definiert ist, kann explizit ein Ordner mit dem entsprechenden Bricknamen definiert werden. Bei Fehler-Ordner und Fehler-Brick kann analog der Ordner und der Name eines Bricks angegeben werden, der beim Auftreten von Fehlern im regulären Brick ausgeführt werden soll.
Zusätzlich können Aktionen mit „Standard“ – Standardaktion für diesen Status –, „Eskalation“ – eine Aktion die bei einer Eskalation ausgeführt wird –, „Kompensation“ – eine Aktion die bei einer Stornierung ausgeführt wird – oder mit „Dialog notwendig“ – Benutzerinteraktion ist erforderlich – gekennzeichnet werden. Wobei das Kennzeichen „Standard“ je Status nur einmal vergeben werden darf, d.h. es kann nur eine Standardaktion je Status geben.
Die max. Laufzeit in Minuten kann als zusätzliche Information zu einer Aktion hinzugefügt werden. Weiters kann die Aktion einer Funktion zugeordnet werden, für die über das Berechtigungssystem spezielle Rechte eingeräumt werden können. Mit den Feldern Parameter 1-3 können Werte eingetragen werden, auf die im Aktionsbrick Bezug genommen werden kann. Für eine umfangreichere Beschreibung der Aktion ist ebenfalls ein Feld definiert.

Werden keine speziellen Bricks in der Bearbeitungsmaske der Aktionen definiert, werden die Bricks aus dem Paket „Process-Engine“ ausgeführt (siehe nachfolgende Abbildung).

Die Todos stehen meistens mit irgendwelchen Daten, meist Bewegungsdaten, in Beziehung. Beispiele hierfür sind Aufträge, Angebote, usw. Über die Zusatzdaten ist es möglich von einer Todo zu diesen Auftragsdaten, Angebotsdaten, etc. zu referenzieren. In den Zusatzdaten wird definiert, wie diese Verbindung aussieht.

Folgende Möglichkeiten bestehen:

• Es existiert eine von der DLE/DPE losgelöste Tabelle, die z.B. die Auftragsdaten hält. Beim Anlegen einer Todo, wird die Auftragsnummer in der Todo mitgespeichert. Über die Auftragsnummer in der Todo-Tabelle kann jederzeit auf den Auftrag zugegriffen werden. Dieser Fall ist der, der in der Praxis am Häufigsten vorkommt. Dies entspricht dem Speichertyp 6: als Hauptobjekt in DLETODO – DATAOBJECT_IDC, DATA_IDC
• Wenn zu einer Todo sehr viele Daten notwendig sind, für die noch keine externe Tabelle besteht bzw. die Daten nur im Rahmen der DLE/DPE Verwendung finden, kann eine neue Tabelle angelegt werden, wobei die Todo-ID als Primärschlüssel der neuen Datentabelle dient. D.h. es existiert eine 1-zu-1-Beziehung zwischen der Todo-Tabelle der DPE und der Datentabelle, die als Verlängerung der Todo-Tabelle mit zusätzlichen Daten zur Todo zu sehen ist. Dies entspricht dem Speichertyp 5: ExtensionDataObject (Externe Tabelle mit TODO_ID als PK)
• Wenn nur sehr wenige Daten zu einer Todo existieren, sodass eine eigene Datenbanktabelle nicht unbedingt nötig ist, können die Daten auch, in einer von der DPE eigens für diesen Zweck bereitgestellten Tabelle, gespeichert werden. Die DPE stellt dafür zwei Tabellen zur Verfügung:
  • DLETodoID: Für die Daten in dieser Tabelle ist ein Datenbankindex für einen schnellen Zugriff auf der Datenspalte hinterlegt. Sinnvoll ist hier die Speicherung von Daten auf die sehr oft zugegriffen wird. Z.B. Primärschlüssel auf andere Tabellen etc. Dies entspricht dem Speichertyp 2: Id als Attribut (DLETODOID)
  • DLETodoData: Für die Daten in dieser Tabelle ist kein Datenbankindex auf der Datenspalte hinterlegt. Sinnvoll ist hier die Speicherung von Daten die keine IDs für andere Tabellen sind. Dies entspricht dem Speichertyp 3: Daten-Attribut (DLETODODAT)

Nachfolgende Abbildung zeigt die Maske zur Konfiguration zusätzlicher Daten zu einer TODO am Beispiel der Sendung.

Ausgangslage bilden die oben besprochenen Speichertypen. Je nach Speichertyp sind unterschiedliche Konfigurationen erlaubt. Der Todo-Typ ist in diesem Beispiel die Sendung. Für die Sendungsdaten besteht bereits eine Tabelle, die die Daten zur Sendung hält, daher wird hier als Speichertyp „als Hauptobjekt in DLETODO – DATAOBJECT_IDC, DATA_IDC“. Dabei wird der Primärschlüssel der Sendungstabelle, die Sendungs-ID, in der TODO-Tabelle gespeichert. Über eine Todo vom Typ Sendung kann somit jederzeit auf die dazugehörigen Sendungsdaten zugegriffen werden.
Im Feld Attribut-Id kann ein Suchbegriff definiert werden, über den eine bestimmte Todo mit der jeweiligen Sendungsnummer gesucht werden kann.
Gespeichert werden soll die Sendungs-ID, d.h. der Schlüssel des Datenobjekts LOGISTIK:SENDUNG.
Mit dem Kennzeichen „Pflicht“ wird sichergestellt, dass jede Todo vom Typ Sendung eine Sendungs-ID haben muss.
Die nachfolgenden Abbildungen zeigen die Zusatzdaten für die Todo-Typen Terminkontrolle und Terminproblem.

Neue Todos können nur über einen Brick angelegt werden. In dem Beispiel werden, nachdem die Daten der Sendung erfasst und gespeichert sind, die Todos angelegt.
Zunächst wird in der Zeile 35 geprüft, ob ein Fixtermin existiert. Falls ja, wird der Kontrolltermin berechnet. Drei Stunden vor dem Fixtermin soll die Prüfung, ob die Sendung bereits disponiert ist, mittels einer Todo stattfinden. Die dafür erforderliche Aufgabe vom Typ „Terminkontrolle“ wird in der Zeile 38 angelegt.
In der Zeile 41 wird eine neue Todo vom Typ Sendung angelegt.
Für beide Todos darf nur eine Todo, mit dem selben Betreff angelegt werden. Beide Todos sind für die Auftragsbearbeitung bestimmt.
Hinweise zu den weiteren Parametern des Kommandos „Todo anlegen“ können im Abschnitt Kommandobeschreibung im Detail nachgelesen werden.

Bei der Aktion „Disponieren“ muss, nachdem die Sendung einem Fahrzeug zugeordnet wurde, der Statuswechsel von „offen“ auf „disponiert“ erfolgen. Dies geschieht im anschließenden Brick in der Zeile 41. In den folgenden Zeilen, wird als Verantwortlicher die Dispo und als Ausführender der Warenausgang für die aktuelle Todo gesetzt.
Ist die Sendung disponiert, können gegebenenfalls die noch offenen Todos vom Typ Terminproblem und Terminprüfung auf erledigt gesetzt werden. Siehe Zeile 46 bis Zeile 60.