Integrationsplattform

Schematische Darstellung einer Integrationsplattform

Als Integrationsplattform bezeichnet man ein Middleware-Produkt oder eine Kombination solcher Produkte, die es ermöglichen, verschiedene Applikationen im Sinne der Enterprise Application Integration (EAI) entlang der Wertschöpfungskette prozessorientiert zu verbinden. Teilweise wird der Begriff auch als Synonym für Business Bus verwendet.

Aufbau und Funktionsweise

Eine Integrationsplattform in diesem Sinne besteht, wie in der Graphik dargestellt, aus mindestens vier Komponenten. Die unterste Ebene stellt den Transport von Meldungen oder Aufträgen dar. Diese Aufgabe übernehmen typischerweise klassische Middleware-Produkte wie CORBA-Implementierungen (synchron) oder Messaging-Plattformen (asynchron). Um die Logik der Adressierung und Verteilung möglichst flexibel zu gestalten, enthalten diese Produkte in der Regel auch einen Message Broker, der anhand von Adressinformationen in der eingehenden Meldung oder Anfrage oder auch aufgrund des Inhalts die Daten an einen oder mehrere Adressaten verteilt. Dazu werden alle eingehenden Daten von der Transportebene direkt an den Message Broker weitergeleitet und dieser gibt sie adressiert an den Transport zurück.

Die Business Process Engine schließlich ermöglicht es komplexe Geschäftsprozesse abzubilden und zu automatisieren. Dazu leitet der Message Broker eingehende Meldungen an diese Engine weiter. Dort wird festgestellt, ob diese Meldung ein Ereignis darstellt, das als Auslöser (Trigger) eines Geschäftsprozesses definiert ist. In diesem Fall wird eine Instanz des Prozesses erzeugt und gestartet. In der Folge wird der erforderliche Meldungsaustausch ebenfalls über die Plattform realisiert.

Um die Spezifikation der Integration möglichst flexibel zu halten, werden die Regeln für den Message Broker und die Prozessdefinitionen in einem Repository gehalten und im laufenden Betrieb von einer Regelmaschine (engl.: Rules Engine) im Message Broker und der Business Process Engine interpretiert. Dieses Repository muss in der Lage sein, die hinterlegten Regeln und Prozesse zu versionieren, da es andernfalls bei einem Versionswechsel bei noch laufenden Prozessen zu Versionskonflikten kommen kann. Die Business Process Engine hinterlegt im Repository typischerweise auch die Zustände der laufenden Prozessinstanzen.

Beispiel

Ein Kunde möchte Online eine Reise buchen. Dazu spezifiziert er mehr oder weniger genau seine Reisewünsche wie Ziel, Unterbringung, Serviceleistungen, Preiskategorie etc. Diese Ausgangsmeldung initiiert einen Prozess zur Suche und Buchung der geeigneten Reise. Aufgrund der Kriterien veranlasst die Business Process Engine Suchaufträge hinsichtlich Anreisemöglichkeiten, z. B. mehrere Fluglinien, Hotelkapazitäten und weitere gewünschte Services wie etwa Mietwagen vor Ort. Aus diesen Informationen wird wenn möglich eine Liste von Angeboten erstellt. Sind die Angaben nicht ausreichend wird gemäß Prozessdefinition für die näher zu spezifizierenden Aspekte jeweils eine Optionsliste erstellt, um dem Anwender die Präzisierung zu erleichtern. Diese Informationen gehen zurück an die Internet-Applikation, wo sie entsprechend aufbereitet und präsentiert werden. Der Prozess geht damit in einen Wartezustand bis entweder der Anwender weitere Angaben sendet, die dann wieder ausgewertet werden oder eine voreingestellte Wartezeit überschritten ist, nach der man annimmt, dass sich der Anwender entschlossen hat, diese Anfrage nicht weiter zu verfolgen.