Entwicklung von Message-Interfaces 
Einsatzmöglichkeiten
Mit plattform-unabhängigen Message-Interfaces können Sie vor der eigentlichen Implementierung Ihres systemübergreifenden Prozesses die Art der Kommunikation und die auszutauschenden Daten festlegen. Siehe auch: Einführung in die Interface-Entwicklung.
Überblick
Die folgende Abbildung zeigt das Klassenmodell für Message-Interfaces im Integration Builder:
Message-Interfaces werden wie alle Repository-Objekte über Repository-Namensräume organisiert, die einer Software-Komponentenversion zugeordnet sind (siehe auch: Organisation der Auslieferungsinhalte).
Sie können Message-Interfaces auf folgende Weise aufbauen:
· Über Message-Typen und Datentypen. Dieser zweistufige Aufbau ist eng an WSDL (Web Service Description Language) angelehnt und auf einen hohen Wiederverwendungsgrad ausgerichtet. Kunden können zusätzlich mit Datentyp-Erweiterungen eigene Felder zu einer Message hinzufügen.
Die Einführung der Zwischenebene von Message-Typen scheint auf den ersten Blick unnötig, ist aber auf XML-Ebene nötig, damit eine Message als eine eigene Instanz behandelt werden kann. Datentypen in XML Schema definieren an sich noch keine solche Instanz, weil ein Datentyp noch kein Element definiert.
· Optional über Fault-Message-Typen, mit denen Sie anwendungsspezifische Fehler behandeln können.
· Über RFC- oder IDoc-Messages, als Gegenstück zu einem RFC beziehungsweise IDoc im SAP-System.
· Über externe WSDL-, XSD- und DTD-Definitionen, deren enthaltene Message-Schemas sie verwenden können.
Zusammenfassend bezeichnet man diese Objekte und Kontextobjekte als Interface-Objekte.
Voraussetzungen
Bevor Sie Message-Interfaces im Integration Builder entwickeln können, müssen Sie eine Software-Komponentenversion importiert haben und für diese einen oder mehrere Repository-Namensräume angelegt haben (siehe: Software-Komponentenversion anzeigen/ändern).
Zu den Systemvoraussetzungen siehe außerdem den Abschnitt Voraussetzungen in Einführung in die Interface-Entwicklung.
Ablauf
Der hier skizzierte Ablauf beschränkt sich auf die technische Sicht bei der Entwicklung von Message-Interfaces und geht nicht auf generelle Richtlinien für das Design von Interfaces und Datentypen ein.
...
1. Abhängig von den beteiligten Kommunikationspartnern gehen Sie folgendermaßen vor (Siehe auch: Kommunikationspartner (Fallbeispiele)):
¡ Wenn Sie die Objekte für Ihre Interface-Definition im Integration Builder anlegen:
i. Um den Inhalt der auszutauschenden Messages festzulegen, benötigen Sie Datentypen. Stellen Sie fest, ob schon Datentypen für die von Ihnen benötigten Interfaces existieren (zum Beispiel über die Suchhilfe). Legen Sie bei Bedarf neue Datentypen an.
ii. Um eine Message selbst referenzieren zu können (zum Beispiel beim Mapping), müssen Sie einen Message-Typ verwenden, der auf einen Datentyp verweist. Prüfen Sie, ob ein entsprechender Message-Typ bereits existiert und legen Sie bei Bedarf einen neuen Message-Typ an. Im einfachsten Fall benötigen Sie einen Message-Typ für die Request-Message und zusätzlich bei synchroner Kommunikation einen Message-Typ für die Response-Message.
iii. Für die Behandlung von anwendungsspezifischen Fehlern, die auf Inbound-Seite auftreten, können Sie optional Fault-Messages verwenden. Prüfen Sie, ob ein entsprechender Fault-Message-Typ bereits existiert und legen Sie bei Bedarf einen neuen Fault-Message-Typ an.
iv. Legen sie ein Message-Interface an und verweisen Sie auf den angelegten Message- und Fault-Message-Typ.
¡ Wenn Sie auf Definitionen aus Anwendungssystemen zugreifen:
...
i. Importieren Sie Ihre Message-Schemata aus externe Definitionen oder RFC beziehungsweise IDocs aus SAP-Systemen. Die Datentypen sind bereits in diesen Definitionen enthalten.
ii. Legen sie ein Message-Interface an und verweisen Sie auf die Messages der externen Definition oder auf die RFC- beziehungsweise IDoc-Message.
2. Für einen Message-Austausch benötigen Sie immer ein Interface-Paar. Sie können Message-Interfaces mit beliebigen anderen Interfaces kombinieren. Die folgende Tabelle gibt ein paar Beispiele:
Kommunikationspartner für Message-Interfaces mit Interfaces im Integration Repository
Message-Interface-Kategorie |
Mögliches Gegenstück |
Art der Kommunikation |
Outbound-Message-Interface |
Inbound-Message-Interface |
Proxy-Proxy-Kommunikation |
Abstraktes Message-Interface |
(Outbound- oder Inbound-Message-Interface) |
Proxy-Prozess-Kommunikation |
Message-Interface |
RFC-/IDoc-Interface |
Proxy-RFC oder |
Der Kommunikationspartner eines Message-Interface kann auch ein Interface sein, dass sich nicht in das Integration Repository importieren lässt. Siehe auch: Kommunikationspartner (Fallbeispiele).
3. Legen Sie das Gegenstück zur Kommunikation im Integration Builder (Design) an beziehungsweise importieren Sie es.
4. Erfassen Sie Dokumentation zu den von Ihnen angelegten Objekten.
Ergebnis
Das Message-Interface mit den referenzierten Message-Typen und Datentypen wird vom Integration Builder im Integration Repository abgelegt. Sie können nun:
· Kontextobjekte für Felder Ihrer Request-Message anlegen, die in Prozessen oder beim logischen Routing in Bedingungen verwendet werden sollen.
· Ausgehend von einem Message-Interface mit Hilfe der Proxy-Generierung ein Java- oder ABAP-Proxy generieren.
·
Abstrakte Message-Interfaces in einem 
systemübergreifenden
Integrationsprozess einsetzen, um die Prozesssignatur
festzulegen.
· Parallel zur Entwicklung der Laufzeitkomponenten mit dem Design von Mappings beginnen.
· Auf das Message-Interface beim Design von Integrationsszenarien verweisen.
· Optional ein XSD- beziehungsweise WSDL-Dokument als lokale Datei aus dem Repository exportieren (siehe: XSD- und WSDL-Dokumente exportieren).
Die Grafik in dem Abschnitt Objektverweise stellt die Beziehungen der Interface-Objekte untereinander und zu anderen Design-Objekten dar.