IDoc-Verarbeitung mit dem IDoc-Adapter

Mit dem IDoc-Adapter können Sie IDocs (Intermediate Documents) über die Integration Engine verarbeiten und verschicken. Sie können hierzu alle existierenden und freigegebenen IDoc-Typen verwenden. Das ALE-Audit wird unterstützt.

Die Verarbeitung von IDocs durch die Pipeline der Integration Engine bietet Ihnen 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 SAP-Anwendungen, die noch nicht über die Funktionen der Proxy-Generierung verfügen.

Weitere Informationen: Integration Engine , ALE-Audit , Pipeline , IDoc-Schnittstelle / Electronic Data Interchange .

Der IDoc-Adapter ist Teil des Integration Server. Er besteht im Wesentlichen aus zwei Teilen, einem Adapter am Eingang des Integration Server und einem Adapter am Ausgang des Integration Server, mit gemeinsamen Metadaten zu den involvierten IDoc-Typen.

Der Adapter am Eingang ist der Pipeline des Integration Server vorgelagert und ruft diese auf. Der Adapter am Ausgang hingegen wird von der Pipeline aufgerufen, kann also als Teil der Pipeline angesehen werden.

Die angeschlossenen Systeme übergeben oder erhalten IDocs über ihre IDoc-RFC-Schnittstelle.

Ablauf der IDoc-Verarbeitung

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

Auf dem Integration Server wird 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.

IDoc-Adapter am Eingang des Integration Server

Nachdem das IDoc aus der Anwendung über die RFC-Schnittstelle in den IDoc-Adapter am Eingang des Integration Server gelangt ist, findet die Konvertierung von IDoc-Format in IDoc-XML-Format statt. Hierbei wird pro IDoc ein Message-GUID erzeugt.

IDos können als Datei zu Verfügung gestellt werden. Weitere Informationen: Dateischnittstelle

IDocs können paketweise übergeben werden. Ein Paket von IDocs wird aber nur akzeptiert, wenn sich alle darin enthaltenen IDocs nach IDoc-XML konvertieren lassen. Ist ein IDoc nicht konvertierbar, werden alle IDocs abgelehnt.

Die Konvertierung 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 (oder 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 zurücksetzen und anschließend erneut laden und geladene Metadaten mit denen im Referenzsystem vergleichen.

Weitere Informationen: Metadaten laden, anzeigen und löschen , Ports für IDoc-Metadaten verwalten , Metadaten mit Referenzsystem vergleichen

IDoc-Paktierung, Eingang in Integration Server und Partnerumschlüsselung

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.

Im Integration Directory müssen für den IDoc-Adapter jeder Kommunikationskomponente 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 die Sender-Kommunikationskomponente im Message-Header spezifizieren. Die Empfänger-Kommunikationskomponente am Eingang bleibt leer.

• Ist das Sendersystem ein SAP-System, wird die Sender-Kommunikationskomponente aus der System-ID (zum Beispiel BCE ) des Sender-Port (zum Beispiel SAPBCE ) und dem Mandanten ermittelt.
• Ist das Sendersystem kein SAP-System, wird die Sender-Kommunikationskomponente aus dem logischen Systemnamen des Sender-Port ermittelt.

Neben der Sender-Kommunikationskomponente 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.
• 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 der Sender-Kommunikationskomponente (ermittelt aus System-ID und Mandant) gebildet wird.

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

  Hinweis

  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.

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.

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

Weitere Informationen: IDoc-Empfänger-Adapter konfigurieren , Verarbeitung von Acknowledgment-Messages

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, Partnerumschlüsselung

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 der Kommunikationskomponente 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.
  • Die Kommunikationskomponente 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 (oder 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.

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 der Message-GUID und die IDoc-Nummer im Feld ARCKEY des IDoc-Kontrollsatzes übergeben.

Umschlüsselung vom Acknowledgment-Status in IDoc-Status und umgekehrt

Regeln zur Umwandlung eines IDoc-Status in einen Acknowledgment-Status

Regeln zur Umwandlung eines Acknowledgment-Status in einen IDoc-Status