Interface-Objekte
Interface-Objekte bieten alle Details darüber, wie eine Prozesskomponente mit einer anderen Daten austauscht, zum Beispiel den Kommunikationsmodus und die Datenstrukturen.
Die folgende Tabelle fasst die Typen von Interface-Objekten zusammen:
Objekttyp |
Beschreibung |
Service-Interface |
Definiert eine Menge von Funktionen, die von einer Anwendung bereitgestellt oder verwendet werden; es enthält eine oder mehrere Operationen. Jede Operation bezieht sich auf einen oder mehrere Message-Typen. |
Message-Typ |
Definiert das Wurzelelement einer Message und bezieht sich auf einen Datentyp. |
Datentyp |
Definiert eine Datenstruktur. |
Externe Definition |
Extern definierte Datenstruktur, die in das ES-Repository importiert wird. |
Importiertes Objekt |
RFC- oder IDoc-Interface, das in das ES-Repository importiert wird. |
Kontextobjekt |
Design-Objekt, das als abgekürzter Ausdruck eines XPath-Ausdrucks verwendet werden kann, um ein bestimmtes Payload-Element zu adressieren. Kontextobjekte werden in Routing-Bedingungen verwendet. |
Interface-Objekte können sich auf bestimmte Art gegenseitig referenzieren. Die möglichen Objektreferenzen werden in der folgenden Grafik gezeigt:
Weitere Informationen: Interface-Objekte im ES-Repository
Service-Interfaces, Operationen und Message-Typen
Da sich Interface-Objekte auch gegenseitig kapseln (wie in der Grafik oben zu sehen ist), ist ein Top-Down-Ansatz ebenfalls möglich, beginnend mit der Definition eines Service-Interfaces.
Ein Service-Interface stellt eine Menge von Funktionen dar, die von einer Anwendung entweder angeboten (Inbound-Service-Interface) oder verwendet (Outbound-Service-Interface) werden. Sie können die Menge der Funktionen, die ein Service-Interface bietet, auch als eine Untermenge der Funktionen betrachten, die von einer Prozesskomponente implementiert werden. Ein Service-Interface im ES-Repository enthält jedoch nur die Metadaten eines Service, ohne jegliche Implementierungsdetails.
Service-Interfaces basieren auf der Web Services Description Language (WSDL), einer XML-basierten Sprache zur Beschreibung von Web-Services und deren Zugriffsmöglichkeiten. Wenn Sie jedoch Interface-Objekte im ES-Repository anlegen, müssen Sie sich nicht mit der Syntax von WSDL vertraut machen, da Sie den entsprechenden Editor zur Angabe der Interface-Attribute verwenden können.
Das Service-Interface-Attribut Kategorie bestimmt, ob es sich um ein Outbound-Service-Interface oder ein Inbound-Service-Interface handelt.
Die Kategorie Abstrakt ist nur für die Kommunikation mit einem Integrationsprozess (komponentenübergreifendes BPM) gedacht.
Ein Service-Interface gruppiert eine oder mehrere Operationen. Eine Operation stellt die kleinste getrennt aufrufbare Funktion dar, die von einer Menge von Datentypen beschrieben wird, die als Ein- oder Ausgabe verwendet werden. Sie können für jede Operation den Kommunikationsmodus angeben. Dieses Attribut bestimmt, ob die von der Operation definierte Kommunikation synchron oder asynchron stattfindet. In einem synchronen Kommunikationsschritt wird für jeden Aufruf oder jede verschickte Request-Message eine Response erwartet. In einem asynchronen Schritt wird eine Request-Message verschickt, aber keine Response erwartet.
Sie ordnen jeder Operation einen oder mehrere Message-Typen zu - je nach Kommunikationsmodus.
Ein Message-Typ definiert das Wurzelelement einer Message. Sie verwenden eine Message, um Daten zwischen Systemen auszutauschen. Ein Message-Typ bezieht sich auf genau einen Datentyp, der die Struktur dieser Daten definiert.
Einer synchronen Operation weisen Sie drei Message-Typen zu: ein Request-, ein Response- und ein Fault-Message-Typ. Ein Fault-Message-Typ ist eine Message, die im Fehlerfall erwartet wird. Einer asynchronen Operation weisen Sie nur einen Request-Message-Typ zu. Die folgende Grafik zeigt die Rolle der verschiedenen Interface-Objekte beim Message-Austausch, wie sie anhand des Prozessmodells (siehe oben) entworfen wurde. Das Beispiel zeigt einen asynchronen Message-Austausch, bei dem eine Request-Message vom Service-Consumer zum Service-Provider gesendet wird.
Die folgende Grafik zeigt einen synchronen Message-Austausch mit einer für die Service-Interface-Operation definierten Request- und Response-Message:
In vielen Szenarien erfordert es die Anwendung, dass während des Message-Austauschs eine bestimmte Kommunikationsfolge und ein bestimmtes Transaktionsverhalten eingehalten werden. Mit dem Attribut Interface-Pattern können Sie dieses Verhalten im ES-Repository entwerfen. Ein Interface-Pattern beschreibt den Typ der Kommunikation, die für die Message ausgeführt werden soll, wenn das Interface verwendet wird. Es bestimmt, welche Art von Operationen für ein Service-Interface definiert werden können. Das Interface-Pattern, das Sie auswählen, beeinflusst die Programmieraktivitäten für die Geschäftslogik im entsprechenden Backend-System (Aufgabe des Anwendungsentwicklers).
Für die vermittelte Kommunikation mit dem Integration Broker sind die Interface-Patterns meistens Stateless oder Stateless (XI 3.0-compatible).
Das Interface-Pattern Stateless (XI 3.0-compatible) wird standardmäßig für alle Interfaces verwendet, die aus früheren Releases (dort Message-Interfaces genannt) von SAP NetWeaver PI (nämlich SAP NetWeaver PI und SAP NetWeaver XI 3.0) auf SAP NetWeaver PI 7.1 migriert wurden. Dieses Interface-Pattern wird auch für Szenarien empfohlen, in denen die sogenannten "technischen Adapter", wie der File/FTP-, JDBC- oder JMS-Adapter verwendet werden. Mit diesem Pattern kann ein Service-Interface jedoch nur eine Operation verwenden.
Das Standard-Pattern zur Entwicklung neuer Service-Interfaces ist Stateless.
Das Interface-Pattern Tentative Update & Confirm/Compensate (TU &C/C) wurde entwickelt, um das Transaktionsverhalten bei synchronen Messages zu verbessern. Das Pattern TU &C/C sorgt dafür, dass - bei System- oder Kommunikationsfehlern - einer oder mehrere synchrone Aktualisierungsaufrufe in einem Transaktionskontext ausgeführt werden und eine konsistente Datenmenge auf beiden Seiten der Kommunikation gewährleisten.
Weitere Informationen: Service-Interface
Datentypen
Ein Datentyp bestimmt die Datenstruktur für eine bestimmte Geschäftsentität, zum Beispiel eine Adresse. Datentypen werden von Message-Typen referenziert und definieren deshalb die Struktur einer Message.
Wie im ES-Repository definiert, basieren Datentypen auf einem XML-Schema (auch XSD genannt). Datentypen können andere Datentypen referenzieren, weshalb Sie aus einfachen Datentypen komplexe Datentypen aufbauen können. Grundlage für alle Datentypen sind die vom W3C verabschiedeten und in einem XML-Schema enthaltenen eingebauten XSD-Typen (beispielsweise xsd:string, xsd:decimal oder xsd:integer). Diese Datentypen definieren die Eigenschaften eines Elements auf einer technischen Ebene.
Weitere Informationen: Datentypen im Enterprise Services Repository
Externe Definitionen
Wenn Sie vorhandene XML-Definitionen als in WSDL oder XSD beschriebene Message-Definitionen wiederverwenden möchten, können Sie diese XML-Definitionen in das ES-Repository importieren anstatt sie über den Datentyp-Editor manuell neu einzugeben. Sie kapseln dann die importierte Definition als externe Definition.
Kontextobjekte
Mit einem Kontextobjekt können Sie einen XPATH-Ausdruck angeben, der zum Zugriff auf ein Feld in einer XML-Message verwendet werden kann.
Diese Ausdrücke können dann zur Konfigurationszeit verwendet werden, um Content-basiertes Routing in Integrationsprozessen (ccBPM) zu konfigurieren.
Weitere Informationen:
Importierte Objekte
Wenn Sie XML-Definitionen von vorhandenen Funktionen - RFCs oder IDocs - wiederverwenden möchten, so dass Sie diese Funktionen mit dem Integration Server aufrufen können, können Sie IDocs und RFCs in das ES-Repository importieren und die Interface-Signatur dort bekannt machen.