Integration von SAP mithilfe der SAP-IDoc-Snaps (Teil 1/4)

Porträtfoto von Ingo Sauerzapf
10 min gelesen
Fassen Sie dies mit AI zusammen

IDocs gibt es in der SAP-Welt schon seit mehreren Jahrzehnten, und Kunden möchten sie sehr häufig integrieren, da sie das Rückgrat für die Übertragung von Stamm- und Transaktionsdaten zwischen SAP-Systemen und anderen Anwendungen in jedem ABAP-basierten System bilden, sei es SAP ECC, BW, SRM, SCM, CRM oder das Flaggschiffprodukt von SAP, S/4HANA.

Übersicht

In SAP-Systemen werden IDocs vom Application Link Enabling (ALE)-Framework verarbeitet. Personen, die mit dem System vertraut sind, verwenden die Begriffe ALE und IDoc oft zusammen oder erwähnen sie im selben Satz. Für Personen, die mit SAP nicht vertraut sind, ist es wichtig zu verstehen, dass ALE wie ein Nachrichtensystem funktioniert. Als Absender der Nachricht (IDoc) legen Sie fest, welche Art von Nachricht gesendet wird, wer sie erhalten soll und welchen ALE-Port Sie verwenden möchten. Auf der SAP-Seite entscheidet das ALE-Framework anhand der Konfiguration, wann die Nachricht verarbeitet wird und welche Funktionen dafür verwendet werden.

Mit diesem grundlegenden Verständnis von ALE wollen wir kurz die einzelnen Snaps und ihre Verwendung durchgehen, bevor wir uns mit den Details jedes einzelnen befassen. Beginnen wir mit dem SAP IDoc Write Snap. Seine Funktion ist zwar ziemlich selbsterklärend, aber er wird verwendet, um ein IDoc im SAP-System zu erstellen. Unsere Dokumentation ist etwas irreführend, da sie suggeriert, dass IDocs immer asynchron verarbeitet werden und eine SnapLogic-Pipeline daher niemals auf den Abschluss der Verarbeitung in SAP wartet, bevor sie fortfährt. Später in dieser Reihe werden wir sehen, dass beide Szenarien möglich sind: asynchrone und synchrone Verarbeitung.

Zunächst erschienen mir IDoc Listener und IDoc Document Listener verwirrend. Warum sollte man zwei separate Snaps benötigen, um IDocs zu überwachen, die von einem SAP-System an eine Pipeline gesendet werden? Die Antwort ist einfach: Sobald das IDoc empfangen wurde, gibt der IDoc Listener das IDoc als XML in einem Binärformat aus, während der IDoc Document Listener das IDoc direkt in ein SnapLogic-Dokument umwandeln kann, mit der zusätzlichen Funktion, einen IDoc-Basistyp anzugeben, also eine bestimmte Version einer bestimmten IDoc-Nachricht, die während der Validierung gelesen und dann verwendet wird, um die Struktur der Nachricht an nachgelagerte Snaps weiterzugeben.

Schließlich können Sie mit dem IDoc Read Snap ein bereits erstelltes IDoc lesen. Dieser Snap gibt zwar das vollständige IDoc mit allen Daten zurück, wird jedoch in der Regel dazu verwendet, den Verarbeitungsstatus des IDocs im SAP-System zu ermitteln. Wir werden uns später in dieser Reihe kurz mit den IDoc-Status befassen. Das ALE-Framework und die Anwendung, die das IDoc in SAP verarbeitet, legen Status fest, anhand derer Sie Einblicke in die Vorgänge auf der SAP-Seite gewinnen können.
Im nächsten Teil der Serie werden wir uns mit den Voraussetzungen für die IDoc-Snaps befassen (Link zum nächsten Teil).

Was Sie tun müssen, bevor Sie Snaps erfolgreich verwenden können

Sehen wir uns nun die Voraussetzungen für die Verwendung der SAP IDoc Snaps an. Die Voraussetzungen sind zwar nicht kompliziert zu implementieren, aber unerlässlich, wenn Sie die Snaps verwenden möchten.

Voraussetzungen für IDoc-Schreiben, IDoc-Lesen Snaps

Da ein SAP-System nicht über Standardfunktionen zum Lesen eines vorhandenen IDocs von außen verfügt, müssen Sie für die IDoc-Lese- und IDoc-Schreib-Snaps einen benutzerdefinierten RFC-fähigen Funktionsbaustein im SAP-System erstellen, bevor diese verwendet werden können. Dies können Sie mit der SAP-Transaktion SE37 tun.

Screenshot vom 07.05.2024 um 17:38:38 Uhr.png

Die Schnittstelle des RFC muss mit dem im SAP-System verfügbaren Funktionsbaustein „IDOC_READ_COMPLETELY” identisch sein. Wir empfehlen, den ursprünglichen Funktionsbaustein zu verpacken, anstatt ihn zu kopieren. Ein Beispiel hierfür finden Sie im Anhang zu diesem Blogbeitrag. Wenn Sie mit der Erstellung eines RFC-fähigen Funktionsbausteins nicht vertraut sind, wenden Sie sich bitte an das Team, das SAP in Ihrem Unternehmen betreibt, und bitten Sie es, dies für Sie zu übernehmen. Die Erstellung des Funktionsbausteins ist einfach und dauert nur wenige Minuten, insbesondere wenn Sie dem Team das beigefügte Beispiel zur Verfügung stellen können. 

Voraussetzungen für IDoc-Listener und IDoc-Dokument-Listener-Snaps

Dienstnamen

Für die Listening Snaps müssen Sie Einträge zur Datei „/etc/services“ unter Linux oder zur Datei „%windir%System32driversetcservices“ unter Windows auf jedem Knoten der Groundplexes hinzufügen, die Sie mit den IDoc Snaps verwenden möchten. Die Datei ordnet TCP/IP-Ports den Servicenamen für viele Standarddienste zu und enthält standardmäßig Einträge für viele der Standardports für viele Standarddienste wie E-Mail, SSH und andere. Sie müssen Dienstnamen für das SAP-System hinzufügen, abhängig von der/den Systemnummer(n) Ihres/Ihrer SAP-Systeme(s). Die SAP-Systemnummer besteht aus zwei Ziffern und wird im Allgemeinen zur Zuordnung zu den verschiedenen Ports verwendet, die SAP überwacht. Wenn die Systemnummer 00 lautet, ist der SAP-Gateway-Port 3300. Wenn sie 01 lautet, ist der Port 3301 usw. Wenn Sie Secure Network Communication (SNC) verwenden möchten, müssen Sie auch einen Eintrag für den SNC-Port 48xx vornehmen. Die Namensregel lautet sapgwXX für den Standardport und sapgwXXs für den SNC-Port.

sapgw00   3300/tcp     # Standard port of SAP Gateway for System No 00
sapgw00s  4800/tcp     # SNC port of SAP Gateway for System No 00 

Alternativ können Sie sich auch an das Team wenden, das die SAP-Systeme in Ihrem Unternehmen betreibt, und dort nach den Einträgen fragen. Diese können Ihnen dort zur Verfügung gestellt werden, da sie in jedem System, auf dem SAP läuft, sowie auf jedem Windows-basierten Desktop, auf dem SAP Gui installiert ist, konfiguriert sind.

SAP RFC Gateway Zugriffskontrolllisten

Damit Ihre IDoc Listen Snaps erfolgreich beim SAP RFC Gateway registriert werden können, muss das Gateway den Zugriff für die Knoten des Groundplex, den Sie verwenden möchten, zulassen. Dazu müssen Sie sicherstellen, dass das SAP RFC Gateway Einträge in den Reginfo- und Secinfo-Dateien des Gateways hat. Die Dateien können über die SAP-GUI-Transaktion SMGW konfiguriert werden. Die verschiedenen Optionen werden in einer großartigen mehrteiligen Blogserie auf SAP SCN erläutert, die sich mit der Sicherheit des SAP RFC-Gateways befasst. Wir empfehlen Ihnen, sich bei dem Team, das Ihre SAP-Systeme betreibt, zu erkundigen, welche ACL-Einstellungen vorhanden sind, oder es zu bitten, die IP-Adressen der Knoten des/der Groundplex(es), den/die Sie verwenden möchten, aufzunehmen.

Erstellen von IDocs in SAP mit dem IDoc-Schreib-Snap

In einem typischen SAP-System sind standardmäßig viele Standard-IDocs verfügbar. Einige Unternehmen verwenden die Standard-IDocs wie ORDERS05 für Kundenaufträge oder MATMAS05 für den Materialstamm, andere hingegen erweitern die von SAP bereitgestellten IDocs oder erstellen eigene. Diese IDocs sind in der Regel groß und enthalten viele Felder, die in Segmente gruppiert sind, sodass man leicht den Überblick verlieren kann. Um uns auf die Integrationsaspekte der Blog-Reihe zu konzentrieren, haben wir ein einfaches benutzerdefiniertes IDoc mit nur zehn Feldern erstellt, die in einem Segment gruppiert sind, um die Funktionalität zu diskutieren. Das von uns erstellte IDoc sieht wie folgt aus:

<?xml version='1.0' encoding='UTF-8'?>
<ZPERSON01>
    <IDOC BEGIN="1">
        <EDI_DC40 SEGMENT="1">
            <TABNAM>EDI_DC40</TABNAM>
            <MANDT>100</MANDT>
            <DOCNUM>0000000000058011</DOCNUM>
            <DOCREL>758</DOCREL>
            <STATUS>30</STATUS>
            <DIRECT>1</DIRECT>
            <OUTMOD>2</OUTMOD>
            <IDOCTYP>ZPERSON01</IDOCTYP>
            <MESTYP>ZPERSONDATA</MESTYP>
            <SNDPOR>SAPS4H</SNDPOR>
            <SNDPRT>LS</SNDPRT>
            <SNDPRN>S4HCLNT100</SNDPRN>
            <RCVPOR>A000000003</RCVPOR>
            <RCVPRT>LS</RCVPRT>
            <RCVPRN>SNPCLNT000</RCVPRN>
            <CREDAT>20240508</CREDAT>
            <CRETIM>225707</CRETIM>
            <SERIAL>20240508225707</SERIAL>
        </EDI_DC40>
        <ZPERSONDATA01 SEGMENT="1">
            <FIRSTNAME>Herbert</FIRSTNAME>
            <LASTNAME>Walker</LASTNAME>
            <TITLE>Mr.</TITLE>
            <GENDER>male</GENDER>
            <STREET>1234 Somestreet</STREET>
            <CITY>Boston</CITY>
            <ZIP>72662</ZIP>
            <COUNTRY>United States</COUNTRY>
            <EMAIL>[email protected]</EMAIL>
            <PHONE>555555525</PHONE>
        </ZPERSONDATA01>
    </IDOC>
</ZPERSON01>

Im IDoc stellt das Segment EDI_CD40 die Kontrollstruktur dar, die die verschiedenen Informationen enthält, die das SAP-System benötigt, um zu verstehen, welche Daten das IDoc enthält und für welche Anwendung es bestimmt ist, während ZPERSONDATA01 das Segment mit den Feldern ist, die die Daten des IDocs enthalten.

Wenn Sie ein IDoc in SAP erstellen, müssen Sie nicht das gesamte Segment EDI_CD40 mit allen Feldern senden, sondern nur die Felder, die für die ALE-Schicht erforderlich sind, um zu verstehen, wohin das IDoc gehen soll. Im folgenden Beispiel haben wir die Struktur so eingeschränkt, dass sie nur die Felder enthält, die für die von uns in SAP vorgenommene Konfiguration erforderlich sind. Das SAP-Team in Ihrem Unternehmen ist für die Konfiguration von ALE verantwortlich und kann Ihnen genau sagen, was in die Felder für das IDoc eingegeben werden muss, das Sie senden möchten.

Die von uns erstellte Pipeline besteht aus drei Snaps, darunter ein JSON-Generator-Snap, der die folgenden Beispieldaten enthält:

{
  "EDI_DC40": {
    "MESTYP" : "ZPERSONDATA",
    "SNDPRT" : "LS",
    "SNDPRN" : "SNPCLNT000",
    "SNDPOR" : "A000000003",
    "RCVPRT" : "LS",
    "RCVPRN" : "A4HCLNT001"
  },
  "ZPERSONDATA01": [
    {
      "FIRSTNAME": "Ingo",
      "LASTNAME": "Sauerzapf",
      "TITLE": "Mr.",
      "GENDER": "female",
      "STREET": "33rd Str.",
      "CITY": "New York",
      "ZIP": "98632",
      "COUNTRY": "United States",
      "EMAIL": "[email protected]",
      "PHONE": "5405883833",
      "SLEEPTIME": 40
    }
  ]
}

Ein Mapper-Snap, der sowohl das Kontrollsegment als auch das Datensegment abbildet. Während die Namen der Felder im Datensegment zwischen der Ausgabe des JSON-Generators und den IDOC-Feldnamen identisch sind, haben wir bewusst die SAP-internen Namen für den Kontrollsatz des JSON-Generators verwendet; der IDoc-Write-Snap zeigt diese Felder mit den Namen, die die Setter-Methoden in der zugrunde liegenden SAP-IDoc-Java-Klassenbibliothek haben. Wir haben diesem Blog eine Zuordnungstabelle beigefügt, die Ihnen dabei hilft, die Setternamen der Java-Methoden den SAP-internen Namen zuzuordnen. Sie finden die Zuordnung jedoch auch in den JavaDocs der SAP-IDoc-Bibliothek.

451fc136-b9fb-46a5-8ca6-df33b313b2f6.png

Die fertige Pipeline sieht wie folgt aus:

Die Ausgabe des SAP IDoc Write Snap liefert Ihnen eine Vielzahl von Informationen, anhand derer Sie nachvollziehen können, was im SAP-System geschehen ist. Am wichtigsten ist dabei die DOCUMENT_NUMBER, aber auch der STATUS, den das IDoc in SAP hat, nachdem der Snap erfolgreich ausgeführt wurde.

Nach erfolgreicher Ausführung können Sie die Verarbeitung des IDocs in der Transaktion WE02 oder WE09 im SAP-System verfolgen.

Wir haben die Beispiel-Pipeline angehängt. Im nächsten Teil des Blogs werden wir uns die verschiedenen Einstellungen ansehen, die Sie im IDoc Write Snap vornehmen können, um das Verhalten des Snaps zu beeinflussen, und wir werden uns die synchrone und asynchrone Ausführung ansehen.

Porträtfoto von Ingo Sauerzapf
Senior Professional Services Architect bei SnapLogic
Kategorie: Technik