Les IDocs existent depuis plusieurs décennies dans l'univers SAP, et les clients souhaitent très souvent les intégrer, car ils constituent la colonne vertébrale du transfert des données de base et transactionnelles entre les systèmes SAP et d'autres applications dans tout système basé sur ABAP, qu'il s'agisse de SAP ECC, BW, SRM, SCM, CRM ou du produit phare de SAP, S/4HANA.
Vue d'ensemble
Au sein des systèmes SAP, les IDocs sont traités par le framework Application Link Enabling (ALE). Les personnes familiarisées avec le système utilisent souvent les termes ALE et IDoc ensemble ou les mentionnent dans la même phrase. Pour les personnes qui ne connaissent pas SAP, il est essentiel de comprendre que l'ALE fonctionne comme un système de messagerie. En tant qu'expéditeur du message (IDoc), vous spécifiez le type de message envoyé, son destinataire et le port ALE que vous souhaitez utiliser. Du côté SAP, le framework ALE décide quand le message est traité et quelle fonctionnalité est utilisée pour cela, en fonction de la configuration.
Maintenant que nous avons acquis les notions de base sur ALE, passons brièvement en revue les différents Snaps dont nous disposons et leur utilisation avant d'entrer dans les détails de chacun d'entre eux. Commençons par le Snap SAP IDoc Write. Bien que son fonctionnement soit assez explicite, il est utilisé pour créer un IDoc dans le système SAP. Notre documentation est quelque peu trompeuse, car elle suggère que les IDocs sont toujours traités de manière asynchrone et que, par conséquent, un pipeline SnapLogic n'attendra jamais la fin du traitement dans SAP avant de poursuivre. Plus loin dans cette série, nous verrons que les deux scénarios sont possibles : le traitement asynchrone et le traitement synchrone.
Au début, IDoc Listener et IDoc Document Listener me semblaient confus. Pourquoi faudrait-il deux Snaps distincts pour écouter les IDoc envoyés à un pipeline par un système SAP ? La réponse est simple : une fois l'IDoc reçu, IDoc Listener le convertit au format XML binaire, tandis qu'IDoc Document Listener peut directement transformer l'IDoc en document SnapLogic avec une fonctionnalité supplémentaire permettant de spécifier un type de base IDoc, une version spécifique d'un message IDoc donné, qui est lu pendant la validation, puis utilisé pour transmettre la structure du message aux Snaps en aval.
Enfin, le Snap IDoc Read vous permet de lire un IDoc déjà créé. Bien que ce Snap renvoie l'IDoc complet avec toutes ses données, son utilisation la plus courante consiste à déterminer le statut de traitement de l'IDoc dans le système SAP. Nous examinerons brièvement les statuts IDoc plus loin dans cette série. Le cadre ALE et l'application traitant l'IDoc dans SAP définissent des statuts qui peuvent être utilisés pour obtenir des informations sur ce qui s'est passé du côté SAP.
Dans la prochaine partie de la série, nous examinerons les conditions préalables aux Snaps IDoc (lien vers la partie suivante).
Ce que vous devez faire avant d'utiliser Snaps avec succès
Examinons maintenant les conditions préalables à l'utilisation des Snaps SAP IDoc. Bien que ces conditions préalables ne soient pas compliquées à mettre en œuvre, elles sont indispensables si vous souhaitez utiliser les Snaps.
Conditions préalables pour l'écriture et la lecture d'IDoc
Étant donné qu'un système SAP ne dispose pas de fonctionnalité standard permettant de lire un IDoc existant depuis l'extérieur, les snaps IDoc Read et IDoc Write nécessitent la création d'un module fonction personnalisé compatible RFC dans le système SAP avant de pouvoir être utilisés. Vous pouvez effectuer cette opération à l'aide de la transaction SAP SE37.

L'interface du RFC doit être identique au module fonction `IDOC_READ_COMPLETELY` disponible dans le système SAP. Nous vous recommandons d'encapsuler le module fonction d'origine plutôt que de le copier. Vous trouverez un exemple à ce sujet dans cet article. Si vous n'êtes pas familiarisé avec la création d'un module fonction compatible RFC, nous vous recommandons de contacter l'équipe chargée de l'exploitation de SAP dans votre organisation et de lui demander de le faire pour vous. La création du module fonction est simple et ne prend que quelques minutes, surtout si vous pouvez leur fournir l'exemple joint.
Conditions préalables pour les snaps IDoc Listener et IDoc Document Listener
Noms des services
Les modules Listening Snaps nécessitent que vous ajoutiez des entrées au fichier /etc/services sous Linux ou au fichier %windir%System32driversetcservices sous Windows sur chaque nœud des Groundplexes que vous comptez utiliser avec les modules IDoc Snaps. Le fichier mappe les ports TCP/IP aux noms de service pour de nombreux services standard et contient, par défaut, des entrées pour la plupart des ports standard de nombreux services standard tels que la messagerie électronique, SSH et autres. Vous devrez ajouter les noms de service pour le système SAP en fonction du ou des numéros de système de votre ou vos systèmes SAP. Le numéro de système SAP se compose de deux chiffres et est généralement utilisé pour mapper les différents ports sur lesquels SAP écoute. Si le numéro de système est 00, le port SAP Gateway est 3300. S'il est 01, le port sera 3301, et ainsi de suite. Si vous avez l'intention d'utiliser Secure Network Communication (SNC), vous devez également créer une entrée pour le port SNC, qui est 48xx. La règle de nommage est sapgwXX pour le port standard et sapgwXXs pour le port SNC.
sapgw00 3300/tcp # Standard port of SAP Gateway for System No 00
sapgw00s 4800/tcp # SNC port of SAP Gateway for System No 00
Vous pouvez également contacter l'équipe chargée de l'exploitation des systèmes SAP dans votre entreprise et lui demander ces entrées. Elle est en mesure de vous les fournir, car elles sont configurées dans tous les systèmes exécutant SAP ainsi que dans tous les ordinateurs de bureau Windows sur lesquels SAP Gui est installé.
Listes de contrôle d'accès SAP RFC Gateway
Pour que vos IDoc Listen Snaps s'enregistrent correctement sur la passerelle SAP RFC, celle-ci doit autoriser l'accès aux nœuds du Groundplex que vous souhaitez utiliser. Pour ce faire, vous devez vous assurer que la passerelle SAP RFC contient des entrées dans les fichiers reginfo et secinfo de la passerelle. Ces fichiers peuvent être configurés via la transaction SAP Gui SMGW. Les différentes options sont expliquées dans une excellente série d'articles sur le blog SAP SCN consacrés à la sécurité de la passerelle SAP RFC. Nous vous recommandons de vérifier auprès de l'équipe qui gère vos systèmes SAP quels sont les paramètres ACL en place ou de leur demander d'inclure les adresses IP des nœuds du ou des Groundplex que vous souhaitez utiliser.
Création d'IDocs dans SAP à l'aide du module IDoc Write Snap
Dans un système SAP classique, de nombreux IDoc standard sont disponibles par défaut. Certaines entreprises utilisent les IDoc par défaut, tels que ORDERS05 pour les commandes client ou MATMAS05 pour la fiche article, tandis que d'autres étendent ceux fournis par SAP ou créent leurs propres IDoc. Ces IDoc sont généralement volumineux et contiennent de nombreux champs regroupés en segments, ce qui peut facilement devenir déroutant. Afin de nous concentrer sur les aspects liés à l'intégration dans cette série d'articles, nous avons créé un IDoc personnalisé simple, comportant seulement dix champs regroupés en un seul segment, afin d'en discuter les fonctionnalités. L'IDoc que nous avons créé se présente comme suit :
<?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>
Dans l'IDoc, le segment EDI_CD40 représente la structure de contrôle qui contient les différentes informations nécessaires au système SAP pour comprendre quelles données contient l'IDoc et à quelle application il est destiné, tandis que ZPERSONDATA01 est le segment contenant les champs qui contiennent les données de l'IDoc.
Lorsque vous créez un IDoc dans SAP, vous n'avez pas besoin d'envoyer l'intégralité du segment EDI_CD40 avec tous les champs ; vous n'avez besoin que des champs nécessaires à la couche ALE pour comprendre où l'IDoc doit être envoyé. Dans l'exemple ci-dessous, nous avons limité la structure afin qu'elle ne contienne que les champs requis par la configuration que nous avons effectuée dans SAP. L'équipe SAP de votre organisation est chargée de configurer ALE et peut vous fournir des détails sur les informations à saisir dans les champs de l'IDoc que vous souhaitez envoyer.
Le pipeline que nous avons construit se compose de 3 Snaps, un générateur JSON Snap qui contient les données d'exemple ci-dessous :
{
"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
}
]
}
Un Snap Mapper qui mappe le segment de contrôle ainsi que le segment de données. Bien que les noms des champs du segment de données soient identiques entre la sortie du générateur JSON et les noms de champs IDOC, nous avons délibérément utilisé les noms internes SAP pour l'enregistrement de contrôle du générateur JSON ; le Snap IDoc Write affichera ces champs avec les noms des méthodes setter dans la bibliothèque de classes Java SAP IDoc sous-jacente. Nous avons joint à ce blog un tableau de mappage qui vous aidera à mapper les noms des méthodes de définition Java aux noms internes SAP, mais vous pouvez également trouver le mappage dans les JavaDocs de la bibliothèque SAP IDoc.

Le pipeline terminé se présente comme suit :

La sortie du SAP IDoc Write Snap vous fournira un ensemble complet d'informations qui vous permettront de comprendre ce qui s'est passé dans le système SAP. Le plus important est le DOCUMENT_NUMBER, mais aussi le STATUS que l'IDoc a dans SAP après l'exécution réussie du Snap.

Une fois l'exécution réussie, vous pouvez voir le traitement de l'IDoc dans la transaction WE02 ou WE09 dans SAP.

Nous avons joint l'exemple de pipeline. Dans la prochaine partie du blog, nous examinerons les différents paramètres que vous pouvez définir dans IDoc Write Snap pour manipuler le comportement du Snap et nous nous intéresserons à l'exécution synchrone et asynchrone.





