© Artur Szydlowski, Fotolia.com

Die IT unterstützt ihre Anwender schon bei vielen Aufgaben. Sie müssen aber dennoch den Überblick behalten, was es als Nächstes zu tun gibt. Workflow-Engines helfen ihnen dabei, denn viele Abläufe in Unternehmen laufen stets nach demselben Muster ab.

Moderne IT-Infrastrukturen ändern sich schnell und sind deshalb selten auf fachlicher Ebene besonders weit vernetzt. Beispiel Dienstreise: Ein Mitarbeiter mailt seinem Servicecenter Termin und Zielort, die Sachbearbeiterin kopiert die Angaben in mehrere Buchungsportale und sendet eine Bestätigung. Nach der Reise erfasst der Betroffene die gleichen Daten erneut für die Spesenabrechnung. Es soll Mitarbeiter geben, die diesen Ablauf mit schlauen Skripten automatisieren. Was aber, wenn das Unternehmen zusätzlich eine Zeiterfassung einführt? Die Komplexität dieser Aufgabe verlangt nach einem ganzheitlichen Ansatz.

Sich laufend ändernde Bedingungen fordern von Entwicklern, Geschäftsprozesse immer wieder anzupassen, ohne jedes Mal die ausführende Technik neu zu erfinden. Damit sind die Prozesse die Schnittstelle zwischen Fachabteilungen und IT. Gleichzeitig sollen Entwickler und Administratoren den Überblick über das Gesamtsystem und dessen innere Vorgänge behalten – eine Herausforderung für Modellierer und Architekten.

Pläne schmieden

Der Zweck eines Workflow-Management-Systems (WFMS) ist, Vorgänge von ihrer Implementierung getrennt zu modellieren [1]. So soll es ähnlich wie beim herkömmlichen Programmieren möglich sein, fachliche Abläufe mit grundlegenden Werkzeugen an Business-Funktionen wie Postversand, Kreditkartenabbuchungen oder Lagerbestandsaufnahmen anzupassen und zu kombinieren. Dazu definiert der Modellierer zunächst in maschinenlesbarer Form, wie ein Vorgang prinzipiell abläuft.

Da sich diese XML-Beschreibung nur mit viel Mühe per Editor pflegen lässt, unterstützt ihn eine Reihe grafischer Werkzeuge (siehe Kasten “Active-BPEL”). Das WFMS liest diese Prozessdefinition und koordiniert und kontrolliert daraufhin die konkreten Instanzen des modellierten Ablaufs. Nebeneffekt: Moderne Prozesssteuerungssysteme sind damit in der Lage, fachliche Daten ohne Umwege über Logfiles zu protokollieren. So erheben sie etwa die Zahl der Dienstreisen und die damit verbundenen Kosten unmittelbar als Teil des Ablaufs.

Das Orchester spielt auf

Workflow-Engines kümmern sich vorrangig um Ablauf und Reihenfolge von Aktivitäten. Um die einzelnen Dienste einzubinden, benutzen die meisten von ihnen Service-orientierte Architekturen (SOA), eine auf XML aufsetzende Beschreibung von Funktionen [2]. Das erlaubt es einem Unternehmen, in der Buchhaltung SAP-Systeme einzusetzen, in der Logistik jedoch eine Eigenentwicklung auf Basis von JEE oder Dotnet zu verwenden.

Bieten alle Anwendungen SOA-Schnittstellen an, lassen sich ihre Funktionen mit einem WFMS applikationsübergreifend zusammenführen und die Abläufe zwischen ihnen steuern. Die einzelnen Webservices verhalten sich wie die Instrumente in einem Orchester: Der Workflow dirigiert und fügt die einzelnen Stimmen zu einem harmonischen Ganzen zusammen. Die Päpste der Zunft nennen das Programming in the Large.

Prozessdesigner konzentrieren sich nicht auf die technischen Details der Implementierung, beispielsweise der Flugbuchung oder Bonitätsprüfung, sondern auf die darauf aufbauenden Anwendungen. Wechselt das Unternehmen von der Schufa zu Creditreform, um die Kreditwürdigkeit von Kunden zu überprüfen, macht das nur noch kleinere Anpassungen nötig. Das entlastet Entwickler und Administratoren.

Standard integriert Technik

Ein Standard für das SOA-Workflow-Management ist die Business Process Execution Language (BPEL). IBM, BEA, Microsoft, SAP und andere haben der OASIS den Standard vorgelegt, aktuell ist Version 2.0 [3]. Er beschreibt Prozesse mittels XML und greift auf die Webservice-Standards WSDL und SOAP zurück. Viele Einsteiger in BPEL sind von der Strenge und Umständlichkeit der Sprache irritiert, denn externe Dienst-APIs ruft BPEL ausschließlich über WSDL-definierte Schnittstellen auf – SOA pur.

Der Prozessdesigner notiert geplante Abläufe zunächst in einer weitgehend nicht-technischen Form, beispielsweise als ereignisgesteuerte Prozessketten oder als handschriftliche Zeichnung. Anschließend hilft ihm der Editor seiner BPEL-Umgebung, den Plan in der formalen Beschreibungssprache zu formulieren. Active-BPEL ist damit eine Umgebung. Ihr Designer fügt sich direkt in die Entwicklungsumgebung Eclipse ein. Dort stellt er dem Entwickler Aktionspaletten bereit, die es erlauben, Prozesse mit der Maus zusammenzustellen (siehe Abbildung 1). Dazu benötigt BPEL von allen Anwendungen WSDL-Schnittstellen.

Abbildung 1: Statt XML per Hand zu verarbeiten, erlaubt es der BPEL-Designer, Prozesse per Drag&Drop zu modellieren. Aufgrund des hohen Abstraktionsgrads der Schnittstellendefinitionen ist er unentbehrlich.

Licht und Schatten

Bei aller Vereinheitlichung hat BPEL aber auch einige Pferdefüße. So bleibt der Standard an einigen Stellen undeutlich oder lässt Schlupflöcher offen, die viele Hersteller von BPEL-Engines für proprietäre Erweiterungen nutzen. So schreibt er zwar XPath als Sprache für die Variablen- und Wertmanipulation vor, erlaubt aber auch Erweiterungen, etwa XQuery oder Javascript. Die vereinfachen zwar das Modellieren, bedeuten aber, dass nicht mehr jede Workflow-Engine die Prozessdefinitionen versteht.

Ähnliches gilt für Hersteller-Erweiterungen im Bereich Sicherheit und den Zugriff auf interne Engine-Informationen: Eindeutige Prozess-IDs über eine Engine-spezifische XPath-Funktionen auszulesen ist bequem, aber nicht portabel. Wer jedoch diese Vendor-Locks kennt, kann um sie herum navigieren.

Musterabläufe entwerfen

Einen Prozess modelliert BPEL als eine Folge atomarer Bearbeitungsschritte, so genannter Aktivitäten. Sie sind zumeist per »invoke«-Element direkt auf einen Webservice abgebildet oder manipulieren Variablen. Die einzelnen Aktivitäten ordnet der Entwickler als Knoten eines Graphen an. Jeder Knoten enthält genau ein Steuerungselement, zum Beispiel Bedingungen, die andere Aktivitäten nach sich ziehen, oder Flows, die weitere Aktivitäten parallel ausführen. Andere Elemente wie Sequenzen oder Schleifen steuern ebenfalls den Kontrollfluss.

Diese Strukturen, in einem XML-Dokument abgelegt, ergeben die BPEL-Prozessdefinition. Sie enthält zusätzlich Meta-Informationen und Schnittstellenbeschreibungen. Der Modellierer formuliert sie in WSDL und in Form von »PartnerLinks«-Elementen. Diese sorgen für eine weitere Abstraktionsschicht zwischen »invoke«-Aktivitäten innerhalb des Prozesses auf der einen Seite und konkreten Webservices auf der anderen.

Zur Wertübergabe benutzt BPEL den Standard XML-Schema, die Variablen können also komplexe Strukturen aufnehmen. Faulthandler fangen Fehler bei der Prozessausführung ab und schließen dann etwa Datenbankverbindungen. Eventhandler hingegen stellen zusätzliche Dienste neben der normalen Prozesslogik bereit. Die Liste ist nicht vollständig, beschreibt aber die wichtigsten Elemente einer Prozessdefinition in BPEL.

Abläufe steuern

Das Muster, nach dem der planende Mitarbeiter die Abläufe anordnet, ist schließlich der Prozess. Erst wenn eine Laufzeitumgebung, die BPEL-Engine, diese Beschreibung abarbeitet, entstehen aus ihm Prozessinstanzen. Jede von ihnen hat eigene Zustände und bringt die einzelnen IT-Systeme mit den beteiligten Mitarbeitern zusammen (siehe Kasten “Workflow in Strukturen integrieren”). Letztere bekommen ihre eigene Anbindung an Webservices: Die Engine stellt dazu der betroffenen Person eine E-Mail zu oder trägt eine Aufgabe in die unternehmensweiten Groupware ein.

Daran wird deutlich, dass Businessprozesse je nach Anwendung durchaus mehrere Tage oder länger dauern. Um in einer solchen Umgebung die Datenintegrität zu gewährleisten, taugen klassische Methoden wie ein Rollback in einer SQL-Datenbank nur noch bedingt: Einen verschickten Brief kann der Absender nicht mehr zurückholen. Stattdessen arbeiten Workflow-Systeme mit Kompensationen, etwa einem zweiten Brief, der eine erfolgte Hotelreservierung wieder storniert. Eine Kompensation ist im BPEL-Kontext wie ein eigener Prozess definiert, daher dürfen Entwickler innerhalb der Kompensation alle Gestaltungsmöglichkeiten von BPEL nutzen.

Workflow in Strukturen integrieren

Neben Webservices spielen auch reale Personen eine Rolle in Unternehmensabläufen – allerdings haben sie keine WSDL-Schnittstelle. Um eine Workflow-Komponente in eine bestehende Infrastruktur zu integrieren, setzen Architekten oft neben der zentralen Engine ein System zur Worklist-Verwaltung ein (siehe Abbildung 3). Es agiert als Schnittstelle zwischen Mitarbeiter und Webservice. Abbildung 3: Die BPEL-Engine steht im Mittelpunkt zu steuernder Workflows. Sie führt nacheinander einzelne Aktivitäten aus, für die Benutzer in ihrem Browser via Worklist-Manager Daten liefern. Mit dem BPEL-Editor plant der Prozessdesigner die Abläufe. Ordnet ein BPEL-Prozess eine Aufgabe einem bestimmten Mitarbeiter zu, ruft er einen Webservice auf. Der schickt sie zur Worklist-Verwaltung, die die Anfrage entgegennimmt und in die To-do-Liste des betreffenden Mitarbeiters einstellt. Sobald dieser seine Aufgabe erledigt hat, sendet die Worklist eine Erledigt-Meldung an die BPEL-Engine. Oft sind solche Systeme mit der Groupware oder einem Webfrontend verbunden, andere akzeptieren E-Mails.

Lange Leitung

In Bezug auf langandauernde Prozesse ergibt sich noch ein weiteres Problem: Das übliche Request-Response-Muster von HTTP reicht nicht aus, wenn die Antwort zu lange braucht. Dann bricht die Anfrage zu einem solchen synchronen Dienst ab, bevor der Webservice sie beantwortet. Aus diesem Grund definiert BPEL Techniken für die asynchrone Webservice-Kommunikation zwischen Client und Server. Dabei unterbricht der Client die Verbindung, sobald er eine Eingangsbestätigung erhalten hat. In der Anfrage hat er über ein »replyTo«-Headerfeld eine URL für die Antwort festgelegt. Ist die Aufgabe bearbeitet, tauschen beide Partner die Rolle und der ehemalige Server sendet die Antwort an die hinterlegte Adresse, sodass die dortige BPEL-Engine den Prozess fortführen kann. Ist es nicht möglich, dass die Prozessengine Antworten entgegennimmt, springt eine Middleware ein, etwa ein Enterprise-Service-Bus.

Struktur schaffen

Die Prozessengine hat die Aufgabe, eingehende Vollzugsmeldungen auch noch lange nach der zugehörigen Anfrage einer Prozessinstanz zuzuordnen, denn oft durchlaufen viele die Engine gleichzeitig. Beispielsweise können einige Instanzen von “Reise genehmigen” zeitgleich innerhalb der Prozessengine ablaufen, weil gerade mehrere Kollegen einen Messebesuch planen. Lassen sich keine Transaktions-IDs in die Abfrage einbauen, da die Schnittstelle von außen vorgegeben ist, versucht das WFMS von den Parametern auf die Prozessinstanz zu schließen. Vermutlich reichen bei einer Reise der Name und das Abreisedatum. Solche mit einem Primärschlüssel vergleichbaren Attribute nennt BPEL Correlation-Sets.

Scopes in einer Modellierung entsprechen Blöcken in C++ oder Java. Sie sind Bereiche mit lokalen Variablen, Prozessabläufen und Faulthandlern. Mit ihnen lässt sich in einer Prozessdefinition Ordnung halten, da lokale Strukturen wie Variablen auch nur lokal verfügbar sind.

Eine mit Scopes modellierte Lieferung verdeutlicht dies: Ein Unternehmen belastet eine Kreditkarte mit dem Rechnungsbetrag (Sub-Scope-Rechnung), kann die Waren aber wegen einer falschen Adresse nicht zustellen (Sub-Scope-Zustellung). Der zugehörige Faulthandler gibt den Fehler an den umgebenden Scope weiter, der selbst einen Faulthandler hat. Dieser verständigt den Sachbearbeiter und kompensiert anschließend die Aktivitäten: Er bucht den Betrag zurück auf das Kreditkartenkonto. Der Vorteil ist, dass der Prozessdesigner die Fehlerbehandlungen und Gegenmaßnahmen lokal bei jedem einzelnen Schritt notiert.

Beispiel: Reise buchen

Anhand der vorgestellten Beschreibungsmittel lässt sich nun ein einfacher Prozess modellieren und später starten. Sind einmal der Applikationsserver und die BPEL-Engine heruntergeladen und installiert (siehe Kasten “BPEL-Engine installieren”), modelliert der Designer einen Teil einer Reisebuchung. Dieses Beispiel verzichtet auf Kompensationen und asynchrone Aufrufe. Es enthält mehrere XML-Dateien. Der Entwickler fasst sie später zu einem Archiv zusammen und überträgt sie in die Engine.

export CATALINA_HOME=$(pwd)/apache-tomcat
cd activebpel-5.0.2
./install.sh

cd ../apache-tomcat/bin
./startup.sh

Als Eingabe für den Prozess dienen vier Datensätze: der Benutzername des Reisenden, Start- und Zielort der Reise sowie Datum und Uhrzeit. Der Prozess startet mit der Wahl eines Verkehrsmittels. Dafür berechnet ein Webservice in Abhängigkeit von Reisedauer und Reisendem, ob dieser mit Bahn oder Flugzeug reist. Geschäftsführer und Servicetechniker könnten beispielsweise eine höhere Priorität für Flugreisen genießen. Ist eine Entscheidung getroffen, bucht die Prozessengine davon abhängig die Fahrt oder den Flug. Den Fahrplan schickt sie als Ergebnis an den Mitarbeiter zurück (siehe Abbildung 2).

Abbildung 2: Bei einer Reisebuchung entscheidet ein Webservice über das genutzte Verkehrsmittel. Anschließend begleitet die Workflow-Engine die Buchung von Bahn oder Flug.

Per Mausklick dirigieren

Der grafische Active-BPEL-Designer hilft die einzelnen Schritte der Modellierung in XML-Dateien umzusetzen. Es sind im Wesentlichen zwei Arten von Dateien im Spiel: BPEL trennt strikt Schnittstelleninformationen von den Webservices. Dazu bedient sich die Sprache Operationen, Parameterbeschreibungen und Partnerlinks. Letztere sind abstrakte Repräsentaten der tatsächlichen Service-Adresse. Die zweite Gruppe ist die Modellierung selbst. Sie legt Struktur, Abfolge und Ausnahmebehandlungen fest. Beide sind in einem Archiv mit der Modellierung der Reisebuchung enthalten und liegen auf dem FTP-Server des Linux-Magazins [8]. Um das Beispiel nachzuvollziehen, laden BPEL-Interessierte den Designer herunter. Dann entpacken und starten sie ihn mit:

./ActiveVOS_Designer_unix_6_0_2.sh

Eine per E-Mail verschickte Lizenzdatei macht den Weg frei zur weiteren Installation. Wer keine Testversion nutzen möchte, darf auch jeden anderen BPEL-Designer nutzen. Ein Wizard installiert zusätzlich zum Designer eine vollständige Version der Engine. Anwender können so direkt aus dem Editor testen. Aus diesem Grund fragt der Wizard nach einem Port für den Debug-Server. Die Voreinstellung passt für das Beispiel.

Nach der Installation behebt der Anwender ein Encoding-Problem in der Linux-Version 6.0.2 und wandelt eine Datei per »recode« um:

cd  ./Designer/designer
recode ibmpc..latin1 jre/lib/i386/jvm.cfg

Den Designer startet er mit »./designer« und übernimmt den vorgeschlagenen Pfad als Workspace. Die Begrüßungsseite beendet er durch das Schließen des Tabs. Eclipse-Anwender finden sich schnell zurecht. In der Standard-Workspace-Ansicht des Designers legen sie mit »File | New | Orchestration Project« ein neues Projekt an.

Die WSDL-Datei »services.wsdl« aus dem Beispielprozess beschreibt alle Schnittstellen. Der Entwickler legt sie im Projektbaum unter »wsdl« an, ebenso die BPEL-Prozessbeschreibung unter »bpel« als »reisebuchung.bpel«. Der Deployment-Deskriptor enthält unter anderem die konkreten Adressenangaben der Dienste. Er findet seinen Platz unter »deploy/reisebuchung.pdd«. Wichtig ist, dass sich alle Definitionen gegenseitig finden. Falls der Designer Fehler meldet, sollte der Modellierer die WSDL-Referenzen in den BPEL und PDD-Dateien kontrollieren.

Versuch macht klug

Ist der Prozess angelegt, lässt er sich im Simulator testen. Dazu führt der Anwender den Prozess mit »Run | Simulate Process« auf der internen Engine aus. Er setzt über den Tab »Process Variables« Parameterdaten von Hand, die im realen Betriebsfall ein weiterer Webservice von außen übergeben würde.

Arbeitet der Prozess wie gewünscht, stellt der BPEL-Anwender ein Deployment-Archiv zusammen (siehe Abbildung 4). Diese BPR-Datei ist ein Jar-Archiv und enthält alle Dateien, die nötig sind, damit der Prozess auf der Open-Source-Engine läuft. Der Anwender erzeugt die Datei über »File | Export | Orchestration | Business Process Archive File« und wählt »File« als Deployment-Typ. Das schreibt die BPR-Datei zunächst auf Festplatte. Optional lässt sich das Deployment direkt per Webservice an eine laufende Engine weitergeben.

Abbildung 4: Der Designer hilft die verschiedenen Modellierungsdateien in einem Business-Process-Archiv zusammenzufassen. Diese Datei führt ein Servlet-Container wie Tomcat unmittelbar aus.

Wer später mit Ant und ohne Designer weiterarbeiten möchte, erzeugt eine BPRD-Datei. Ein Deployment-Deskriptor beschreibt, wie eine Prozessdefinition ihren Weg in eine Workflow-Engine findet, und konfiguriert bislang abstrakt gebliebene Parameter. Diese Angaben fasst »reisebuchung.pdd« zusammen.

Der Entwickler beendet nun den Designer und startet Tomcat mit der darin installierten Active-BPEL-Engine. Um den neuen Prozess der Engine bekannt zu machen, reicht es, das BPR-Archiv in das Deployment-Verzeichnis »bpr« unterhalb der Tomcat-Installation zu kopieren. Nach wenigen Sekunden erkennt der Servlet-Container das Archiv. Das lässt sich unter [http://localhost:8080/BpelAdmin/deployment_log_detail.jsp] im Deployment-Log des Administrations-Interface überwachen.

Unter »Deployed Processes« listet es die installierten Prozesse. Startet ein Nutzer per SOAP-Anfrage einen Prozess vom Typ »reisebuchung«, zeigt das Admin-Frontend unter [http://localhost:8080/BpelAdmin/active_processes.jsp] seinen Zustand und Variableninhalte an. Die Darstellung des Prozesses im Webfrontend folgt dabei der Anzeige im Designer. Damit lässt sich auch mit der Workflow-Engine allein recht passabel experimentieren.

Gute Anbindung

Ein SOAP-Request gelingt mit jedem SOAP-Client, für schnelle Tests hat sich Soap UI bewährt [8]. Die WSDL-Definition von »reisebuchung()« lässt sich damit direkt von der laufenden Engine laden: [http://localhost:8080/active-bpel/services/ReisebuchungPartnerLinkService?wsdl]. Wer die Definitionen so importiert, hat die tatsächliche HTTP-Service-Adresse der Engine eingestellt und kann sofort loslegen und den Prozess in eigene Anwendungen integrieren.

Wegen seiner vielen Abstraktionsebenen ist Workflow-Management mit BPEL nicht ganz einfach. Mehrere Ansätze auf der Fachebene zur Prozessmodellierung, unterschiedliche Notationen, die erlaubten Varianten bei der Implementierung des Standards, die vielen Schichten einer SOA sowie die Vielfalt bei den Softwareprodukten fordern dem Architekten einer solcher Lösung viel Überblick ab. Fachliteratur dazu füllt eine kleine Bibliothek, einen pragmatischen Ansatz erklären Juric und Mitstreiter in einem als Tutorial tauglichen Buch [10]. Alle Beispiele kommen ohne Designer aus, denn die Autoren haben sie in XML kodiert.

Entwickler nicht arbeitslos

BPEL ist so universell, dass sich die meisten Businessvorgänge damit bearbeiten lassen. Den vielen konkurrierenden Methoden der Prozessmodellierung begegnet BPEL mit universellem Ansatz. Entwickler bleiben so flexibel und können gleich mehrere Methoden der Modellierung unterstützen. Sie sollten aber dennoch nicht die Komplexität unterschätzen: Ein WFMS auf Basis von BPEL verlangt vom Entwickler gute Kenntnisse der SOA-Technologie und von den Fachabteilungen ein klares Bekenntnis zur Prozesstechnologie.

Die Beschreibungssprache ist aber nicht als Werkzeug für die Marketingabteilung oder die Geschäftsführung geeignet, um frei jeder Technikbetrachtung Unternehmensprozesse zu definieren. Im Gegenteil: Ein Prozessdesigner muss sehr genau über die technischen Gegebenheiten in der unterliegenden SOA Bescheid wissen. Er benötigt Wissen zum WSDL-Standard, Kenntnisse von SOAP sind sinnvoll.

Die oft gehegte Vision, einfach den Chef die Arbeit machen zu lassen, erweist sich damit als Illusion. Das ist auch gar nicht der Sinn und Zweck dieser Technik: BPEL will eine technische Integrationsplattform für möglichst jede Art von fachlicher Prozessdefinition bieten. Wer den langen Atem hat, eine solche Struktur aufzubauen, freut sich später darüber, wenn alles im Fluss bleibt. (mg)