Im zweiten Teil der Blogserie zur Integration von SAP mithilfe der SAP IDoc Snaps werden wir uns das Verhalten der IDoc Write Snaps und die verschiedenen Einstellungsmöglichkeiten ansehen und einen Blick auf die Konfiguration innerhalb von SAP werfen, damit die SnapLogic-Pipeline entweder synchron oder asynchron verarbeitet wird, falls Sie die Verarbeitung Ihrer Pipeline fortsetzen möchten, ohne auf den Abschluss der IDoc-Verarbeitung im SAP-System zu warten.
Die Einstellungen im IDoc-Schreib-Snap verstehen
Die wichtigste Einstellung, die Sie vornehmen müssen, ist das Hinzufügen des Namens des Funktionsbausteins in das Feld „IDoc Read BAPI Name“, das zum Lesen des Status des IDocs verwendet wird, sobald es im SAP-System erstellt wurde. Wir haben den Funktionsbaustein im im ersten Teil unserer Blogserie besprochen und am Ende des ersten Blogs ein Implementierungsbeispiel angehängt. Sobald ein IDoc erstellt wurde, versucht der Snap, das IDoc genau einmal über den Funktionsbaustein zu lesen, um den aktuellen Status des IDocs im SAP-System zu ermitteln. Anhand dieses Status wird dann entschieden, ob die SnapLogic-Pipeline die Verarbeitung des Dokuments fortsetzen oder das Dokument an die Fehleransicht weiterleiten soll. Damit der Snap dies tun kann, muss das Kontrollkästchen „Fehler weiterleiten“ aktiviert sein.
IDoc-Status im SAP-System sind in zwei Teile unterteilt: Ausgehende IDocs von 01 bis 42 und eingehende IDoc-Verarbeitung von 50 bis 75. Eine vollständige Liste der IDoc-Statuscodes finden Sie im SAP-System unter der Transaktion WE47. Eine detaillierte Beschreibung aller IDoc-Statuscodes würde den Rahmen dieses Blogs sprengen, aber die Standardverarbeitung eingehender IDocs durchläuft in der Regel die folgenden Statusübergänge:
- 50 IDoc hinzugefügt
- 64 IDoc bereit zur Weitergabe
- 62 IDoc an Anwendung übergeben
- 53 Bewerbungsunterlagen eingereicht.
Durch Hinzufügen der oben genannten Statuscodes zu den Feldern „Erfolgscodes“ weisen Sie Snap an, Dokumente an die Ausgabeview weiterzuleiten, wenn die erstellten IDocs zum Zeitpunkt des Statuslesens einen dieser Status haben. Alle anderen Dokumente, die IDocs mit anderen Status erstellt haben, werden an die Fehleransicht weitergeleitet. Da der Funktionsbaustein den Status nur einmal liest und nur den aktuellen Status zum Zeitpunkt des Lesens berücksichtigt, ist es wichtig, alle Status zu dem Feld hinzuzufügen, das für die weitere Verarbeitung Ihres Dokuments verwendet werden soll.
Die Abfrageintervall und Zeitlimit für die Abfrage steuern die Zeit, die Snap warten soll, um den Status des IDocs zu ermitteln. Wenn das Polling-Intervall auf 0 gesetzt ist, verwendet Snap den Funktionsbaustein nicht und versucht überhaupt nicht, den Status des IDocs zu lesen. Jede Einstellung über 0 wird als Wartezeit in Sekunden zwischen den Aufrufen des SAP-Systems zum Lesen eines Status verwendet. Das Polling-Timeout bestimmt die Gesamtwartezeit, bevor eine Java-Ausnahme ausgelöst wird. Die Einstellungen können verwendet werden, wenn Sie IDocs in sehr ausgelasteten SAP-Systemen erstellen, für die Sie den Status des IDocs ermitteln müssen, um Ihre Weiterleitung festzulegen.
Verständnis des Verarbeitungsverhaltens von IDocs in SAP
Zum Zeitpunkt der Erstellung dieses Artikels unterstützen die SnapLogic SAP-IDocs nur tRFC (Transactional Remote Function Call) und qRFC (Queued Remote Function Call) wird nicht unterstützt. Darüber hinaus verwenden unsere IDoc-Snaps die SAP-JCO-Bibliothek und die dazugehörige IDoc-Java-Bibliothek , um IDocs zu erstellen. Daher konzentrieren wir uns nur auf das Verhalten der IDoc-Java-Bibliothek beim Aufruf von JCoIDoc.send(..) Methoden aufgerufen werden. Beachten Sie, dass Systeme, die diese Bibliotheken nicht verwenden, möglicherweise ein anderes Verhalten sowie andere Optionen aufweisen.
Synchrones Verhalten der IDoc-Verarbeitung
Als wir begannen, die verschiedenen Verhaltensweisen zu untersuchen, fanden wir im Internet häufig Aussagen, dass IDocs immer asynchron sind. Dennoch beobachteten wir ein anderes Verhalten bei der Verwendung des IDoc-Write-Snaps, der offenbar darauf wartete, dass die Verarbeitung in SAP „abgeschlossen“ war, bevor er fortfuhr. Schließlich stellten wir eine Frage im SAP Software Developer Network. Wir erhielten bald eine Antwort, die uns auf den SAP-Hinweis 180057 verwies, in der erklärt wird, dass SAP das Verhalten des Funktionsbausteins IDOC_INBOUND_ASYNCHRONOUS geändert hat und die Erstellung des IDocs in der ALE-Schicht nicht mehr von der Übertragung an die Anwendung entkoppelt. IDOC_INBOUND_ASYNCHRONOUS ist der Funktionsbaustein, der in der IDoc-Java-Bibliothek von der Methode JCoIDoc.send(..) verwendet wird. Dies bedeutet, dass Sie Ihr aus SnapLogic stammendes IDoc so konfiguriert haben, dass es sofort in der Transaktion WE20 verarbeitet wird, wie in der folgenden Abbildung gezeigt.
Die Erstellung des IDocs in der ALE-Schicht von SAP erfolgt im gleichen Prozess wie die Verarbeitung des IDocs durch die Anwendung, und die SAP IDoc Java Library wartet, bis die Anwendung die Verarbeitung des IDocs abgeschlossen hat. Während die Bibliothek wartet, kann der IDoc Write Snap den IDoc-Status nicht abrufen, obwohl das IDoc bereits die Statuscodes 50, 64 und 62 passiert hat. Dieses Verhalten bindet die SnapLogic-Pipeline effektiv an die gesamte Verarbeitung des IDocs durch die Anwendung innerhalb von SAP, und die Pipeline wird erst fortgesetzt, wenn die IDoc-Verarbeitung abgeschlossen ist.
Optionen für die asynchrone Verarbeitung von IDocs
Wenn Sie daran interessiert sind, Ihre SnapLogic-Pipeline von der Verarbeitung des IDocs in SAP-Hinweis 180057 bietet mehrere Optionen. Leider steht uns die erste Lösung mit dem Funktionsbaustein INBOUND_IDOC_PROCESS nicht zur Verfügung, da die SAP IDoc Java Library keine Möglichkeit bietet, diesen Funktionsbaustein zu verwenden. Auch die zweite Option, die Übertragung kleinerer IDoc-Pakete, funktioniert nicht, da auch hier noch auf den Abschluss der Verarbeitung durch die Anwendung gewartet werden müsste. Damit bleiben uns zwei Optionen: Die erste wäre, die Verarbeitung Ihres IDocs in Transaktion WE20 von Trigger Immediately auf Auslösen in Hintergrund Programm.
Diese Konfiguration entkoppelt die Erstellung des IDocs in der ALE-Schicht von SAP von der Verarbeitung des IDocs durch die Anwendung und ermöglicht die Fortsetzung des SAP-IDoc-Schreibvorgangs, sobald das IDoc in der ALE-Schicht erstellt wurde. Dies bedeutet auch, dass der Status Ihres IDocs beim Lesen durch den SAP IDoc Write Snap niemals über 64 liegen wird.
Die zweite Möglichkeit besteht darin, einen ABAP-PI-Port für das eingehende IDoc in Transaktion WE21 zu verwenden und dann den ABAP-PI-Port anstelle eines Transaktions-RFC-Ports in der Kontrollstruktur Ihres IDocs anzugeben.
Der folgende Screenshot zeigt die Portkonfiguration in Transaktion WE21. Beim Anlegen des Ports können Sie einen beliebigen Funktionsbaustein auswählen. In diesem Fall haben wir RFC_PING verwendet. Beachten Sie, dass der von Ihnen angegebene Funktionsbaustein nicht während der Eingangsverarbeitung verwendet wird, sondern zum Speichern der Konfiguration erforderlich ist.
Sobald der Port angegeben ist, verwenden Sie den neuen Portnamen ASYNC0001, im Feld SNDPOR der Kontrollstruktur Ihres IDOC. Zur Veranschaulichung verwenden wir das unten stehende JSON in einem JSON-Generator-Snap in der Beispiel-Pipeline, die wir dem ersten Teil der Blog-Reihe beigefügt haben, ersetzen jedoch das Feld SNDPOR durch den Portnamen des ABAP-PI-Ports.
{
"EDI_DC40": {
"MESTYP" : "ZPERSONDATA",
"SNDPRT" : "LS",
"SNDPRN" : "SNPCLNT000",
"SNDPOR" : "ASYNC00001",
"RCVPRT" : "LS",
"RCVPRN" : "A4HCLNT001"
},
"ZPERSONDATA01": [
{
"FIRSTNAME": "Ingo",
"LASTNAME": "Sauerzapf",
"TITLE": "Mr.",
"GENDER": "male",
"STREET": "33rd Str.",
"CITY": "New York",
"ZIP": "98632",
"COUNTRY": "United States",
"EMAIL": "[email protected]",
"PHONE": "5405883833",
"SLEEPTIME": 40
}
]
}Bei der Übermittlung über einen ABAP-PI-Port startet das SAP-System die Anwendung zur direkten Verarbeitung, wartet jedoch nicht auf das Ende der Verarbeitung. Ihr IDoc Write Snap kann den Status sofort weiterlesen.
Testen des Verhaltens beim Wechsel zwischen synchroner und asynchroner Verarbeitung
Um das Verhalten zu testen, haben wir im SAP-System ein IDoc erstellt und eine kleine Anwendung entwickelt, die die Daten des eingehenden IDocs übernimmt und in eine Tabelle in der SAP-Systemdatenbank schreibt. Um eine langwierige IDoc-Verarbeitung zu simulieren, haben wir eine Sleep-Anweisung von 60 Sekunden hinzugefügt. Wenn wir ein IDoc erstellen, indem wir es an den tRFC-Port senden, können wir sehen, dass die Ausführung der Pipeline etwas mehr als eine Minute dauert.
Wenn wir dasselbe IDoc stattdessen über den ABAP-PI-Port senden, wird die Pipeline-Verarbeitung in Millisekunden abgeschlossen.
Im dritten Teil unserer Blogseriebeschäftigen wir uns mit den Snap-Modulen „IDoc Listen” und „IDoc Document Listen”. Außerdem sehen wir uns an, wie wir den Status eines IDocs im SAP-System ändern können, das wir über die Listen-Snap-Module empfangen haben, um seinen Status nach der Verarbeitung durch den SnapLogic-Prozess genau widerzuspiegeln.
