1 Einleitung

Applikationsintegration kann durch Kopplung von Anwendungen realisiert werden.

Bei Großkonzernen mit bereichsübergreifenden Applikationen ist hierfür eine Verein-

heitlichung der entsprechenden Schnittstellen hilfreich, um die Komplexität zu beherr-

schen [1]. In Umgebungen mit hunderten von Applikationen ist aber keine derart enge

Kopplung zwischen all diesen Anwendungen erreichbar: Punkt-zu-Punkt-

Verbindungen und sogar Medienbrüche sind auf längere Zeit unvermeidbar. Dennoch

ist eine (betriebswirtschaftliche) Steuerung und Optimierung der entsprechenden

gramme in ihrem Prozesskontext dargestellt werden können (vgl. Abb. 1b). Ein gene-

relles Problem solcher Performance-Manager ist allerdings, dass sie an diejenigen

Applikationen angebunden werden müssen, welche die Runtime-Daten verwalten.

Dies erfordert eine aufwendige Implementierung von Adaptern.

schaftlichen Literatur aufkommende Themen, deren Bedeutung zunehmend erkannt

wird [4]. Die Anbindung von WfMS wäre prinzipiell einfach möglich, weil diese

ohnehin über die relevanten Prozess- und Ausführungsinformationen verfügen. Des-

halb wird in diesem Bericht untersucht, wie eine entsprechende Anbindung so reali-

mit IBM Process Server), allerdings existieren hierfür bisher keine allgemeingültigen

Architekturen oder Konzepte. Deshalb werden im Abschnitt 2 geeignete Ansätze zu

Kopplung der Systemtypen untersucht. Abschnitt 3 skizziert geeignete standardisierte

Schnittstellen und geht auf Umsetzungsmöglichkeiten mit kommerziellen Systemen

ein, bevor Abschnitt 4 die Ergebnisse zusammenfasst.

2 Design-Varianten zur Kopplung der Systeme

Grundidee der nachfolgend vorgestellten Ansätze ist, einmalig zentral zu spezifizie-

ren, welche Ereignisse und Daten beim Performance-Management gemessen werden.

Ausbaustufe 1: Im einfachsten Fall erfolgt diese Spezifikation wie in Abb. 2a darge-

stellt mit einem Administrationswerkzeug. Bei diesem kann es sich z.B. um einen

Management-API zugegriffen werden. Dies hat den Vorteil, dass über dieses API

beliebige WfMS in das Performance-Management eingebunden werden können,

nachdem für das WfMS (einmalig und prozessunabhängig) ein entsprechender WfMS-

Adapter implementiert wurde. Der Performance-Manager (und sein zugehöriger

Performance-Management-Adapter) müssen also nicht an unterschiedliche WfMS

angepasst werden. Zusätzlich können aufgrund der einheitlichen Schnittstelle prob-

lemlos mehrere WfMS oder auch Legacy-Applications an denselben Performance-

Manager angebunden werden, was ein applikationsübergreifendes Monitoring ermög-

licht.

mance-Management-Produkten verwendet werden, da alle Performance-Management-

Adapter dasselbe API verwenden. Aufgabe eines solchen Adapters ist es, je nach

Performance-Management-Produkt, Statusabfragen an das WfMS weiterzuleiten bzw.

(z.B. periodisch) zu initiieren. Außerdem wandelt er die Ergebnisse in die vom jewei-

ligen Performance-Manager benötigte Form.

Prozesskosten) aus den Basisinformationen ist nur lokal für den Performance-Manager

eines WfMS werden ohnehin das Workflow-Modell inkl. der Ein- und Ausgabedaten

aller Aktivitäten definiert. Für jedes für das Monitoring relevante Modell wird nun für

die Aktivitäten zusätzlich festgelegt, ob sie für das Performance-Management relevant

sind. Außerdem wird angegeben, welche Daten beim Eintreten eines Ereignisses an

das Performance-Management übermittelt werden sollen. Allerdings sind die Model-

lierungs-Tools heutiger WfMS hierfür typischerweise nicht erweiterbar. Dies führt

dazu, dass gewisse Work-arounds notwendig werden, um in dem Tool die benötigten

Informationen festlegen zu können. So können hierfür z.B. benutzerdefinierbare

Attribute, reservierte Datenelemente oder Kommentarfelder verwendet werden. Diese

Vorgehensweisen sind zwar etwas unschön, aber durchaus akzeptabel, da das im

ein (leider häufig produktspezifisches) XML-Format an. Diese Prozessbeschreibung

wird dann geparst, um daraus den Input zur Steuerung des WfMS-Adapters abzulei-

ten. Es handelt sich hierbei um dieselbe Beschreibung, die bei der Ausbaustufe 1

manuell erstellt wird. Da sie aber automatisch abgeleitet wird, wird durch dieses

Vorgehen ihre Konsistenz gewährleistet. Außerdem reduziert der Ansatz den Aufwand

für die Erstellung und auch Wartung dieser Spezifikation: Da die benötigten Informa-

tionen im Workflow-Modell enthalten sind, muss im Fall von dessen Änderung ledig-

lich ein neuer Export und Parserlauf durchgeführt werden, um eine angepasste Spezi-

fikation für die Kopplung zu erhalten.

kation noch eine weitere für den Performance-Manager. Diese enthält eine Beschrei-

bung der Prozessstruktur. Diese ist nicht identisch mit der Prozessstruktur des

flows sind leicht lösbar. Außerdem ist der Aufwand für die Erstellung der Basis-

3 Realisierung der Schnittstellen und Abbildung auf Produkte

einer Datenbankoperation ist, dass alle Ereignisse (effizient) mit einer einzigen Anfra-

ge ermittelt werden können. Lediglich auf Anwendungsdaten und Bearbeiterinforma-

tionen der Aktivitäten muss für jede ermittelte Aktivität einzeln per Workflow-API [6]

zugegriffen werden. Das Workflow-Modell wird bei MQ Workflow mittels einer

FDL-Datei von der Modellierungskomponente zum Workflow-Server transferiert. Des

Weiteren ist die Anreicherung des Workflow-Modells um Zusatzinformation möglich,

die ebenfalls in die FDL-Datei geschrieben wird. Damit sind bei der Ausbaustufe 2