Ein IDoc ist das Standardformat für den Datenaustausch zwischen SAP-ERP-Systemen (kurz SAP-System). In einem häufig genutzten Szenario werden IDocs über das SAP PI/PO verschickt, um dort in ein Format umgesetzt zu werden, welches von einem nicht-SAP-Produkt verarbeitet wird.
Doch wie funktioniert die Kommunikation zwischen dem SAP-System und der SAP PI/PO? Das folgende Szenario beschreibt beispielhaft das Versenden eines IDoc aus dem SAP-System an die SAP PI/PO. Die Betrachtungen beziehen sich hauptsächlich auf den Sendervorgang im SAP-System und sind daher auch auf ein Szenario mit der SAP Cloud Platform Integration (CPI) anwendbar.
Grundlegendes
IDocs zwischen SAP-Systemen (oder der SAP PI/PO) werden über einen Remote Function Call (RFC) ausgetauscht, bei dem ein Funktionsbaustein im Zielsystem aufgerufen wird. Die einfachste Möglichkeit eines RFC-Aufrufs ist der synchrone RFC-Aufruf (sRFC). Dabei geschieht der Aufruf im Zielsystem sofort und der Aufrufer wartet auf die Verarbeitung. Der Vorteil ist, dass auf die Antwort der Gegenseite direkt reagiert werden kann. Der Nachteil ist, dass es zu Fehlern kommt, wenn die Gegenseite nicht er riechbar ist (z.B. durch hohe Auslastungen).
Für größere Datenmengen (wie dem Stammdatenaustausch) eigene sich der sRFC-Aufruf daher nicht. IDocs werden daher über einen transaktionalen RFC (tRFC) verschickt. Hierbei werden die ausgehenden Nachrichten zunächst in eine Warteschlange (Queue) gestellt und dann verarbeitet. Ist das Zielsystem einmal nicht erreichbar, können fehlgeschlagenen Nachrichten noch einmal verarbeitet werden.
Für einen solchen tRFC-Aufruf beim IDoc-Versand zwischen SAP-System und SAP PI/PO sind prinzipiell zwei Voraussetzungen zu erfüllen. Zum einen muss die grundlegende Netzwerkverbindung aufgebaut werden. Dies geschieht in der Transaktion SM59. Dort wird eine Verbindung vom Typ T („TCP/IP-Verbindung“) erstellt. Die SAP PI/PO muss sich dabei als registriertes Serverprogramm anmelden (Details dazu folgen in einem weiteren Blog-Beitrag). Die zweite Voraussetzung ist ein logischer Port (Transaktion WE21). Dort muss ein Port vom Typ „Transaktionaler RFC“ angelegt werden, entsprechend muss hier die eben erstellte RFC-Verbindung hinterlegt sein.
Sind diese beiden Voraussetzungen erfüllt, kann der Port in den Partnervereinbarungen (WE20) verwendet werden. In den Partnervereinbarungen müssen dann pro Empfänger (hier in diesem Szenario die SAP PI/PO) und Nachrichtenart die entsprechenden Versand-Einstellungen vorgenommen werden.
Es sei noch erwähnt, dass mithilfe von Verteilungsmodellen (Transaktion BD64) die Verbindungen zentral verwaltet werden können. Zusätzlich ist es möglich, die Einstellungen z.B. für Partnervereinbarungen generieren zu lassen.
Der Unterschied von tRFC und qRFC
Für die Verarbeitung von IDoc gibt es prinzipiell zwei Möglichkeiten. Die bereits vorgestellt Variante per tRFC zeichnet sich dadurch aus, dass die Abarbeitung der Queue nicht davon abhängt, in welcher Reihenfolge die IDoc erstellt werden. Das heißt, dass die Daten in einer beliebigen Reihenfolge im Zielsystem ankommen können. Gibt es Fehler bei der Verarbeitung einer Nachricht, hat das keine Auswirkung auf folgende Nachrichten.
Ist es nötig, dass die Reichenfolge der Verarbeitung eingehalten wird (z.B. Anlage von Stammdaten, anschließend Update von Datensätzen), kann die Verarbeitung auch auf queued RFC (qRFC) umgestellt werden. Auch in diesem Fall gibt eine Verarbeitungs-Queue, die allerdings immer in der Reihenfolge der Nachrichtenerstellung abgearbeitet wird. Kommt es zu einem Fehler bei der Verarbeitung, werden nachfolgende Nachrichten nicht abgearbeitet, sondern bleiben in der Warteschlange stehen.
Wie stellt man das Verfahren von tRFC auf qRFC um? Zunächst muss im Port (Transaktion WE21) das Kennzeichen „Queueverarbeitung wird unterstützt“ gesetzt werden. Ist das Empfangssystem eine SAP PI/PO oder ein anderes SAP-System, ist diese Unterstützung gegeben.
Anschließend kann die qRFC-Verarbeitung in der Partnervereinbarung pro Nachrichtentyp aktiviert werden.
Story vom verlorenem IDoc
Um die Analyse im Fehlerfall besser zu verdeutlichen, soll folgendes Szenario dienen. Ein SAP ERP-System verteilt Kostenstellen (IDoc COSMAS) an ein Fremdsystem. Dazu werden die IDoc an die SAP PI/PO geschickt, damit die Nachrichten dort für das nicht-SAP-Zielsystem gewandelt werden. Die IDocs werden per Standard-Report RBDSECOS erstellt und sind im IDoc-Monitor (WE02) auch im Status 03 („Datenübergabe an Port OK“) zu sehen. In der SAP PI/PO tauchen die Nachrichten allerdings nicht auf (Message Monitor), auch der Sender-Kanal weist keine Fehler auf (Channel Monitor). Die IDocs scheinen verschwunden zu sein.
Wenn der Message Monitor keine Nachrichten anzeigt (auch keine fehlerhaften), sollte die Suche im Sendersystem (SAP ERP) beginnen. Der Status 03 („Datenübergabe an Port OK“) ist tatsächlich nicht der End-Status, indem sich ein IDoc befinden kann. Dieser Status zeigt nur an, dass die Nachricht an die Queue (entweder tRFC oder qRFC) übergeben wurde, nicht, dass diese wirklich versandt wurde. Mit der Transaktion BD75 kann der Queue-Status überprüft werden und der eigentliche End-Status 12 („Versand OK“) gesetzt werden. Setzt man das Kennzeichen „Nicht versandte IDocs anzeigen“, erhält man zusätzlich eine Ausgabelist mit IDocs, die noch in der Queue hängen geblieben sind.
Gibt es IDocs, die noch in der Warteschlange stehen, kann man die eigentlichen Queues betrachten, um dort weiter Hinweise auf den Fehler zu finden. Für die tRFC-Queue gibt es Transaktion SM58, für die qRFC-Queue SMQ1.
Hier in diesem Beispiel sieht man eine fehlgeschlagene Nachricht im qRFC-Monitor (SMQ1). Obwohl nur eine Nachricht einen Fehler hat, bleiben auch alle folgenden Nachrichten hängen.
Jetzt kommt es auf den individuellen Fehler an, wie die Lösung aussieht. Handelt es sich zum Beispiel um eine Fehlerkonfiguration in der SAP PI/PO, muss der Fehler dort behoben werden. Ist der Fehler behoben und das IDoc neu erstellt, muss die Verarbeitung der Queue fortgesetzt werden. Dazu platziert man den Cursor in der entsprechenden Fehlerzeile und lösche die Zeile aus der Queue (Mülleimer-Icon). Erst jetzt können die anderen Nachrichten nachverarbeitet werden, entweder einzeln über das „Ausführen“-Icon oder auf dem vorherigen Bildschirm über die Funktion „Queue aktivieren“.