Service-Interface 
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
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.
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 (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
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.
Ü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.
Der Service-Interface-Editor ist folgendermaßen aufgebaut (Registerkarte Definition):

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 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
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
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.
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.
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
Das Feld zur Auswahl des Sicherheitsprofils ist nur verfügbar wenn Sie das Ankreuzfeld Point-to-Point enabled auswählen.
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
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.
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
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.