Grundlagen
Die Umsetzung eines kollaborativen Prozesses ist in drei Phasen unterteilt:
· Während des Designs entwerfen Sie den gesamten kollaborativen Prozess und leiten davon ab, welche Interfaces benötigt werden. Sie können entweder neue systemunabhängige Interfaces definieren, die später implementiert werden sollen (Outside-In-Entwicklung), oder mit bereits in den Systemen vorhandenen Funktionen arbeiten (Inside-Out-Entwicklung). In dieser Phase entwerfen Sie den logischen kollaborativen Prozess, indem Sie den Message-Austausch zwischen Anwendungskomponenten in einer spezifizierten Rolle beschreiben. Diese Beschreibung ist noch unabhängig von konkret installierten Systemen (siehe: Design-Zeit).
· Während der Konfiguration richten Sie ihren kollaborativen Prozess für eine konkrete Systemlandschaft ein. So können Sie beispielsweise Bedingungen für den Message-Fluss festlegen und Design-Objekte gemäß Ihrer Anforderungen auswählen. (Siehe: Konfigurations-Zeit.)
· Die Konfigurationsdaten werden zur Laufzeit ausgewertet und steuern die Kommunikation. Sie können den Nachrichtenfluss über ein zentrales Monitoring überwachen.
Diese Dreiteilung spiegelt sich in der Architektur wider:

· Um eine Übersicht über alle Daten zu haben, die für den systemübergreifenden Prozess relevant sind, gibt es für Design- und Konfigurations-Zeit jeweils eine zentrale Ablage: Das Integration Repository beziehungsweise das Integration Directory. Sie bearbeiten diese Daten mit einem gemeinsamen Werkzeug, dem Integration Builder. Die Inhalte des Integration Repository und des Integration Directory bezeichnet man als Collaboration Knowledge.
· Der Integration Server ist die zentrale ‚Verteilungsmaschine’ für Messages zur Laufzeit. Alle über den Integration Server miteinander kommunizierenden Systeme tauschen Messages über diesen Server aus. Auf logischer Ebene werden sie als Business-Systeme bezeichnet, in einer konkreten Systemlandschaft als technische Systeme oder Kommunikationspartner. Der Integration Server entscheidet an Hand der Konfigurationsdaten aus dem Integration Directory, an welche(n) Empfänger er die Message weiterzuleiten hat und ob davor ein Mapping ausgeführt werden muss.
Der Abschnitt Connectivity beschreibt, welche Möglichkeiten Sie haben, um Systeme an den Integration Server anzuschließen.
Im Integration Server legen Sie Objekte der Design-Zeit im Integration Repository und Objekte der Konfigurations-zeit im Integration Directory ab. Das System Landscape Directory (SLD) ist ein Produkt von SAP, um Produkte, Software-Komponenten, logische Systeme und technische Systeme zu beschreiben. Der Integration Server greift auf diese Informationen zur Design-, Konfigurations- und Laufzeit zu:
Beziehung zwischen SLD und Integration Repository / Integration Directory
Phase |
Verwendete Objekte im |
Design-Zeit |
|
Konfigurations-Zeit |
Technische Systeme (beispielsweise ein SAP-System), also in einer Systemlandschaft installierte Komponenten |
Die Trennung im Integration Builder zwischen Objekten eines logischen kollaborativen Prozesses und der konkret installierten Systemlandschaft findet sich also im SLD wieder, spiegelt sich aber nicht im Produktnamen wider (System Landscape Directory).
Siehe auch: System Landscape Directory in der Exchange Infrastructure.