Workflows

Ein Workflow-Template ist eine Java Klasse, welche von der abstrakten Klasse wfl_template erbt. Solch eine Klasse beschreibt eine bestimmte Art von Workflow und kann vom Endanwender selbst geschrieben werden. Diese unterliegt folgenden Konventionen:

Die Klasse muss sich im Package Workflow-Templates befinden, von wfl_template erben und die abstrakte Funktion receive(String fct_ID, Auftrag result) implementieren. Diese Funktion wird aufgerufen, sobald ein Ereignis, z.B. das Eintreffen eines Ergebnisses eines vorheriger Applikation-Server Funktionsaufrufes, für diesen Workflow auftritt. Diese Funktion hat 2 Parameter. Die fct_ID beschreibt, welches Ereignis aufgetreten ist. Der Normalfall ist die Lieferung eines Ergebnisses zu einem vorher erfolgten Applikation-Server Funktionsaufruf. Hier ist an Hand der fct_ID zu erkennen, zu welchem Funktionsaufruf das eintreffende Ergebnis gehört. Der Funktionsparameter result ermöglicht es, zu einem solchen Ereignis beliebig viele Parameter mitzuliefern. Des Weiteren steht dem Workflowtemplate-Programmierer ein Objekt vom Typ HashMap namens Status zur Verfügung. Hier müssen alle Daten, die auf der Abstraktionsebene Workflow benötigt werden, abgelegt werden.

In der receive-Funktion kann nun an Hand Daten fct_ID, results sowie Status entschieden werden, was als nächstes passieren soll. Eine weitere Möglichkeit, sich den Stand des Workflows zu merken, gibt es nicht.

Durch einen Anforderung von außen wird eine template-Klasse instantiiert, initialisiert und die run-Methode dieses Threads gestartet. Von nun an agiert der Workflow nebenläufig zum restlichen System.

In der run-Methode wird nun die vom template-Ersteller implementierte Methode receive aufgerufen. Der Funktionsparameter fct_ID bekommt den Wert start und result stellt eine Kopie des optional bei der Anforderung der Workflow-Erstellung mitgegebenen HashMap. Dadurch, daß fct_ID den Wert ,,start`` hat, kann nun durch ein entsprechendes if-then-Konstrukt der erste Schritt des Workflows bestimmt werden. U.a. stehen dem template-Entwickler die Funktionen send_app_function sowie waitForResult zu Verfügung. Erstere senden eine Auftrags-Objekt1 an den Applikation-Server, während waitForResult dafür sorgt, dass der Workflows nun auf Empfang schalten. Alle Änderungen, welche nach Aufruf dieser Funktion noch erfolgen, sind beim nächsten Ereignis verloren. Man muss nämlich die Vorstellung haben, dass sich der Workflows nun in eine Art Schlaf begibt und beim Eintreffen des nächsten Ereignisses wieder geweckt wird. Gesichert wird nur, was in der Datensammlung Status steht, alles andere geht verloren.

Trifft im Folgenden ein Ergebnis ein, wird der Workflow wieder geweckt und es wird wieder die receive Funktion aufgerufen. Nun hat der template-Ersteller die Möglichkeit, einmal anhand der fct_ID festzustellen, von welchem Applikation-Server-Funktionsaufruf das Ergebnis stammt und auch im Zusammenhang mit dem aktuellen Status des Workflows über ein entsprechendes if-then-Konstrukt festzulegen, welcher Schritt als nächstes erfolgt.