Agile Geschäftsprozesse durch die Verwendung von XML bei Modellierung, Daten und Steuerlogik Workflowbasierter Systeme (in EAI, SOA und Portalen)

Agile Geschäftsprozesse durch die Verwendung von XML bei Modellierung, Daten und Steuerlogik Workflow- basierter Systeme (in EAI, SOA und Portalen) Marc Pellmann, Dr. Torsten Schmale inubit AG Lützowstr. 105-106 D-10785 Berlin marc.pellmann@inubit.com torsten.schmale@inubit.com Abstract: Bei der Integration heterogener Systeme und Formate, wie sie von EAI [EAI01] Systemen durchgeführt werden, ist es wichtig, eine gemeinsame Welt zu finden, die innerhalb des Integrationsprozesses durchgängig erhalten bleibt. Hier bietet sich XML als Container der Daten und die damit verwandten Spezifikationen XSLT und XPath [XML01] zur Überführung und Abfrage der Strukturen an. Um alle Vorteile und Synergieeffekte nutzen zu können ist es wichtig, keine Brüche innerhalb der Daten und Kontrolllogik zu haben. Einleitung Die Abbildung automatisierter Geschäftsprozesse über Workflows unter Verwendung von XML Formaten für den Datenfluss und die Kontrollstrukturen, erlaubt eine einfache Integration von Systemen und Mitarbeitern. Sie sind ebenso das Mittel der Wahl für dynamische, agile Geschäftsprozesse. In etablierten Architekturen erfolgt die Anbindung von Systemen und die Erstellung von Portalen über klassische Programmiertechniken. Dies erschwert ein schnelles und unkompliziertes Anpassen der Logik an agile Prozesse wie sie in heutigen Unternehmen und Geschäftsbeziehungen in der Regel vorkommen. Durch eine SOA [SOA01] Architektur und die damit verbundene, lose Kopplung der Services über ein Workflow-System, kann schnell auf sich verändernde Businessprozesse und die darunter liegenden Systeme eingegangen werden. Dies wird im Folgenden anhand einiger Beispiele im inubit IS [IS01] dargestellt. Es wird auch gezeigt, welche Vorteile sich in erweiterten Bereichen wie einem Worfklow- getriebenen Web-Portal ergeben. 1 XML überall Die Realisierung der Abläufe über Workflows, die in einem graphischen Diagrammeditor zusammengestellt werden, ist ein geeignetes Mittel auf schnell verändernde Prozesse und Szenarien reagieren zu können. Innerhalb der Workflows werden diverse Module miteinander verbunden. Die Daten, die von Modul zu Modul fließen, liegen entweder in XML vor oder werden innerhalb des Workflows direkt in XML umgewandelt. Abb.1: Bild eines Workflows mit einem WS-Connector als Anfang Somit liegen die durch den Workflow fließenden Daten grundsätzlich in XML vor. Die Kontrolllogik innerhalb der Workflow arbeitet ebenfalls auf diesem XML (sowie auf erweiterten Kontrollvariablen, die mit dem XML in Interaktion stehen – vgl. Konformität zu [BPEL01]). Diese Durchgängigkeit der Verwendung von XML und den damit verwandten Techniken wie XSLT/XPath zur Transformation und Abfrage findet sich innerhalb der Module wieder. Abb.2: Graphische Erzeugung des WSDL 2 In der Benutzeroberfläche des Web Services Moduls (siehe Abb.2) wird die Struktur des erwarteten Aufrufes bzw. des Dokumentes graphisch definiert. Danach werden automatisch das WSDL und eine Mapping-Vorlage generiert. Wird dieses Web Services Modul nun am Anfang eines Workflows verwendet, kann dieser entsprechend der definierten Strukturen (bzw. entsprechend der generierten WSDL) aufgerufen werden. In der Ausführung auf dem Server reicht das Web Services Modul nur den Inhalt der Nachricht in XML an das nächste Modul im Workflow weiter (außerdem kann es natürlich eine Strukturüberprüfung durchführen, und behandelt die Fragen der Übertragung der Daten wie HTTPS, Client-Server Authentifizierung etc.). Im Gegensatz zu vielen anderen Lösungen gibt es hier keine Brüche der verwendeten Technologien. Das WSDL wird nicht in Java [J01] oder .NET [MS01] Code umgewandelt, der dann für die weitere Verarbeitung notwendig ist und tiefgehende Programmierkenntnisse erfordert. In der Regel wird das auf den Web Services Connector folgende Modul ein Steuermodul (hier ein Demultiplexer) sein, wenn verschiedene Methoden verarbeitet werden sollen. Es wird dann anhand einer XPath Abfrage entschieden, welche Zweige des Workflows weiter ausgeführt werden sollen. Abb.3: Demultiplexer zur Entscheidung über weitere Verarbeitung Enthält die Beschreibung des Web Service nur eine einzelne Methode oder ist der Web Service dokumentenorientiert, kann direkt mit einem XSLT Converter Modul weitergemacht werden (in Abb.3 nicht direkt sichtbar, da in verlinktem Workflow „Log WF Insert DB“). Dieses besteht innerhalb der Ausführung des Workflows auf dem Server aus einer XSLT Konvertierung, die verschiedenste XSLT-Prozessoren unterstützt. Die Konfiguration der Konvertierung innerhalb des Toolsets erfolgt über ein graphisches Mapping mit Test- und Debuggingsupport (siehe Abb. 4). Dies wird über ein einfaches drag-and-drop von Quellenachricht zur Zielnachricht erstellt. Auch hier werden XPath und XSLT verwendet. Erworbenes Know-how in den verschiedenen Standards um XML kann somit überall wieder verwendet werden, ohne dass imperative Programmiersprachen notwendig werden. In das XSLT kann auch jederzeit direkt eingegriffen werden, ohne das die Möglichkeiten der graphischen Abbildung beeinträchtigt würden, d.h. volles Round-Trip Engineering ist gewährleistet. 3 Abb.4: Ein Web Service wird auf einen anderen gemapped Der Übergang in andere Systeme ist in den Modulen gekapselt – die Schnittstelle ist immer in XML gestaltet. Als Beispiel wird hier die über den Web Service eingegangene, kundenindividuelle Preisanfrage einmal über ein SAP System und einmal über eine betriebsinterne Datenbank aufgelöst. Im Fall von SAP sind die IDoc/BAPI-Aufrufe in einem einfachen XML Format zu füllen. Im Fall der Datenbank (Abb. 5) ist die SQL- Abfrage ebenfalls in eine XML Syntax verpackt. Somit wird zu jeder Zeit ein gleichförmiges Vorgehen über die Standards der XML Welt sowie ein bekanntes Werkzeug genutzt. Abb.5: Preisanfrage geht an Datenbank und wird zusätzlich gelogged 4 2 Flexible Typisierung Bleibt man - soweit möglich - in der XML-Welt, hat man den Vorteil, dass eine hohe Typsicherheit durch die Verwendung von XML Schemata möglich aber nicht zwingend ist. Somit ist, wo dies gewünscht ist, eine höhere Fehlertoleranz erzielbar. Ein einfaches Beispiel soll diesen Vorteil zeigen. Abb. 1 vom Anfang dieses Textes zeigt einen Workflow der beliebige Web Service Aufrufe entgegennimmt und die übertragenen Daten in eine Datenbank speichert. Da es hier keine Typbindung und Auflösung in Java oder .NET Objekte gibt und die Validierung im Modul ausgeschaltet wurde, ist es kein Problem mit beliebigen SOAP Nachrichten umzugehen. Dieser Workflow dient nun dazu, die eingehenden Web Services in einer Datenbank zu protokollieren, um diese später abfragen zu können. In einem anderen Workflow kann dieser Web Service also für das Mitschreiben sowohl eingehender wie auch ausgehender Web Services genutzt werden (Siehe Abb. 3). Es ist lediglich notwendig, den bestehenden eingehenden oder ausgehenden Aufruf noch um eine ID anzureichern. Später können die geloggten Services dann über die ID und eine Zeiteingrenzung abgefragt werden. Zusätzlich wird ein XPath angegeben, der auf die XML Struktur der Services angewendet wird. Der Service der Abfrage ist dabei, entgegen dem Service des Loggings, typsicher definiert. Der Vorteil der sich hier ergibt liegt darin, dass beliebige Web Services über dieses Interface geloggt werden können. Es kann also jeder Web Service, der im Unternehmen Verwendung findet, mitgeschrieben werden. Es ist nicht notwendig intern zu loggen oder für jedes Logging einen neuen Web Service zu definieren. 3 Einbeziehung von Benutzerinteraktion Vom Eingreifen des Benutzers in den Integrationsprozess bis zu Workflow-getriebenen Portalen ist auch die Benutzerinteraktion über die XML-Welt abbildbar. Die Beschreibung von graphischen Benutzeroberflächen in XML ist State-of-the-Art. Hier sprechen wir von der XML UI Language (XUL) [XUL01] gesprochen. Dies meint im Speziellen das Format, das die Mozilla Foundation für Mozilla/Netscape/Firefox entwickelt hat und im Allgemeinen die Beschreibung einer graphischen Benutzeroberfläche in XML. Auch das kommende Windows Longhorn wird auf einen solchen XML Dialekt basieren, der dort XAML heißt. Der inubit IS bietet hier ein Format, das speziell auf die Anforderungen von Aufgabenlisten und Portalen innerhalb der Workflow-Ausführung zugeschnitten ist. Für die Darstellung kann zwischen HTML und Java/Swing gewählt werden. 5 Abb. 6: Beispiel eines einfachen Formulars Das Formular wird komfortabel über einen graphischen Formular Designer erstellt (Abb. 6). Die zur Verfügung stehenden Komponenten werden dabei über drag-and-drop in das Formular gezogen bzw. darin verschoben oder kopiert. Aus diesen Operationen entsteht ein vorgefülltes XSLT Skript, das nun nur noch in der gewohnten Art und Weise mit der in das Modul eingehenden Nachricht gemappt werden muss. Das Ergebnis des Formulars ist ebenfalls wieder XML. Zusätzlich zu der bekannten Art aus dem Quelldokument in das Zieldokument zu mappen, können die Elemente aus dem Quelldokument hier auch direkt auf das graphische Formular – z.B. ein Textfeld gezogen werden. Die entsprechenden XSLT- Transformationen werden dann automatisch generiert.