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.
|
Active-BPEL implementiert den BPEL-Standard in der Version 2.0. Die Engine steht unter der GPLv2. Als JEE-Webapplikation läuft sie zusammen mit einem Servlet-Container wie Apache Tomcat. Der visuelle Editor für BPEL-Prozesse, Designer genannt, ist eine Eclipse-RCP-Anwendung. Sie lässt sich 30 Tage kostenlos nutzen. Dazu beantragt der Anwender eine Testlizenz von der Downloadseite, die der Hersteller per E-Mail verschickt [7]. Entwickler dürfen auch andere Designer mit der Active-BPEL-Engine verwenden. Die Eclipse-Foundation etwa entwickelt einen eigenen Editor.
Der Hersteller Active Endpoints bietet den Designer für Windows und Linux als Eclipse-Plugin an. Zusammen mit der Engine erlaubt er es, Prozesse zu debuggen: Er setzt Breakpoints, führt Code schrittweise aus und simuliert Prozessläufe. Die Active-BPEL-Engine stellt sie jedoch auch als Webservice bereit, sodass jeder Client sie nutzen kann.
Das Deployment von Prozessen erfolgt entweder über ein Verzeichnis auf der Festplatte oder per Webservice. Damit lässt es sich selbst als Teil eines BPEL-Prozesses verwenden - sinnvoll für eine Vorverarbeitung oder das Prüfen neuer Prozesse. Die Entwickler unterstützen Anwender entweder über ein kostenloses Webforum oder mit kommerziellem Support. Den bieten außerdem auch Dritte an.
|
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.
« Zurück
1
2
3
4
5
6
7
Weiter »