Interface- und Message-Typen 

In der folgenden Grafik ist ein Beispiel dargestellt, bei dem verschiedene Empfänger mit einem Sender kommunizieren sollen:

·      In diesem Beispiel erlaubt das SAP-System auf Empfängerseite noch keine Proxy-Generierung – es wird statt dessen ein IDoc und ein RFC auf der Inbound-Seite verwendet. Um später beim logischen Routing und beim Mapping auf die Namen (und die Schemabeschreibung) dieser Interfaces zugreifen zu können, importieren Sie für sie eine XML-Beschreibung in das Integration Repository.

·      Für den ABAP-Sender und den Java-Empfänger kann dagegen ein Inbound-Proxy generiert werden. Für diesen Zweck legen Sie im Integration Repository zwei Message-Interfaces an.

Ein Outbound-Message-Interface kann also an verschiedene Empfänger-Interfaces angeschlossen werden und umgekehrt. Welche Interfaces semantisch zusammengehören, können Sie mit Hilfe eines Integrationsszenarios modellieren beziehungsweise dokumentieren.

Weitere Beispiele finden Sie unter Fallbeispiele.

Interfaces und Message-Typen

Bei der Definition eines Message-Interface geben Sie einen Output- und einen Input-Message-Typ an:

·      Der Output-Message-Typ ist derjenige, der bestimmt, wie die zu versendende Message aufgebaut ist.

·      Der Input-Message-Typ ist derjenige, der bestimmt, wie die zu empfangene Message aufgebaut ist.

Sie verweisen von einem Message-Interface auf einen der folgenden Objekttypen:

·      Auf Message-Typen, die direkt im Integration Repository angelegt worden sind. Sie verweisen auf einen Datentyp, der die Struktur der Message bestimmt.

·      Auf Message-Schemas aus externen Definitionen. Externe Definitionen sind importierte WSDL-, XSD- oder DTD-Dokumente. Die Proxy-Generierung kann nur externe Definitionen verarbeiten, die bestimmte Voraussetzungen erfüllen.

·      Auf das Message-Schema eines importieren IDocs

·      Auf Message-Schemas eines importierten RFC (Requests und gegebenenfalls Response).

Beim Import von RFCs oder IDocs in das Integration Repository beziehungsweise einer externen Definition legt der Integration Builder also auch Message-Objekte im Repository an, die Sie in Message-Interfaces verwenden können. Ein Message-Interface kann nicht auf unterschiedliche Objekttypen (beispielsweise auf einen Message-Typ und eine RFC-Response) verweisen.

 

Messages von importierten Interfaces oder externen Definitionen lassen sich nicht verändern und sind daher auch nicht im Navigationsbaum des Integration Builders sichtbar.

XML-Namensräume für Message-Instanzen

Ein XML-Namensraum ist ein zusätzlicher Identifikator für die Message-Instanz. Abhängig vom Typ Ihrer Output- oder Input-Message, ist der XML-Namensraum entweder fest vorgegeben oder kann geändert werden:

·      Bei (Fault-)Message-Typen können Sie den XML-Namensraum im Integration Builder frei wählen.

·      Bei RFCs und IDocs ist der XML-Namensraum im Integration Builder vorgegeben. Er entspricht ihrem festen Repository-Namensraum.

·      Bei externen Definitionen ist der XML-Namensraum im importierten Dokument festgelegt.

Gleiche Messages sollten den gleichen XML-Namensraum haben. Ansonsten müsste eine Output-Message nur auf Grund eines unterschiedlichen XML-Namensraums mit einem Mapping auf eine Input-Message abgebildet werden.