Show TOC

HintergrundService-Interface Dieses Dokument in der Navigationsstruktur finden

 

Mit einem Service-Interface beschreiben Sie unabhängig von einer Plattform oder 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 Benutzer aufgerufen werden kann.

  • Outbound (Consumer-Rolle): Sie wollen einen Service eines Providers aufrufen. Dazu benötigen Sie das zum Inbound-Service-Interface passende Outbound-Service-Interface.

  • Abstrakt : Sie wollen in einer erweiterten Kommunikation über den Integration Server Messages mit einem gepufferten Integrationsprozess austauschen (weitere Informationen: 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.

    Hinweis Hinweis

    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.

    Ende des Hinweises.

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:

Die Abbildung wird im Begleittext erläutert.

Service-Interfaces werden wie alle Designobjekte über Repository-Namensräume organisiert, die einer Software-Komponentenversion zugeordnet sind (weitere Informationen: Organisation des ESR-Content).

Sie können Service-Interfaces auf folgende Weise aufbauen:

  • Über Message-Typen und Datentypen. Dieser zweistufige Aufbau verwendet WSDL (Web Service Description Language) und ist auf einen hohen Wiederverwendungsgrad ausgerichtet. Kunden können mit Datentyp-Erweiterungen zusätzliche Felder zu einer Message hinzufügen. Sie können Fault-Message-Typen verwenden, um anwendungsspezifische Fehler zu behandeln.

    Hinweis Hinweis

    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 einem XML-Schema definieren an sich noch keine solche Instanz, weil ein Datentyp noch kein Element definiert.

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

  • Über externe WSDL-, XSD- und DTD-Definitionen sowie den darin enthaltenen Message-Schemas.

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

Funktionsumfang

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

Die Abbildung wird im Begleittext erläutert.

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-Patterns 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-Patterns zustandslos und zustandslos (XI 3.0 kompatibel) verwenden.

Weitere Informationen: Interface-Patterns

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 den Integration Server folgendermaßen: Ein Integrationsprozess auf dem Integration Server kann Messages nach einem vorgegebenen Modell zueinander in Beziehung setzen (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 dem gleichen abstrakten Interface eine Message empfangen und senden. Abstrakte Service-Interfaces empfangen die Message in der Regel von einem Outbound-Interface eines Sendersystems und senden sie an ein 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: Unterschiedliche Entwicklungsansätze kombinieren

Interface-Patterns und Operationen

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

Interface-Pattern

Operation-Pattern

Modus der Operation

Sicherheitsprofil

zustandslos

normale Operation

synchron oder asynchron

No

Low

Medium

High

zustandslos (XI 3.0 kompatibel)

normale Operation

synchron oder asynchron

Basic

Strong

zustandsbehaftet

normale Operation

synchron

No

Low

Medium

High

Commit-Operation

synchron

Rollback-Operation

synchron

TU&C/C

normale Operation

synchron oder asynchron

No

Low

Medium

High

Tentative-Update-Operation

synchron

Confirm-Operation

asynchron

Compensate-Operation

asynchron

Achtung Achtung

Wenn Sie das Interface-Pattern eines Service-Interface ä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.

Ende der Warnung.

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

Messages

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 übermitteln Fehler auf Empfängerseite dem Sender oder dem Monitoring. Für asynchrone Operationen abstrakter Service-Interfaces oder für asynchrone Operationen von Outbound-Service-Interfaces können Sie daher keine Fault-Messages definieren.

Sicherheitsprofil

Sie können den Service-Interfaces im ES Repository bestimmte Sicherheitsstufen zuordnen. Diese Werte bilden die Metadaten-Beschreibung, die das Verhalten bei der Implementierung dieser Service-Definition beeinflussen. Diese Funktion ist nur für die Point-to-Point-Kommunikation relevant. Sie können Sicherheitsprofilen verschiedene Mengen an Werten zuweisen. Je nach Typ von Interface-Pattern, können Sie für das Sicherheitsprofil aus verschiedenen Mengen von Werten auswählen.

  • Wenn Sie das Interface-Pattern Zustandslos (XI 3.0 kompatibel) wählen, können Sie aus den folgenden Werten auswählen:

    • Basic - Basic Authentication mit Benutzer-ID und Kennwort, aber ohne Transportsicherheit.

    • Strong - Strong Authentication (SSL oder SSO) und Transportsicherheit.

    Hinweis Hinweis

    Das Feld zur Auswahl des Sicherheitsprofils ist nur verfügbar wenn Sie das Ankreuzfeld Point-to-Point enabled auswählen.

    Ende des Hinweises.
  • Wenn Sie das Interface-Pattern Zustandsbehaftet, Zustandslos oder TU&C/C auswählen, können Sie aus den folgenden Werten auswählen:

    • No - Keine Authentifizierung und keine Transportsicherheit.

    • Low - Basic Authentication mit Benutzer-ID und Kennwort, und ohne Transportsicherheit.

    • Medium - Basic Authentication mit Benutzer-ID und Kennwort sowie Transportsicherheit.

    • High - Strong Authentication (SSL oder SSO) und Transportsicherheit.

Hinweis Hinweis

Wenn das Service-Interface von einem ES Repository einer älteren Version als 7.11 in ein ES Repository der Version 7.11 oder höher transportiert wird, erhält das Sicherheitsprofil eine bestimmte Voreinstellung. Für das Interface-Pattern XI30-kompatibel ist diese Voreinstellung Basic und für alle anderen Interface-Patterns ist sie Low.

Wenn ein Service-Interface von einem ES Repository der Version 7.11 oder höher in ein ES Repository einer älteren Version als 7.11 transportiert wird, geht der Wert für das Sicherheitsprofil verloren. Nach einem Upgrade entspricht der Wert der Voreinstellung.

Ende des Hinweises.
Idempotenz

Idempotenz beschreibt die Eigenschaft von Operationen, die nach mehrfacher Ausführung der Operation immer zum gleichen Ergebnis führt.

Tritt bei der Kommunikation zwischen Consumer und Provider ein Fehler auf, versucht der Consumer die gleiche Message erneut zu senden. Ist der Service auf Provider-Seite mit Idempotenz implementiert, kann der Provider mit der Message korrekt umgehen. Wenn der Provider zum Beispiel bereits eine Response geschickt hat und der Fehler erst nach dem Veschicken der Response auftrat, verarbeitet der Provider den Request nicht noch einmal, sondern verschickt einfach nochmal die gespeicherte Message.

Das Feld Idempotent ist für Inbound-Service-Interfaces mit synchronem Verarbeitungsmodus verfügbar. Das Feld ist für alle Interface-Patterns verfügbar außer TU&C/C.

Hinweis Hinweis

Wenn Service-Interfaces von einem ES Repository der Version 7.11 oder höher in ein ES Repository einer älteren Version transportiert werden, geht der Wert der Idempotenz verloren.

Bei einem Upgrade von einem ES Repository einer älteren Version als 7.11 auf ein ES Repository der Version 7.11 oder höher gibt es für die Idempotenz keine Voreinstellung. Um einen Wert für die Idempotenz zu setzen, wählen Sie das Ankreuzfeld Idempotent.

Ende des Hinweises.

Weitere Informationen

Service-Interface anlegen