Templates

Das Konzept des Workflowmanagers und der Workflow-Templates entstand aus der Überlegung, Bestellabläufe nicht fest in ein Einkaufssystem eincodieren zu müssen, sondern jederzeit relativ problemlos neu entstandene Wege hinzuzufügen, alte Abarbeitungswege erweitern oder verändern zu können.

Die Templates selbst stellen dabei die codierte Abarbeitungsvorschrift für einen Bestellvorgang dar. Dafür muß ein Template-Programmierer lediglich ein neues Template mit den gewünschten Abläufen kreieren und dem Workflowmanager zur Verfügung stellen. Dieser ist dann in der Lage, aus der Liste der existierenden Templates auszuwählen und die Einkaufs-Vorgänge abzuwickeln.

Ein Workflow startet in der Regel mit dem Bestellwunsch eines Benutzers. Anhand der Informationen: wer bestellt, was bestellt er, in welchem Wert, inwieweit muß er sich diese Bestellung bestätigen lassen usw., entscheidet der Workflowmanager selbst, welches Template er für die Abarbeitung dieses Vorgangs initialisiert. Das so ausgewählte Template ist nun die zwingend einzuhaltende Vorschrift, nach der der gesamte Vorgang abgewickelt wird.

Einkaufs-Abläufe an einer Universität funktionieren größtenteils nach einem sich immer wiederholenden Schemata. Jemand hat einen Bedarf, ein anderer die Verfügungsgewalt über den entsprechenden Haushalts-Topf, ein dritter muß den Vorgang eventuell genehmigen, wieder ein anderer ist für die Entgegen- und Abnahme zuständig Solche Vorgänge sind also zumeist standardisierbar und werden sequenziell bearbeitet.

Das Konzept der Workflow-Templates basiert genau darauf. Ein Vorgang wird initialisiert und zur Bearbeitung an den Application-Server gesandt. Das heißt im Klartext: Ein System-Benutzer identifiziert sich dem System als User X und teilt mit, daß er z.B. etwas bestellen möchte.

-theoretisch kann der Benutzer unseres Systems nicht nur einen Bestellvorgang starten; Eine Anforderung bis hin zu ,,ich brauche Kaffee`` oder ,,jemand muß meinen BMW putzen`` sind vorstellbar.-

Daraufhin erfragt der App-Server die Liste aller Workflow-Templates, die dieser Benutzer ausführen darf. Anhand einer Beschreibung zu jedem Template kann der Benutzer den passenden Bearbeitungsweg auswählen. Mit dieser Auswahl ist das entsprechende Template und damit der kommende Workflow initialisiert.

Ab nun wird das Template schrittweise abgearbeitet. Anhand der Ergebnisse des zuletzt ausgeführten Schritts wird der nächste Schritt bestimmt und in Bearbeitung gegeben. Dieser ,,Nächste Schritt`` entstammt einer geringen Auswahl möglicher Schritte, die ein Template für eine Weiter-Bearbeitung vorsieht.

Ein Beispiel hierfür wäre:

• der letzte Schritt war die Frage an den Vorgesetzten, ob er den Bestellvorgang genehmigt.
• Abhängig von der Antwort muß das Template nun ,,Nächste Schritte`` bereithalten.
• Bei positiver Beantwortung müsste die Bestellung eingeleitet werden.
• Bei negativer Beantwortung müsste der Vorgang abgebrochen werden
• Des weiteren wären Schritte im Repertoire zu halten, die z.B. einen Timeout, d.h. gar keine Antwort, abdecken u.ä.

In dieser Form können die Templates beliebig komplex gestaltet sein. Schließlich kann, oder muß, man eine beliebige Menge an Eventualitäten und Schritten abdecken.

Ein Template könnte aber theoretisch auch aus lediglich einem Schritt bestehen: ,,Stellt ein Client eine Anfrage, initiiere Bestellung¡`

So ein Template ist zwar möglich aber offensichtlich wenig sinnvoll. Schließlich könnte sich auf diesem Wege ja jeder seinen neuen BMW bestellen.

Dieser Umstand führt gleich zum Punkt Sicherheit:

• Ein Template sollte natürlich nur von bestimmten, vertrauenswürdigen Personen erstellt werden dürfen
• Eine nochmalige Contentüberprüfung vor der Inbetriebnahme sollte außerdem erfolgen
• Die Auswahl an Templates für den jeweils eingeloggten User muß natürlich zuallererst nach seinen Rechten im System beschnitten werden. Er darf keine höheren Entscheidungsinstanzen auslassen können.

Weit komplexere Templates sind natürlich realistisch und zu erwarten. Wir haben uns bemüht, einige relativ realitätsnahe Workflow-Templates für unser System zu erstellen. Auch, wenn wir uns dabei bisher größtenteils auf unsrer Vorstellungsvermögen verlassen mussten. Schließlich sind wir alle, trotz 2er Semester BWL und 3en beim berühmten Herrn Liggesmeyer, keine BWL-Genies geworden.

Abläufe

Zum Beispiel braucht ein wissenschaftlicher Mitarbeiter drei neue Computer für die Arbeit mit Studenten. Er müsste also seinen Bestellwunsch ins System eingeben. Daraufhin erhielte er einen oder mehrere Workflows, die eine Bestellung in der Größenordnung 3er Computer durch einen wissenschaftlichen Mitarbeiter abdecken können. Dies wäre der Initialschritt für einen neuen Workflow.

Der App-Server wird nun dem Workflowmanager mitteilen, daß er eine neue Workflow-Instanz anhand der User- und Anfrage-Daten des Bestellenden anlegen muß.

Für die sich nun anschließenden Schritte bis zu der Bestätigung des intakten Eingangs der drei Rechner muß es im System ein Template geben, welches alle möglichen Verfahrenswege genau beschreibt.

Der logisch nächste Schritt einer solchen Abwicklung war für uns die Überprüfung der Verfügungsberechtigung der anfordernden Person.

Dies lässt sich ableiten aus der Rolle des Bestellers im System, die er beim Login einnimmt. Rolle heißt hier: mit seinem Login identifiziert sich der Nutzer dem System gegenüber als eine Person mit bestimmten Rechten. So wird das Login eines Lehrstuhl-Leiters demjenigen auch die Verfügungsgewalt über den Haushalts-Topf seines Ressorts ermöglichen, dem wissenschaftlichen Mitarbeiter jedoch eine Bestellung ohne Zustimmung generell verweigern.

Informationen zu den verschiedenen Rollen sind in einer Datenbank hinterlegt und ermöglichen die einfache Überprüfung der Verfügungsberechtigung.

Kehrt die Funktion mit der Aufgabe der Verfügungsprüfung mit einem Ergebnis zurück, muß das Template dieses Workflows nun mindestens 2 mögliche Folgeschritte abdecken:

1. Die eingeloggte Person ist berechtigt eigenmächtig über den angefragten Betrag, der schon im ersten Anforderungsformular einer Kostenstelle zugeordnet werden muß, zu verfügen. Hier müsste der nächste Schritt schon die Bestellung sein.
2. Die eingeloggte Person ist über diesen Betrag nicht verfügungsberechtigt. Der nächste Schritt wäre jetzt, die Anforderung einem Vorgesetzten vorzustellen, der über diese Ausgabe entscheiden kann. Das Template muß das ermöglichen.

Außerdem müssten weitere Eventualitäten abgedeckt werden. So könnten zum Beispiel Timeouts oder ungültige Antworten den Vorgang behindern.

Auch diese Fälle müssen an manchen Stellen durch das Template selbst abfangen werden. Würde hier der Fall auftreten, daß nach einer bestimmten Zeit noch keine Antwort vom Vorgesetzten eingetroffen ist, könnte man im Template eine erneute Anfrage festlegen.

Für den Fall, daß die Bestätigung durch den Vorgesetzten positiv zurück kam, muß jetzt damit begonnen werden, Angebote für die benötigten Posten bei Anbietern einzuholen.Das Template muß das an dieser Stelle festlegen. Diese Angebots-Einholung wäre die Stelle, an der die schon einmal angesprochenen mobilen Agenten ins Spiel kämen. Solange es diese noch nicht gibt, muß das händisch vorgenommen werden.Das muß entweder der Besteller selbst, oder eine andere damit beauftragte Person erledigen.

Im Template muß festgelegt sein, das neue Angebote nur eine bestimmte Zeit lang ins System ,,eingehängt`` werden können. Ansonsten könnte ein Workflow hier ewig hängen.

Sind nun alle Angebote in einem Preisspiegel katalogisiert, muß verglichen und sich entschieden werden. Für den Fall, das alle Angebote den ursprünglich anvisierten Preis weit übersteigen, haben wir uns eine erneute Genehmigungsrunde vorgestellt.

Sind nun alle Bestellformalitäten durchlaufen, würde die Bestellung abgegeben. Ab hier bewegt sich das Geschehen eine Weile außerhalb des Systems und kann durch den Template-Programmierer höchstens durch Timeouts überprüft werden. Das hieße, ist die Bestellung nach einer bestimmten Zeit nicht eingetroffen, muß das Template eine Information für den Besteller vorsehen.

Ist die Bestellung angekommen, müssen in den Abläufen noch Vorgänge, wie das Überprüfen der funktionalen Korrektheit der eingetroffenen Ware, oder die Inventarisierung vorgesehen werden.

Inwiefern solche Schritte noch automatisierbar sind oder in den Workflows lediglich einer ,,ist-passiert-Bestätigung`` bedürfen ist eine Frage, die wir nicht mehr endgültig beantwortet haben. Hier ist also ein weiterer Ansatzpunkt für Folgearbeiten.

Ein eben beschriebener Workflow könnte im Ablauf etwa so aussehen:

Abbildung 4.2: Workflow

Größtenteils handelt es sich bei den Templates um die Abwicklung von if Bedingungen. Der Workflowmanager teilt mit, daß die Rolle xy eine Anforderung in Höhe von ?Euro gestellt hat. Im Template müsste codiert stehen : if ,,Anforderung von XY in Höhe von ¿`; then ,,check, ob XY ?Euro ausgeben darf``! Aus solchen Bedingungen setzt sich der größte Teil der Templates zusammen.

Dieser Umstand führte uns fast zwangsläufig zur Überlegung, daß zum Erstellen der Templates ein visuelles Tool alla VISIO eine sehr gute Lösung darstellen würde.

Man könnte dann die verschiedenen Vorgänge praktisch ,,zusammenklicken``. Damit könnte verhindert werden, daß man für die Erstellung von Templates tiefere Java-Kenntnisse benötigt. Ganz zu schweigen von der viel geringeren Fehler-Anfälligkeit beim Erstellen. Diese Idee ist sicherlich praktikabel und auch lohnenswert. Jedoch wollten wir den nachfolgenden Zornschen Projekt-Gruppen nicht jeden Spaß wegarbeiten und ließen diese Anforderung daher gönnerhaft unbearbeitet!!! ;o)