Service-Interface 

Verwendung

Mit einem Service-Interface beschreiben Sie unabhängig von einer Plattform beziehungsweise einer Programmiersprache Operationen, die Sie in einer späteren Implementierung im Anwendungssystem benötigen. Abhängig von der Kategorie eines Service-Interface gibt es folgende Verwendungen:

·        Inbound (Provider-Rolle):
Sie wollen einen Service in einem Anwendungssystem implementieren, der von einem Verwender aufgerufen werden kann.

·        Outbound (Consumer-Rolle)
Sie wollen einen Service eines Providers aufrufen. Dazu benötigen Sie ein zum Inbound-Service-Interfaces passendes Outbound-Service-Interface.

·        Abstrakt
Sie wollen bei einer erweiterten Kommunikation über den Integration Server Messages mit einem zwischengelagerten Integrationsprozess austauschen (siehe auch: Prozesssignatur).

Im Anwendungssystem generieren Sie ausgehend von Service-Interfaces mit Hilfe der Proxy-Generierung Entwicklungsobjekte für die Implementierung. Die Proxy-Generierung generiert folgende Objekte automatisch:

●      Proxy-Objekte (beispielsweise Klassen, Methoden und Datentypen).

●      Eine Service-Definition für die Kommunikation über die Web-Service-Laufzeit.

Für das Interface-Pattern zustandslos (XI 3.0 kompatibel) wird nur dann eine Service-Definition angelegt, wenn es sich um eine synchrone Operation handelt.

Sie bestimmen über das Interface-Pattern im ES Repository, welches Protokoll Sie verwenden wollen.

Integration

Die folgende Abbildung zeigt ein vereinfachtes Klassenmodell für Service-Interfaces im ES Builder:

Service-Interfaces werden wie alle Designobjekte über Repository-Namensräume organisiert, die einer Software-Komponentenversion zugeordnet sind (siehe auch: Organisation der Auslieferungsinhalte).

Sie können Service-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. Optional setzen Sie Fault-Message-Typen ein, um anwendungsspezifische Fehler zu behandeln.

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.

·        Über RFC- oder IDoc-Messages, als Gegenstück zu einem RFC beziehungsweise IDoc im SAP-System (nicht in der Grafik oben abgebildet) für eine A2A- oder B2B-Integration.

·        Über externe WSDL-, XSD- und DTD-Definitionen, deren enthaltene Message-Schemas sie verwenden können.

Zusammenfassend bezeichnet man diese Objekte, sowie Business-Objekte und Kontextobjekte als Interface-Objekte.

Funktionsumfang

Der Service-Interface-Editor ist folgendermaßen aufgebaut (Registerkarte Definition):

 

Kategorie und Interface-Pattern

Das Interface-Pattern bestimmt die Art der Kommunikation:

●      Service-Interfaces der Kategorie Outbound oder Inbound werden für die Implementierung der Kommunikation im Anwendungssystem verwendet. Sie können in diesem Fall alle Interface-Pattern wählen.

●      Service-Interfaces der Kategorie Abstrakt sind für die Kommunikation mit einem Integrationsprozess auf dem Integration Server gedacht. Sie können in diesem Fall nur die Interface-Pattern zustandslos und zustandslos (XI 3.0 kompatibel) verwenden.

Weitere Informationen: Interface-Pattern

Abstrakte Service-Interfaces

Abstrakte Service-Interfaces werden für die Ausführung von systemübergreifenden Integrationsprozessen benötigt. Die Ausführung solcher Prozesse erweitert die Kommunikation über dem Integration Server in der Weise, dass ein Integrationsprozess auf dem Integration Server Messages nach einem vorgegebenen Modell zueinander in Beziehung setzen kann (man spricht auch von Orchestrierung). Die Ausführung eines Integrationsprozesses findet also statt nachdem eine Message verschickt wurde und bevor sie ein Empfänger erhalten hat. Ein Integrationsprozess empfängt und sendet Messages über abstrakte Service-Interfaces. Service-Interfaces dieser Kategorie können innerhalb von Integrationsprozessen die Rolle eines Inbound- oder Outbound-Service-Interfaces annehmen, je nachdem, ob es zum Senden oder Empfangen einer Message verwendet wird. Bei seiner Definition ist also noch keine Richtung vorgegeben. Bei Integrationsprozessen können Sie so mit ein und demselben abstrakten Interface eine Message empfangen und senden. Abstrakte Service-Interfaces empfangen die Message in der Regel von einem Outbound-Interface eines Sendersystems und senden es einem Inbound-Interface eines Empfängersystems und übernehmen dabei die komplementäre Rolle.

Weitere Informationen: Integrationsprozesse

Sie verwenden abstrakte Service-Interfaces auch für bestimmte Adapter. Da abstrakte Interfaces nicht für eine Implementierung im Anwendungssystem vorgesehen sind, können Sie keine Proxies für Service-Interfaces dieser Kategorie generieren.

Weitere Informationen: Entwicklungsansätze kombinieren

Interface-Pattern und Operationen

Jedes Service-Interface kann mehrere Operationen haben. Abhängig vom Interface-Pattern bietet der Service-Interface-Editor passende Operation-Pattern und Modi zur Auswahl an:

Interface-Pattern	Operation-Pattern	Modus der Operation
zustandslos	Normale Operation	synchron oder asynchron
zustandslos (XI 3.0 kompatibel)	Normale Operation	synchron oder asynchron
zustandsbehaftet	Normale Operation	synchron
	Commit-Operation	synchron
	Rollback-Operation	synchron
TU&C/C	Normale Operation	synchron oder asynchron
	Tentative-Update-Operation	synchron
	Confirm-Operation	asynchron
	Compensate-Operation	asynchron

Wenn Sie das Interface-Pattern eines Service-Interfaces ändern, gehen unter Umständen Informationen verloren, weil nicht jedes Operation-Pattern bei jedem Interface-Pattern angeboten wird. Zudem müssen Sie eine gegebenenfalls bereits existierende Implementierung ändern. Sie müssen sich also zu Beginn für ein Interface-Pattern entscheiden.

Die Struktur der auszutauschenden Daten wird über den Verweis auf ein Message-Schema festgelegt. Abhängig vom Modus können Sie im Service-Interface-Editor auf Message-Typen, RFC-Messages, IDoc-Messages (nur für Requests) oder externe Messages für die jeweilige Richtung des Message-Austauschs verweisen (vergleiche Übersicht im Mapping-Abschnitt).

Modus und Messages

Modus
Asynchron	Request, Fault (optional und nur für Inbound-Service-Interfaces)
Synchron	Request, Response, Fault (optional)

Wenn Sie anwendungsspezifische Fehler behandeln beziehungsweise im Monitoring persistieren wollen, weisen Sie der Operation entsprechende Fault-Message-Typen zu. Fault-Messages sind dazu vorgesehen, Fehler auf Empfängerseite dem Sender beziehungsweise dem Monitoring zu übermitteln. Für asynchrone Operationen abstrakter Service-Interfaces oder für asynchrone Operationen von Outbound-Service-Interfaces können Sie daher keine Fault-Messages definieren.

Aktivitäten

...

       1.      Legen Sie ein Service-Interface an (weitere Informationen: Anlegen eines Objektes).

Der Service-Interface-Editor legt zusammen mit dem Service-Interface eine erste Operation mit dem gleichen Namen wie das Service-Interface an. Sie können den Namen der Operation so lange ändern, bis Sie das erste Mal das Service-Interface gespeichert haben. Um danach den Namen zu ändern, müssen Sie die Operation löschen und neu anlegen.

       2.      Legen Sie die Kategorie und das Interface-Pattern des Service-Interface fest.

       3.      Je nach Interface-Pattern benötigen Sie ein oder mehrere Operationen. Legen Sie neue Operationen über die Operationsliste an. Solange Sie das Service-Interface nicht speichern, können Sie den Namen der Operation ändern.

       4.      Legen Sie pro Operation das Operation-Pattern und den Modus fest. Je nach Interface-Pattern bietet der Service-Interface-Editor unterschiedliche Operation-Pattern und Modi an (siehe oben).

       5.      Weisen Sie der jeweiligen Operation über die Eingabehilfe ein Message-Schema für die Request-Message und gegebenenfalls für die Response- und Fault-Message zu. Die zugehörigen Interface-Objekte müssen in der gleichen oder einer unterliegenden Software-Komponentenversion zum Service-Interface liegen.

       6.      Bei einer erweiterten Kommunikation können Sie den Zugriff auf die Message-Payload beim logischen Routing über Kontextobjekte vereinfachen. Sie können im Service-Interface-Editor einer Request-Message Kontextobjekte der gleichen oder einer unterliegenden Software-Komponentenversion zuordnen (weitere Informationen: Kontextobjekte).

       7.      Speichern Sie Ihre Änderungen.

Ergebnis

Sie haben ein Service-Interface angelegt und können dazu im Anwendungssystem Entwicklungsobjekte mit Hilfe der Proxy-Generierung generieren.