IDoc-Verarbeitung mit dem IDoc-Adapter 

Einsatzmöglichkeiten

Der IDoc-Adapter ermöglicht das Verarbeiten und Verschicken von IDocs (Intermediate Documents) über die Integration Engine. Alle existierenden und freigegebenen IDoc-Typen können hierzu verwendet werden; das ALE-Audit wird unterstützt.

Die Möglichkeit der Verarbeitung von IDocs durch die Pipeline der Integration Engine bietet eine Alternative zur Verarbeitung von XML-Messages, die über die Proxy-Schnittstelle generiert werden. Diese Alternative kommt typischerweise für alle SAP-Anwendungen und Fremdsysteme (Subsysteme) in Betracht, die bereits IDocs definiert haben, sowie für neue SAP-Anwendungen, die noch nicht über die Funktionalität der Proxy-Generierung verfügen.

Weitere Informationen zu IDocs finden Sie unter IDoc-Schnittstelle / Electronic Data Interchange.

Voraussetzungen

Integration Server

Wenn das System, auf dem sich der IDoc-Adapter befindet als Integration Server konfiguriert ist, werden eingehende IDocs mit dem IDoc-Adapter und nicht über die normale IDoc-Schnittstelle verarbeitet.

Auf einem Integration Server müssen Sie deshalb IDocs, die grundsätzlich mit der IDoc-Schnittstelle verarbeitet werden sollen, mit dem Report IDX_SELECT_IDOCTYP_WITHOUT_IS in die Ausnahmetabelle IDXIDOCINB eintragen. In diese Tabelle können Sie nur IDoc-Typen aufnehmen, die bereits im System definiert sind. Diese IDoc-Typen werden dann nicht mit der Integration Engine verarbeitet.

Zum Laden von IDoc-Metadaten, müssen Sie über die Portpflege im IDoc-Adapter eine RFC-Verbindung zu dem angeschlossenen System aufnehmen. Dieses System ist durch den Absenderport und den Mandanten im IDoc-Kontrollsatz definiert.

Anwendungskomponenten

Bestehende Anwendungen müssen nicht geändert werden.

Im Sendersystem müssen Sie lediglich für den Integration Server die Zieladresse der RFC-Destination eines tRFC-Ports ändern. Ist kein tRFC-Port vorhanden, müssen Sie einen neuen tRFC-Port für den Integration Server anlegen.

Um einen vorhandenen tRFC-Port zu ändern, verfahren Sie wie folgt:

...

       1.      Führen Sie die Transaktion Anzeige und Pflege von RFC-Destinationen (SM59) aus.

       2.      Wählen Sie per Doppelklick die entsprechende RFC-Destination aus.

       3.      Geben Sie als Zielmaschine die Server-Adresse des Integration Server ein.

Näheres hierzu finden Sie unter Destinationen anzeigen, pflegen und testen.

Um einen neuen tRFC-Port anzulegen, verfahren Sie wie folgt:

...

       1.      Legen Sie mit der Transaktion Anzeige und Pflege von RFC-Destinationen (SM59) eine RFC-Destination vom Verbindungstyp 3 an und geben Sie als Zielmaschine die Server-Adresse des Integration Server an.

Näheres hierzu finden Sie unter Destinationen anzeigen, pflegen und testen.

       2.      Definieren Sie mit der Transaktion Ports in der IDoc-Verarbeitung (WE21) mit dieser Destination einen neuen Port vom Typ Transaktionaler RFC (tRFC).

Näheres zum Einrichten von Ports finden Sie unter Ports einrichten.

       3.      Ändern Sie mit der TransaktionPartnervereinbarungen (WE20) die Partnervereinbarungen, indem Sie das Empfängersystem als Partnernummer eintragen und bei den Ausgangsparametern den zu sendenden Nachrichtentyp und Basistyp auswählen sowie den neuen Port als Empfängerport eintragen.

Näheres hierzu finden Sie unter Ausgangspartnervereinbarung anlegen.

Im Empfängersystem müssen Sie ebenfalls die Partnervereinbarungen ändern.

...

       1.      Führen Sie hierzu die Transaktion Partnervereinbarungen (WE20) aus und legen Sie für den Senderpartner eine Eingangspartnervereinbarung an.

       2.      Geben Sie zudem bei den Eingangsparametern den eingehenden Nachrichtentyp und Basistyp an.

Ablauf

Die angeschlossenen Systeme erzeugen in den Anwendungen die entsprechenden IDocs und versenden sie an den neuen tRFC-Port, dessen RFC-Destination den Integration Server adressiert.

Auf dem Integration Server wird dann der IDoc-Adapter aufgerufen, der aus dem nativen IDoc-Format ein IDoc-XML erzeugt, das an die Pipeline der Integration Engine zum Routing, Mapping und Versenden übergeben wird.

Soll das empfangene IDoc ohne Änderungen an den Datensätzen wieder als IDoc versendet werden, können Sie die Konvertierung nach IDoc-XML über einen entsprechenden Konfigurationsparameter ausschalten.

IDoc-Paketierung, IDoc-Adapter am Eingang des Integration Server

Folgende Funktionsbausteine stehen am Eingang des Integration Server zur Verfügung:

●      IDOC_INBOUND_ASYNCHRONOUS

Dieser Baustein verwendet Segmentnamen als Inputparameter.

●      IDOC_INBOUND_IN_QUEUE

Dieser Baustein verwendet Segmenttypen. Sie können außerdem den Queue-Namen für Quality-of-Service Exactly Once in Order mitgeben.

Ist im IDoc-Sender-Adapter die IDoc-Paketierung aktiviert, werden IDocs-Pakete, die über tRFC verschickt werden, in eine Message eingestellt. Über die Paketgröße legen Sie fest, dass die Pakete nicht zu groß werden.

Ist die IDoc-Paketierung nicht aktiviert, wird für jedes IDoc-XML eine Message bestehend aus Header und Body mit Payload (IDoc-XML) an den Integration Server gesendet. Der Header enthält unter anderem die Sender-Kommunikationskomponente.

Die Konvertierung von IDoc nach IDoc-XML geschieht durch ein implizites 1:1-Mapping von Segmenten und Feldern zu XML-Tags. Die dazu notwendigen Metadaten (IDoc-Strukturen für die entsprechenden IDoc-Typen) befinden sich jedoch nicht im Integration Server, sondern in dem angeschlossenen SAP-System (bzw. in dem SAP-Referenzsystem, in dem die Metadaten abgelegt sind, wenn es sich bei dem sendenden System um ein Subsystem handelt).

Diese Metadaten können entweder direkt zur Laufzeit abgerufen oder vorab auf den Integration Server geladen werden. Um dies zu ermöglichen, müssen Sie zuvor eine RFC-Verbindung (einen Port) zu dem angeschlossenen System angelegt haben.

Über die Metadaten-Anzeige im IDoc-Adapter können Sie bereits geladene Metadaten und bereits angeschlossene Systeme anzeigen. Sie können Metadaten auch zurücksetzen und anschließend erneut laden.

Eingang in Integration Server

Für jedes IDoc-XML wird eine Message bestehend aus Header und Body mit Payload (IDoc-XML) an den Integration Server gesendet. Der Header enthält unter anderem den Sender-Service.

Im Integration Directory müssen für den IDoc-Adapter jedem Service adapterspezifische Identifikatoren zugeordnet werden. Die spezifischen Identifikatoren für den IDoc-Adapter sind Werte aus dem IDoc-Kontrollsatz. Aufgrund dieser Angaben kann der IDoc-Adapter den Sender-Service im Message-Header spezifizieren. Der Empfänger-Service am Eingang bleibt leer.

●      Ist das Sendersystem ein SAP-System, wird der Sender-Service aus der System-ID (zum Beispiel BCE) des Sender-Port (zum Beispiel SAPBCE) und dem Mandanten ermittelt.

●      Ist das Sendersystem kein SAP-System, wird der Sender-Service aus dem logischen Systemnamen des Sender-Port ermittelt.

Neben dem Sender-Service enthält der Message-Header auch noch die Sender- und Empfängerpartner (bestehend aus Partnername, Identifikationsschema, und vergebender Agentur).

●      Ist ein IDoc-Partner als logisches System definiert (Partnertyp LS), bleibt der Partner im Message-Header leer. Der Service wird unter Service ohne Partner definiert.

●      Ist ein IDoc-Partner nicht als logisches System definiert, wird im Message-Header ein alternativer Partner erzeugt, der aus den folgenden alternativen Identifikatoren besteht:

○       Dem Kommunikationspartner (Partnername), der aus der Partnernummer des IDocs gebildet wird.

○       Dem Identifikationsschema, das aus der Partnerart und optional der Partnerrolle des IDocs gebildet wird (also aus ALE#<partner_art> oder optional aus ALE#<partner_art>#<partner_rolle>).

○       Der vergebenden Agentur, die aus dem Sender-Service (ermittelt aus System-ID und Mandant) gebildet wird.

Optional kann der alternative Senderpartner normalisiert, das heißt durch den internen XI-Partner ersetzt werden.

Aus Kompatibilitätsgründen kann auf die Normalisierung des alternativen Partners verzichtet werden.

Zusätzlich werden die Sender/Empfänger-IDoc-Partner als Kontext-Objekte dem logischen Routing zur Verfügung gestellt. Nähere Informationen hierzu finden Sie bei der Beschreibung des Bedingungseditors zum logischen Routing.

Logisches Routing

Das logische Routing ermittelt den logischen Empfänger. Der Empfänger kann abhängig vom Sender-Business-System in der IDoc-XML-Message entweder über Kontext-Objekte aus dem IDoc-Kontrollsatz oder über eine XPath-Regel auf das IDoc-XML ermittelt werden. Die XPath-Regel muss für eine erfolgreiche Empfängerermittlung den Status true haben.

Werden die Kontext-Objekte nicht verwendet und ist keine XPath-Regel definiert, wird das dem Business-System des Senders zugeordnete Business-System des Empfängers gewählt.

Technisches Routing

Das technische Routing ordnet dem logischen Empfänger ein physisches Ziel zu. Der IDoc-Adapter benötigt für jeden logischen Empfänger eine RFC-Destination aus dem technischen Routing. Diese ist als Parameter (RFC-Destination) im IDoc-Empfänger-Adapter spezifiziert.

Sie müssen einen Kommunikationskanal vom Adaptertyp IDoc auch für Sendersysteme anlegen, die Acknowledgment-Messages von einem IDoc-Adapter erwarten.

Im IDoc-Empfänger-Adapter legen Sie außerdem die Version der technischen IDoc-Schnittstelle fest.

Mapping

An das Mapping stellt der IDoc-Adapter keine speziellen Anforderungen. Am Ausgang des Integration Server muss dem IDoc-Adapter lediglich eine IDoc-XML-Struktur zur Verfügung gestellt werden. Diese ist entweder bereits vorhanden oder muss durch ein Mapping erzeugt werden. Enthält die IDoc-XML-Struktur einen Kontrollsatz, wird dieser verworfen und vom IDoc-Adapter neu erstellt.

Ausgang aus Integration Server

Vor dem Ausgang aus dem Integration Server befinden sich Werte im Header der Message, die ausgelesen und später zum Füllen des IDoc-Kontrollsatzes verwendet werden.

Der IDoc-Adapter wird aufgerufen und das IDoc-XML, die Parameter aus dem Kommunikationskanal sowie die Kontrollsatzdaten werden übergeben.

IDoc-Adapter am Ausgang des Integration Server

Die Aufgabe des IDoc-Adapters am Ausgang des Integration Server ist das Konvertieren von IDoc-XML in natives IDoc-Format und die Übergabe der IDocs an das Empfängersystem (also ein SAP-System oder ein Subsystem) über die Standard-tRFC-IDoc-Schnittstelle. Der Kontrollsatz des IDoc wird hierzu vom IDoc-Adapter gefüllt.

Zusätzlich ermittelt der IDoc-Adapter aus dem Sender und Empfänger im Message-Header die entsprechenden IDoc-Partner.

●      Ist der Partner im Message-Header leer, wird ein IDoc-Partner vom Typ LS (logisches System) ermittelt mit dem Service als logischem Systemnamen.

●      Ist der Partner im Message-Header gefüllt, wird der IDoc-Partner mit Hilfe des alternativen Partners ermittelt.

Wurde normalisiert, müssen hierzu über einen Kommunikationskanal die folgenden Identifikatoren zugeordnet werden:

○       Die Partnerart und optional die Partnerrolle des IDocs (also ALE#<partner_art> oder optional ALE#<partner_art>#<partner_rolle>) als Identifikationsschema.

○       Der Service als vergebende Agentur.

Der IDoc-Adapter benötigt für die Umwandlung von IDoc-XML in IDoc-Format die Metadaten für den jeweiligen IDoc-Typ. Sind diese nicht verfügbar, müssen sie aus dem Empfängersystem geladen werden (bzw. aus dem entsprechenden SAP-Referenzsystem, wenn es sich bei dem Empfängersystem um ein Subsystem handelt). Mit Hilfe der Metadaten findet dann die Konvertierung nach IDoc statt.

Wurde das zu versendende IDoc bereits als IDoc empfangen und wurde der entsprechende Konfigurationsparameter zum Abschalten der IDoc-XML-Konvertierung gesetzt, entfällt an dieser Stelle die Rückkonvertierung von IDoc-XML in IDoc-Format.

Danach wird über die RFC-Destination ein Funktionsbaustein (Parameter Interface-Version und Queue-Verarbeitung im IDoc-Empfänger-Adapter) des RFC-IDoc-Eingangs gerufen und die Daten im entsprechenden Format übergeben.

Das IDoc wird schließlich an die empfangende Anwendung versendet. Der Integration Server überprüft im nachhinein, ob die Message auch tatsächlich versendet wurde.

Um eine nachträgliche Selektionen von IDocs im Zielsystem zu ermöglichen, werden die Message-GUID und die IDoc-Nummer im Feld ARCKEY des IDoc-Kontrollsatzes übergeben.