Konfigurations-Zeit 

Zur Konfigurations-Zeit werden die systemübergreifenden Prozesse für eine bestehende Systemlandschaft konfiguriert. Die Konfiguration beschreibt, wie der Integration Server eingegangene Messages verarbeitet und an welche(n) Empfänger sie weitergeleitet werden. An der Verarbeitung sind verschiedene Engines auf dem Integration Server beteiligt: Die Integration Engine als zentrale Laufzeitkomponente, die Adapter Engine als Laufzeitkomponente für die Adapter-Kommunikation und die Business Process Engine als Laufzeitkomponente für die Ausführung von Integrationsprozessen auf dem Integration Server. Im einzelnen sind folgende Dienste des Integration Servers zu unterscheiden:

·      Sowohl die Adapter Engine als auch die Integration Engine haben eine Eingangs- und Ausgangsverarbeitung. Beim Empfang einer Message wird dabei beispielsweise geprüft, ob der Sender berechtigt ist, an den Integration Server zu senden.

·      Die Integration Engine ermittelt Empfänger in zwei Schritten:

¡      Logische Empfänger werden über das logische Routing bestimmt.

¡      Technische Empfängerinformationen werden über das technische Routing bestimmt.

Diese Trennung entkoppelt den logischen Empfänger von dem technischen, so dass technische Adressen (beispielsweise eines Applikationsservers) einfacher ausgetauscht werden können, ohne den darüber liegenden logisch definierten kollaborativen Prozess zu beeinflussen.

·      Die Integration Engine ermittelt an Hand der Konfiguration, ob ein Mapping ausgeführt werden muss, ermittelt es und ruft das Mapping-Programm auf.

·      Die Business Process Engine führt optional Integrationsprozesse aus. Sie kommuniziert mit der Integration Engine, um Mappings auszuführen und um Messages zu empfangen und zu senden.

Die folgende Grafik gibt einen Überblick über die Ausführung dieser Dienste auf dem Integration Server und stellt dar, welche Informationen aus dem Integration Directory dafür benötigt werden:

Zur Vereinfachung sind im Bild nur die essentiellen Dienste abgebildet. Außerdem gibt das Bild nur den logischen Ablauf bei der Verarbeitung einer Message wieder. So werden beispielsweise die Directory Daten eigentlich nicht direkt aus dem Integration Directory sondern aus einem Cache gelesen.

Konfiguration der Engines auf dem Integration Server im Integration Directory

Da die Anforderungen an ein Integrationsszenario beim Kunden unterschiedlich sein können, sind Inhalte des Integration Directory keine Auslieferungsinhalte. Es ist die Aufgabe von Beratern und Administratoren die Daten im Integration Directory beim Kunden zu konfigurieren. Bei der Konfiguration beziehen Sie sich auf Objekte der Design-Zeit im Integration Repository (angesprochene Dienste des Integration Directory sind unterstrichen):

·      Konfigurationsszenarien gruppieren Konfigurationsobjekte im Integration Builder. Die Objekte, die Sie für ein Scenario anlegen, können Sie auch in anderen Konfigurationsszenarien wiederverwenden. Um Konfigurationsobjekte automatisch für ein Scenario generieren zu lassen, können Sie ein Integrationsszenarien aus dem Integration Repository als Vorlage verwenden.

·      Um die Konfiguration für verschiedenste Konfigurationsszenarien offen zu halten und Wiederverwendung zu unterstützen, legen Sie die Art der Kommunikation und die beteiligten Kommunikationspartner in zwei Schritten fest:

¡      In Kommunikationsprofilen legen Sie die technischen Möglichkeiten von Sendern und Empfängern fest und wie man sie identifiziert. Ein Profil umfasst die folgenden Informationen:

§       Gerade im B2B-Umfeld werden Sender beziehungsweise Empfänger über unterschiedliche Methoden identifiziert (beispielsweise über eine DUNS-Nummer oder eine EAN-Nummer). In SAP XI geben Sie alle Möglichkeiten, einen Sender beziehungsweise Empfänger zu identifizieren mit Hilfe des Objektes Kommunikationspartner an. In der weiteren Konfiguration ist es dann nicht mehr nötig, mit verschiedenen externen Identifikatoren zu arbeiten, sondern Sie verwenden einfach den angelegten Kommunikationspartner, bei dem alle möglichen Arten zur Identifizierung hinterlegt sind. Man bezeichnet diese Vorgehensweise auch als Empfänger- beziehungsweise Sender-Normalisierung.

§       Um auf logischer Ebene beschreiben zu können, welche Adressaten miteinander kommunizieren, arbeiten Sie mit Services. Ein Service kann beispielsweise ein Business-System oder ein Integrationsprozess sein. Sie können Kommunikationspartnern mehrere Services zuweisen oder auch einen Service ohne konkreten Kommunikationspartner konfigurieren.

§       Der Service spezifiziert noch keine technischen Details des Message-Austauschs. Je nach Art des Service verweisen Sie auf Interfaces und einen oder mehrere Kommunikationskanäle. Letzterer bestimmt, wie Sie einen Kommunikationspartner technisch adressieren können, beispielsweise, welcher Adapter benötigt wird.

In einem Kommunikationsprofil sind also alle technischen Möglichkeiten und ‚öffentliche’ Interfaces von Sendern und Empfängern abrufbar.

¡      Über Kommunikationsvereinbarungen legen Sie für eine Auswahl von Sendern und Empfängern fest, welche im Kommunikationsprofil beschriebenen Möglichkeiten zur Laufzeit gültig sein sollen. Sie wählen hierzu beispielsweise für das technische Routing denjenigen Kommunikationskanal aus, der für eine Gruppe von Interfaces aktiv sein soll (beispielsweise einen Kanal, der für alle IDoc-Messages vorgesehen ist). Kommunikationsvereinbarungen steuern die Eingangs- und Ausgangsverarbeitung.

·      Das logische Routing arbeitet auf Services und ist über Routing-Regeln festgelegt:

¡      Empfängerermittlungen legen den Service fest, an den die Message gesendet werden soll. Zusätzlich können Sie Bedingungen festlegen, die für die Weiterleitung der Message erfüllt sein müssen.

¡      Der Interface-Ermittlung, über die Sie einem Sender-Interface ein Empfänger-Interface zuordnen.

·      Die Interface-Ermittlung bestimmt, welches Sender-Interface zu welchem Empfänger-Interface gehört. Wenn für dieses Interface-Paar ein Mapping ausgeführt werden soll, können Sie dieses Mapping aus dem Integration Repository auswählen und bei der Interface-Ermittlung zuweisen. Vor der Laufzeit wird das eigentliche Mapping-Programm aus dem Repository geladen und auf dem Integration Server abgelegt.

Zusammengenommen bestimmen die Kommunikationsvereinbarungen sowie die Empfänger- und Interface-Ermittlung den Empfänger einer Message und ob ein Mapping ausgeführt werden muss.

Kommunikationspartner und System Landscape Directory

Das System Landscape Directory (SLD) beschreibt eine Systemlandschaft. Innerhalb einer Systemlandschaft sind folgende Systemtypen zu unterscheiden:

·      Business-Systeme, die den logischen Empfänger unabhängig von technischen Eigenschaften benennen. Ein Business-System kann beispielsweise der Mandant eines SAP-Systems sein.

·      Technische Systeme, mit denen die Hardware des Systems genauer spezifiziert wird (Serverdaten, etc.).

Ein Kunde, der SAP XI einsetzt, muss alle Business-Systeme und ihre zugeordneten technischen Systeme im SLD eingetragen haben, bevor er mit der Konfiguration beginnen kann. Da sich das SLD auf die Systemlandschaft eines Kunden bezieht, brauchen Sie bei einem Unternehmensübergreifenden Scenario keine Systeme von Geschäftspartnern im SLD einzutragen.

Die folgende Tabelle gibt abschließend einen Überblick, wie Sie im Integration Builder mit den Objekten Kommunikationspartner, Service und Kommunikationskanal bei der Konfiguration Sender und Empfänger zu identifizieren und ihre technischen Möglichkeiten beschreiben:

Objekte des Kommunikationsprofils und ihre Verwendung

Objekttyp	Verwendung	SLD-Eintrag?
Kommunikationspartner	Mit dem Objekt Kommunikationspartner identifizieren Sie eine Unternehmenseinheit, die im folgenden als Sender oder Empfänger konfiguriert werden kann. B2B-Kommunikation baut auf die hier angegebenen Identifikatoren auf. Kommunikationspartner sind optional.	nein
Service vom Typ Business-Service	Service für Unternehmensübergreifenden Message-Austausch. Sie können unabhängig von einem System Interfaces und Kommunikationskanäle für Business-Services angeben.	nein
Service vom Typ Integrationsprozess-Service	Service für den Austausch von Messages mit einem Integrationsprozess	nein
Service vom Typ Business-System-Service	Service für den Austausch von Messages mit einem Business-System. Das Business-System, das zugehörige technische System und die Zuordnung zwischen beiden muss im System Landscape Directory (SLD) eingetragen sein.	ja
Kommunikationskanal	Legt die Laufzeitkomponente fest, über die Messages empfangen und gesendet werden: Der Adaptertyp XI steht für Proxy-Kommunikation über die Integration Engine, alle anderen stehen für Adapter-Kommunikation über die Adapter Engine.	nein