Integration heterogener Applikationstypen durch Workflow-Management-Technologie Thomas Bauer DaimlerChrysler Research and Technology, Abt. RIC/ED, Postfach 2360, D-89013 Ulm Thomas.TB.Bauer@DaimlerChrysler.com Zusammenfassung. In diesem Betrag wird ein EAI-Projekt mit einem etwas außergewöhnlichen Fokus vorgestellt: die Integration von Anwendungen von völlig unterschiedlichem Typ. Deren Kopplung ist erforderlich, da sie in dem- selben Anwendungskontext verwendet werden sollen. EAI-Technologie wird z.Zt. meist zur Daten- oder Funktionsintegration von solchen Anwendungen verwendet, die ähnliche Aufgaben erfüllen. Da die zu integrierenden Anwen- dungen kaum Gemeinsamkeiten aufweisen, ist eine Integration auf der Daten- oder Funktionsebene aber nicht möglich. Um im betrachteten Projekt dennoch eine Kooperation zu ermöglichen, wurde diese prozessbasierend umgesetzt. Unterstützt wird sie noch durch eine graphische Visualisierung von aktuell aus- geführten Prozessinstanzen. 1 Einleitung Das im Folgenden betrachtete Anwendungsbeispiel wurde von der DaimlerChrysler- Forschung gemeinsam mit Geschäftsbereichen umgesetzt. Es wurde in der Fahrzeug- entwicklung durchgeführt, der vorgestellte Ansatz lässt sich aber auf alle Anwen- dungsdomänen übertragen, in denen unterschiedliche Typen von Applikationen ein- gesetzt werden. Im vorgestellten Projekt muss das Projektmanagementsystem RPlan und ein eigenentwickeltes Controlling-Tool mit mehreren operativen Entwicklungs- systemen aus dem Bereich Elektrik/Elektronik (E/E) integriert werden. Die ersten beiden dienen der Steuerung eines Projekts, wohingegen die Operativsysteme den aktuellen Bearbeitungszustand dieses Projektes enthalten. Ziel der Systemintegration ist, den aktuellen Bearbeitungszustand dem Projektma- nagement zugänglich zu machen. Dadurch kann er Abweichungen eher erkennen und den Projektplan früher anpassen. Außerdem sollen die Entwickler, die mit den opera- tiven Systemen arbeiten, mit Planungsdaten (Projektabläufe und -termine) versorgt werden. Dies erlaubt den Sachbearbeitern, ihre Aufgaben besser in das Gesamtprojekt einzuordnen und ihre eigentlichen Aufgaben vorausschauender zu planen. Um unnö- tigen Zusatzaufwand zu vermeiden, ist eine Nebenbedingung, dass mehrfache Einga- ben derselben Daten vermieden werden, und Daten der verschiedenen beteiligten Systeme automatisch abgeglichen (d.h. ausgetauscht) werden. Schließlich existiert noch die Anforderung, dass das resultierende System sehr leicht zu bedienen ist und die Zusammenhänge einfach (wenn möglich graphisch) dargestellt werden. Als Hauptproblem stellte sich dabei heraus, dass existierende EAI-Ansätze eher auf Applikationen mit ähnlichem Verwendungszweck (z.B. Produktdatenmanage- ment- und Stücklistenverwaltungssysteme) abzielen. Eine Integration völlig unter- schiedlicher Anwendungstypen ist mit diesen Ansätzen hingegen nicht möglich, da weder bei den Daten noch bei den Funktionen eine nennenswerte Überlappung exis- tiert: Projektmanagementsysteme und E/E-Entwicklungswerkzeuge haben keine ge- meinsame Funktionalität. Die einzigen Daten, welche in beiden Systemen vorhanden sind, sind die tatsächlichen Bearbeitungszeiten und -zustände. Doch selbst diese lie- gen nicht im Fokus der Entwicklungssysteme, sondern finden sich eher implizit in den Historieninformationen. Da diese Daten nur einen extrem geringen Bruchteil der von diesen Systemen verwalteten Informationen darstellen, ist auch eine klassische Datenintegration hier nicht sinnvoll. Deswegen wurde in dem vorgestellten Projekt die Integration mittels eines Prozes- ses realisiert. Dieser ermöglicht den Datenaustausch zwischen den heterogenen Ap- plikationen. Durch eine Prozessvisualisierung wird den Beteiligten zusätzliche Infor- mation über Projektstruktur und -status bereitgestellt, sowie detaillierte Daten zu dem Bearbeitungszustand der einzelnen Projektaufgaben. Hierfür und zur Unterstützung der Prozessbearbeitung werden Daten aus den verschiedenen integrierten Anwen- dungssystemen verwendet. Ausgelesene sowie bei der Prozessausführung erzeugte Daten werden des weiteren auch in die Applikationssysteme geschrieben, so dass ein Datenabgleich realisiert wird. Die Systeme selbst bleiben aber unangetastet. 2 Verwandte Arbeiten Klassische Ansätze für EAI [10, 11, 14] versuchen Applikationen auf Daten- oder Funktionsebene zu integrieren. Wie schon erwähnt ist ein solcher Ansatz bei der gegebenen Aufgabenstellung nicht anwendbar, weil die betroffenen Systeme zu we- nig Überlappung bezüglich Daten und Funktionalität haben. Die Verwendung von Portalen [13] ist ebenfalls nicht zielführend, da sich durch diese lediglich ein gemeinsamer Einstiegspunkt für mehrere Anwendungssysteme realisie- ren lässt, und häufig auch nur lesender Zugriff unterstützt wird. Ein Datenaustausch zwischen den Systemen kann durch diese Vorgehensweise nicht realisiert werden. Ein Data-Warehouse [6] kann den Benutzern Informationen zur Verfügung stellen, die aus mehreren Quellsystemen stammen. Allerdings wird der direkte Datenaus- tausch zwischen den Quellsystemen durch diese Technologie nicht unterstützt. Des- halb ist es z.B. nicht möglich, den tatsächlichen Bearbeitungszustand in ein Projekt- managementsystem zurückzuschreiben, so dass er für die Projektplanung unmittelbar zur Verfügung steht. Auch eine prozessorientierte (graphische) Sicht auf den Ent- wicklungsablauf wird durch eine solche Datenzusammenführung nicht unterstützt, so dass dieser Ansatz hier nicht trägt. Workflow-Management-Systeme (WfMS) [7, 9] wurden eigentlich nicht zur Rea- lisierung von EAI-Lösungen, sondern zur Steuerung von Geschäftsprozessen entwi- ckelt. Da in diese Prozesse auch Geschäftsanwendungen eingebunden werden müs- sen, ermöglichen WfMS normalerweise den Aufruf von Applikationen als Teil- schrittprogramme. Häufig werden sogar schon vorgefertigte Adapter zu Standardap- plikationen wie SAP oder CICS angeboten (z.B. in WebSphere MQ Workflow [8]). Dadurch bieten WfMS eine gute Plattform zur Integration von heterogenen Applika- tionen, falls die Integration durch einen „People-Workflow“ erfolgen soll. Da WfMS zukünftig hoffentlich zunehmend anspruchsvolle Funktionalität wie Verteilung und Dynamik [2, 3, 4] unterstützen werden, stellen sie eine strategisch günstigere Imple- mentierungsplattform als z.B. Lotus Notes oder WebSphere MQ dar. Außerdem hel- fen sie schon heute den Implementierungsaufwand zu reduzieren, da WfMS Funktio- nalität wie Prozesssteuerung, Arbeitslistenverwaltung oder Monitoring bereits reali- sieren. Auch die mit EAI-Technologie zu integrierenden Applikationen können Prozess- logik enthalten. Außerdem ermöglichen EAI-Tools häufig die Definition von „Micro- flows“ zur Steuerung des Zugriffs auf Funktionen verschiedener Anwendungssyste- me bei der Ausführung einer Geschäftsfunktion. Diese werden allerdings automa- tisch, d.h. ohne Beteiligung von Personen, ausgeführt. In beiden Fällen befindet sich der Prozess aber eher auf einer semantisch niedrigeren Ebene und ist deshalb im Ge- gensatz zu WfMS nicht für eine stark prozessorientierte Applikationsintegration ge- eignet. 3 Prozessbasierende Applikationsintegration Ziel des Projektes war es, die folgenden Applikationssysteme (siehe Abb. 1) zu integ- rieren: Das Projektmanagementsystem RPlan von Actano [1] verwaltet die Abläufe, d.h. die Projektaufgaben und deren Abhängigkeiten, des Entwicklungsprojekts sowie die zugehörigen Termine auf einer sehr detaillierten Ebene. Das Messgrößenverwaltungssystem dient zum Controlling des Gesamtprojektes auf hohem Abstraktionsniveau. Es verwaltet Quality Gates, für deren Durch- schreiten definierte Messgrößen bestimmte Bedingungen erfüllen müssen. Die Festlegung der entsprechenden Messwerte erfolgt ebenso mit diesem System, wie die Verwaltung der Verantwortlichkeiten für Messgrößen und -werte. Im Elektrik/Elektronik (E/E) Bereich werden unterschiedliche Systeme zur Unter- stützung der Produktentwicklung eingesetzt. Aufgrund ihrer völlig unterschiedli- cher Aufgaben gibt es kaum Beziehungen zwischen ihnen, die gespeicherten Daten lassen aber jeweils Rückschlüsse auf den aktuellen Stand der Produktentwicklung zu. Hier seien exemplarisch zwei von ihnen vorgestellt: − Das automatische Testsystem für E/E-Aufbauten verwaltet u.a. die erzeugten Testergebnisse, welche wiederum Rückschlüsse auf den Reifegrad von E/E- Komponenten (z.B. Steuergeräte) zulassen. − In der Fehlerverfolgung des Prototypenbaus wird im Fall von entdeckten Fehl- funktionen ein Workflow ausgelöst, welcher der Beseitigung und Dokumentati- on des Problems dient. Die Anzahl und der Zustand dieser Prozesse erlauben einen Rückschluss auf den Reifegrad des E/E-Gesamtsystems. Es ist offensichtlich, dass eine direkte Daten- bzw. Funktionsintegration allenfalls für jeweils sehr wenige dieser Systeme und nur für kleine Teilfunktionalitäten möglich ist, da die Systeme zu extrem unterschiedlichen Aufgaben dienen. Eine solche Integ- Baureihen- Management Messgrößen- E/E-Management verwaltung Anpassung Werte von Zuständigkeiten der Termin- Messgrößen Termine Messgrößen planung Visualisierung Prozessstruktur E/E-Entwicklungs- EAI-Prozess Ausführungszustand verantwortliche Projektplanungs- information Ausführungs- status E/E- E/E-System E/E-System E/E-System Entwickler automatischer Fehlerverfolgung ... Komponententest Prototypenbau Abb. 1. Verwendung und Datenaustausch zwischen den integrierten Anwendungssystemen ration anzustreben wäre nicht sinnvoll. Teilweise ist ein Datentransfer zwischen den Systemen auch überhaupt nicht automatisierbar: So kann aus dem zeitlichen Verlauf der Fehlerprozess-Auslösung im Prototypenbau unter Berücksichtigung der jeweils unterschiedlichen Schwere des Fehlers – die nur aus dessen textueller Beschreibung ersichtlich ist – zwar auf den Bearbeitungszustand der Aufgabe „Entwicklung von in Fahrzeug erprobungswürdigen E/E-Komponenten“ geschlossen werden, aber sicher- lich nicht automatisch. Da die semantisch tieferliegenden Ebenen ausscheiden, muss die Systemintegrati- on über den Geschäftsprozess erfolgen. Dessen Ausführung erlaubt das automatische Sammeln von Daten ebenso wie eine menschliche Interaktion, dort wo sie notwendig ist (z.B. zur Aggregation von Daten). So kann automatisiert von mehreren Aktivitäten aus auf verschiedene E/E-Systeme zugegriffen werden. Ebenso können Projektmana- gementinformationen aus RPlan gelesen werden und E/E-Applikationen gezielt zur Verfügung gestellt werden. In [5] haben wir bereits aufgezeigt, dass bei unterschied- lichem Abstraktionsniveau der Projektplanung und der operativen Tasks bzw. Work- flows eine Zwischenschicht für die Informationszuordnung und Aggregation erfor- derlich ist. Es hat sich herausgestellt, dass diese im vorliegenden Szenario nur pro- zessorientiert realisiert werden kann. Um den Aufwand hierfür zu reduzieren und die Flexibilität zur erhöhen, wurde dies mit dem WfMS Lotus Workflow [12] durchge- führt. Die Aktivitäten des Workflows werden i.d.R. von sog. Funktionsgruppensprechern bearbeitet, die jeweils für die Entwicklung von logisch zusammengehörigen E/E- Komponenten verantwortlich sind. Diese legen im Rahmen dieses Prozesses auch die Werte von Teilmessgrößen fest, aus denen sich dann die Messgrößenwerte ergeben. Die Messgrößen werden von der in Abb. 1 entsprechend benannten Applikation ver- waltet. Einige Prozessschritte lesen von ihr die Beschreibungen und Zuständigkeiten von Messgrößen und schreiben nach der Bearbeitung der entsprechenden Aktivitäten auch Werte von Messgrößen zurück. Durch diese Vorgehensweise wird verhindert, dass ein Benutzer mit mehreren Applikationen arbeiten muss. Die Oberfläche des WfMS und die entsprechenden Masken als einzige Benutzerschnittstelle für die Funktionsgruppensprecher tragen deutlich zur Akzeptanz des Ansatzes bei. 4 Visualisierung von Prozessinstanzen Das vorgestellte Projekt zeigt, wie eine Applikationsintegration mit Hilfe eines WfMS durchgeführt werden kann. Dies ist sicherlich nicht das erste Projekt, in dem diese Vorgehensweise gewählt wurde, da EAI-Systeme und WfMS deutliche Über- lappungen ihrer Funktionalität aufweisen. Allerdings wurde im betrachteten Projekt auch noch ein Nebeneffekt genutzt, der sich als großer Vorteil herausstellte: Der bisher nur implizit gelebte Prozess wird nun explizit verfügbar, und das einschließlich seines aktuellen Abarbeitungszustandes. Dies bildet eine ideale Basis zur Information aller Prozessbeteiligten. So dient der Ausführungszustand natürlich der Projektleitung zur Planung und zum Controlling. Die Prozessvisualisierung wird aber auch zur In- formation der Sachbearbeiter verwendet: Die Entwickler kennen meist weder die Projektpläne und Termine eines Fahrzeugprojektes, noch den abstrakten Gesamtpro- zess. Deshalb ist es ihnen nicht möglich, ihre konkreten Aufgaben in den Gesamt- kontext einzuordnen. Dies führt wiederum dazu, dass sie auf sich zukommende Ver- zögerungen nicht rechtzeitig erkennen und die Auswirkungen von selbst verursachten Verspätungen nicht einschätzen können. Die Darstellung der im WfMS vorhandenen Information erfolgt idealerweise durch die graphische Visualisierung einer Prozessinstanz, da dies für „normale Benutzer“ wesentlich leichter verständlich ist als Listen, Kennzahlen oder Tabellen. Leider ist die Funktionalität der Visualisierungs- bzw. Monitoringkomponenten heutiger WfMS hierfür bei weitem nicht ausreichend. So zeigt Abb. 2 die Standard-Prozessvisualisie- rung von Lotus Workflow. Diese war den interviewten Endbenutzern deutlich zu unübersichtlich und ermöglicht zudem nicht, alle relevante Laufzeitinformation dar- zustellen. Diese Schwachpunkte sind aber keineswegs Lotus Workflow spezifisch; die entsprechende Funktionalität anderer WfMS ist sogar größtenteils noch geringer. So gelten eigentlich bei allen Standard-Visualisierungskomponenten die folgenden Beschränkungen: Es kann nur direkt diejenige Sicht auf den Workflow dargestellt werden, die bei der Modellierung erzeugt wurde. Dies ist aber eher ein technischer Blickwinkel, d.h. er beinhaltet auch automatische Aktivitäten (z.B. zur Zusammenführung von Dokumenten bei Joins) oder durch das Metamodell bedingte Subworkflows. Da- durch wird die Darstellung für nicht IT-geschulte Anwender zu unübersichtlich. Es können nur WfMS-interne Attribute wie Bearbeiter oder Startzeiten dargestellt werden. Es ist meist nicht möglich, Anwendungsdaten zu Visualisieren (z.B. Be- zeichnungen von E/E-Komponenten, vom Bearbeiter angegebene Abarbeitungszu- stände laufender Aktivitäten oder voraussichtliche Beendigungstermine). Dies sind allerdings Daten, die für die Entwickler höchst relevant sind. Die graphische Darstellung ist häufig sehr unübersichtlich. Normalerweise kann diese auch nicht um Zusatzinformationen angereichert werden, welche die Über- sichtlichkeit erhöhen würden. So könnte z.B. die Zusammengehörigkeit von Akti- xyz Abb. 2. Visualisierung einer Prozessinstanz in Lotus Workflow vitäten eines Bereichs durch das Einblenden eines farbig ausgefüllten Rechtecks als Hintergrund deutlich gemacht werden. Auch Texte mit Zusatzinformationen und (gestrichelte) Pfeile zwischen Aktivitäten mit informellem Informationsaus- tausch wären geeignet, um die Übersichtlichkeit zu erhöhen. Um eine derart erweiterte Darstellung zu ermöglichen, wurde im vorgestellten Projekt eine Visualisierungskomponente (siehe Abb. 3) selbst implementiert. Diese verwen- det das bei der Workflow-Modellierung erzeugte (und dann exportierte) Prozessmo- dell, ein selbst definiertes Visualisierungsmodell und Anwendungsdaten, die teilweise außerhalb des WfMS gespeichert sind. Die Verbindung dieser Laufzeitdaten mit der Workflow-Instanz wird durch einen „Datenzugriffsabschnitt“ im Visualisierungsmo- dell definiert. Die gesamte Implementierung ist mit Ausnahme des Visualisierungs- modells anwendungsunabhängig. Dieses wird in Form einer XML-Datei festgelegt (deren DTD selbstverständlich ebenfalls anwendungsunabhängig ist), die eigentlich automatisch vom Modellierungswerkzeug des WfMS aufgrund von Darstellungsfest- legungen des Modellierers erzeugt werden sollte. Da heutige WfMS hierzu nicht in der Lage sind, wird die Generierung durch eine manuelle Erstellung simuliert. Da- durch entsteht natürlich das Problem, dass die Konsistenz des Visualisierungsmodells mit dem Workflow-Modell im Falle von dessen Änderung nicht garantiert werden kann. Abb. 3. Benutzergerechte Visualisierung einer Workflow-Instanz Bei manchen Daten einiger Applikationssysteme erfolgt die Integration nicht durch ein direktes Schreiben einer automatischen Aktivität des Prozesses, sondern durch eine Benutzeraktion. Dies ist für eine Änderung der Pläne des Projektmanagement- systems auch der einzig gangbare Weg, weil eine automatische Umplanung aufgrund der Komplexität einer solchen Operation kaum vorstellbar ist und außerdem viel zu gefährlich wäre. Stattdessen wird die Visualisierung des aktuellen Ausführungszu- standes (bei der auch aufgetretene Verzögerungen dargestellt werden) genutzt, um den Projektmanager bei dessen Analyse zu unterstützen. Dieser zieht dann selbst die entsprechenden Schlüsse und passt den Projektplan manuell an (angedeutet durch den gestrichelten Pfeil in Abb. 1). 5 Zusammenfassung und Ausblick Im vorgestellten Projekt war es die Aufgabe, Anwendungssysteme zu integrieren, für die dies wegen ihrer zu unterschiedlichen Einsatzgebiete mit den normalerweise ver- wendeten EAI-Methoden nicht möglich ist. Deshalb wurde eine Lösung gewählt, bei der die Integration über einen Geschäftsprozess erfolgt, der hierzu mittels eines WfMS implementiert wurde. Durch dessen Ausführung wird einerseits ein automati- scher Datenaustausch zwischen den Applikationen realisiert, andererseits werden auch intellektuelle Entscheidungen der Prozessbeteiligten möglich. Um diese Ent- scheidungen auf solide Beine stellen zu können und zur Information aller Prozessbe- teiligten, erwies sich die Visualisierung des ausgeführten Prozesses als sehr geeignet. Deshalb wurde eigens eine Visualisierungskomponente entwickelt. Für die Zukunft bleibt zu hoffen, dass die WfMS-Hersteller eine entsprechende Visualisierungsfunk- tionalität in ihre Systeme übernehmen werden, da ein sehr enger Bezug zur Modellie- rungskomponente des WfMS existiert. Damit wäre eine bedarfsgerechte Visualisie- rung ohne Zusatzaufwand für die jeweiligen Projekte verfügbar. Abgesehen von dem Schwachpunkt der Visualisierung haben wir festgestellt, dass sich WfMS gut für die beschriebene Integration eignen, weil die Anforderungen an das Metamodell, die Workflow-Steuerung usw. im betrachteten Projekt nicht über- mäßig hoch waren. Die Verwendung eines WfMS führt zu einem recht geringen Initialaufwand bei der Implementierung der prozessorientierten Applikation. WfMS bieten häufig schon vorbereitete Schnittstellen zu zahlreichen Typen von Anwen- dungssystemen. Abhängig von den konkret zu integrierenden Anwendungen können diese zu einer zusätzlichen Reduzierung des Umsetzungsaufwands führen. Da im konkreten Projekt hauptsächlich proprietäre Anwendungen ohne definierte Schnitt- stellen zu integrieren waren, blieb hier als einzige Lösung meist nur der Zugriff auf die Applikationsdatenbank zur Integration, so dass nicht von angebotenen Schnitt- stellen profitiert werden konnte. Dennoch hat sich das verwendete WfMS als sehr geeignete Implementierungsplattform erwiesen. Literatur 1. Actano: RPlan. http://www.actano.de 2. T. Bauer: Effiziente Realisierung unternehmensweiter Workflow-Management-Systeme. Dissertation Universität Ulm, Tenea-Verlag. (2001) 3. T. Bauer, M. Reichert, P. Dadam: Dynamische Ablaufänderungen in verteilten Workflow- Management-Systemen. Datenbank-Spektrum, Vol. 1(1). (2001) 68-77 4. T. Bauer, M. Reichert, P. Dadam: Intra-Subnet Load Balancing in Distributed Workflow Management Systems. Int. Journal of Cooperative Information Systems, Vol. 12(3). (2003) 295-323 5. T. Bauer, R. Siebert: Requirements and Methods for the Coupling of Project and Workflow Management Systems. In: Proc. ProSTEP iViP Conf. on Advances in Collabo- rative Product Creation, Dresden. (2003) 173-185 6. S.R. Gardner: Building the Data Warehouse. Communications of the ACM, Vol. 41(9). (1998) 52-60 7. D. Georgakopoulos, M. Hornick, A. Sheth: An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases, Vol. 3(2). (1995) 119-152 8. IBM: MQSeries Workflow - Concepts and Architecture. (2001) 9. S. Jablonski, M. Böhm, W. Schulze: Workflow-Management: Entwicklung von Anwen- dungen und Systemen. dpunkt-Verlag. (1997) 10. M. Kaib: Enterprise Application Integration - Grundlagen, Integrationsprodukte, Anwen- dungsbeispiele. Dissertation Universität Marburg, Deutscher Universitäts-Verlag. (2002) 11. W. Keller: Enterprise Application Integration - Erfahrungen aus der Praxis. dpunkt- Verlag. (2002) 12. Lotus: Domino Workflow Application Development. (2000) 13. J. Rütschlin: Ein Portal - Was ist das eigentlich? In: Proc. GI/OCG-Jahrestagung, Wien. (2001) 691-696 14. D. Serain: Middleware and Enterprise Application Integration. Springer. (2002)