La troisième partie de la série consacrée à l'intégration SAP à l'aide des snaps SAP IDoc abordera les snaps IDoc Listener et IDoc Document Listener, et évoquera brièvement le snap SAP IDoc Read. Nous reviendrons sur les prérequis déjà abordés dans la première partie de la série, vous montrerons où configurer la connexion dans SAP Gateway, la testerons et vous donnerons un aperçu des différentes transactions SAP qui vous permettent d'envoyer des IDocs. Enfin, nous utiliserons à nouveau le Snap IDoc Write pour renvoyer un IDoc de statut utilisé par le système SAP afin de modifier le statut d'un IDoc que nous avons initialement reçu via les Snaps IDoc Listener. L'IDoc de statut nous permettra de nous intégrer aux systèmes de surveillance des IDoc dans le système SAP et de signaler les succès ou les échecs à SAP.
Réexamen des conditions préalables à l'utilisation des snaps IDoc Listener
Nous avons déjà abordé les prérequis dans la première partie de cette série, mais nous tenons à les rappeler rapidement ici. Les deux éléments suivants sont essentiels au bon fonctionnement du snap IDoc Listener et du snap IDoc Document Listener : ajouter les noms de service au fichier /etc/services sur chaque nœud de votre Groundplex et vous assurer que les listes de contrôle d'accès sur la passerelle SAP autorisent GroundPlex à se connecter à la passerelle SAP. Veuillez consulterla section Conditions préalables pour les snaps IDoc Listener et IDoc Document Listenerde la première partie de cette série.
Comprendre les snaps IDoc Listener et Document Listener
L'un des deux Snaps SAP IDoc Listener écoute les IDocs entrants en s'enregistrant auprès de la passerelle SAP. Cela signifie que les pipelines créés avec les Snaps ne s'arrêtent pas, mais continuent de fonctionner jusqu'à ce qu'un utilisateur les arrête. Pour vous enregistrer auprès de la passerelle, vous devez spécifier le hôte de la passerelle, service de passerelle (qui correspond au port sur lequel la passerelle fonctionne) et un ID de programme qui identifie de manière unique le Snap sur la passerelle SAP. Si votre système SAP se trouve derrière un routeur SAP, vous devez également spécifier la chaîne du routeur SAP. L'équipe qui exploite vos systèmes SAP peut vous fournir le nom de l'hôte, le nom du service de passerelle et la chaîne du routeur SAP, et définir un nom unique pour le Snap à utiliser comme ID de programme.
Bien que chaque système SAP dispose d'une passerelle intégrée, vous pouvez également configurer une passerelle autonome à proximité de vos nœuds Groundplex. Les passerelles autonomes SAP sont généralement utilisées dans les configurations à haute disponibilité où un système SAP se connecte à une application tierce telle que notre Snaps.
Du côté SAP, vous devez utiliser la transaction SM59 pour créer une destination RFC qui sera utilisée par la couche SAP ALE pour envoyer des données au Snap dans votre pipeline. La destination RFC doit être de type T – Connexion TCP/IP et utiliser un programme serveur enregistré avec le même ID de programme que celui que vous avez spécifié dans les paramètres du Snap.
Lorsque vous exécutez le pipeline et accédez au tableau de bord, vous pouvez voir qu'il est en cours d'exécution. Vous pouvez utiliser le statut pour ouvrir les statistiques d'exécution du pipeline et le nombre de documents pour vérifier que les IDocs sont bien envoyés du système SAP vers le pipeline.
Une fois le pipeline opérationnel, vous pouvez utiliser le bouton Test de connexion dans la transaction SM59 pour tester la connexion et voir votre connexion enregistrée dans la transaction SMGW. L'ID du programme peut être consulté à l'aide de l'entrée de menu Aller à -> Clients connectés dans SMGW.
Astuce pour récupérer la structure IDoc à partir du Snap IDoc Listener
Étant donné que le Snap IDoc Listener peut recevoir n'importe quel IDoc provenant du système SAP et le transférer au format binaire, la création de pipelines en aval dépendra de votre compréhension de la structure des IDoc(s). Une astuce que nous utilisons souvent pour comprendre la structure des IDoc consiste à attacher un Snap HTTP Client avec une entrée binaire directement à la sortie du Snap SAP IDoc Listener et à transférer le contenu vers un service API fictif qui affiche la requête reçue.
Ce faisant, vous obtiendrez le document XML ci-dessous pour l'IDoc de démonstration que nous utilisons tout au long de la série d'articles. Vous pouvez ensuite utiliser ces informations pour créer votre pipeline.
<?xml version="1.1"?>
<ZPERSON01>
<IDOC BEGIN="1">
<EDI_DC40 SEGMENT="1">
<TABNAM>EDI_DC40</TABNAM>
<MANDT>001</MANDT>
<DOCNUM>0000000000007004</DOCNUM>
<DOCREL>754</DOCREL>
<STATUS>30</STATUS>
<DIRECT>1</DIRECT>
<OUTMOD>2</OUTMOD>
<IDOCTYP>ZPERSON01</IDOCTYP>
<MESTYP>ZPERSONDATA</MESTYP>
<SNDPOR>SAPA4H</SNDPOR>
<SNDPRT>LS</SNDPRT>
<SNDPRN>A4HCLNT001</SNDPRN>
<RCVPOR>A000000002</RCVPOR>
<RCVPRT>LS</RCVPRT>
<RCVPRN>SNPCLNT000</RCVPRN>
<CREDAT>20240528</CREDAT>
<CRETIM>231206</CRETIM>
<SERIAL>20240528231206</SERIAL>
</EDI_DC40>
<ZPERSONDATA01 SEGMENT="1">
<FIRSTNAME>Elmo</FIRSTNAME>
<LASTNAME>Monster</LASTNAME>
<TITLE>Monster</TITLE>
<GENDER>male</GENDER>
<STREET>123 Sesame Street</STREET>
<CITY>New York City</CITY>
<ZIP>10023</ZIP>
<COUNTRY>United States</COUNTRY>
<EMAIL>[email protected]</EMAIL>
<PHONE>+12125953456</PHONE>
</ZPERSONDATA01>
</IDOC>
</ZPERSON01>Le Snap SAP IDoc Document Listener
Outre le Snap IDoc Listener, le Snap IDoc Document Listener vous permet de spécifier le type de base IDoc dans l'onglet Paramètres du Snap. Cela permettra au Snap de récupérer la structure IDoc lors de la validation à partir du système SAP et vous permettra de l'utiliser dans un Snap en aval, tel qu'un Snap Mapper. Si vous avez l'intention de ne recevoir qu'un seul type d'IDoc de base dans le pipeline, cela est très utile, car les IDocs SAP standard sont généralement très volumineux et contiennent de nombreux segments. La possibilité d'obtenir la structure transmise simplifie considérablement la configuration du pipeline. Le Snap IDoc Document Listener n'accepte et ne traite toutefois pas très bien les différents types d'IDoc de base par rapport au Snap IDoc Listener.
Le pipeline sap-idoc-document-listener-to-http ci-joint utilise le module IDoc Document Listener Snap et mappe simplement la sortie vers un module HTTP Client Snap configuré pour envoyer l'IDoc vers un point de terminaison HTTP.
Après avoir validé le pipeline, vous pouvez voir la structure en aval de l'IDOC apparaître dans le Mapper Snap et l'utiliser pour effectuer le mappage dont vous avez besoin.
Le point de terminaison HTTP utilisé dans ce Snap recevrait un document JSON dans le corps de la requête HTTP POST qui ressemblerait à la structure JSON ci-dessous.
{
"IDOC":{
"@BEGIN":"1",
"EDI_DC40":{
"@SEGMENT":"1",
"TABNAM":"EDI_DC40",
"MANDT":"001",
"DOCNUM":"0000000000007020",
"DOCREL":"754",
"STATUS":"30",
"DIRECT":"1",
"OUTMOD":"2",
"IDOCTYP":"ZPERSON01",
"MESTYP":"ZPERSONDATA",
"SNDPOR":"SAPA4H",
"SNDPRT":"LS",
"SNDPRN":"A4HCLNT001",
"RCVPOR":"A000000002",
"RCVPRT":"LS",
"RCVPRN":"SNPCLNT000",
"CREDAT":"20240529",
"CRETIM":"002032",
"SERIAL":"20240529002032"
},
"ZPERSONDATA01":{
"@SEGMENT":"1",
"FIRSTNAME":"Elmo",
"LASTNAME":"Monster",
"TITLE":"Monster",
"GENDER":"male",
"STREET":"123 Sesame Street",
"CITY":"New York City",
"ZIP":"10023",
"COUNTRY":"United States",
"EMAIL":"[email protected]",
"PHONE":"+12125953456"
}
}
}Activation des fichiers de trace
Tous les snaps SAP qui utilisent la bibliothèque SAP JCo vous permettent d'activer la trace SAP JCo en cochant la case Enable Trace (Activer la trace) dans la configuration. Ceci est illustré dans la capture d'écran de la configuration du snap IDoc Listener ci-dessus. Une fois activé, SAP JCo écrira un fichier de trace pour la communication entre le système SAP et GroundPlex dans /opt/snaplogic sur le nœud qui exécute la connexion. Les fichiers commencent par JCO et se terminent par .trc. Vous pouvez configurer le niveau dans la connexion à l'aide du paramètre de configuration jco.trace_level avec une valeur comprise entre 0 et 10.
Que puis-je faire avec l'IDoc Read Snap ?
AvecIDoc Read Snap, vous pouvez lire un IDoc existant dans les pipelines Snaplogic. Cela peut être utile si vous créez des pipelines qui génèrent des IDocs configurés dans SAP qui ne doivent pas être traités immédiatement, mais via une tâche planifiée s'exécutant en arrière-plan ultérieurement. Dans ce cas, si l'IDoc est créé avec succès, il recevra le code d'état64 – IDoc prêt à être transmis à l'application directement après la création de l'IDoc. Vous pouvez ensuite créer un deuxième pipeline qui s'exécutera périodiquement pour vérifier si l'état a changé dans SAP et si le traitement des données s'est poursuivi. Vous pouvez également utiliser l'IDoc Read Snap pour récupérer tous les statuts qu'un IDoc a passés et les horodatages correspondant aux moments où les modifications ont eu lieu. Ils sont contenus dans le champSTATUSdes objets du tableauINT_EDIDS, comme indiqué ci-dessous. L'objetIDOC_CONTROLcomprend également un champSTATUSavec le statut actuel au moment de l'écriture, identique au dernier objet du tableauINT_EDIDS.
Optimisation du module fonction qui lit l'IDOC dans SAP
En optimisant le module fonction standard IDOC_READ_COMPLETELY, que nous avons utilisé comme base pour notre version personnalisée compatible RFC dans la première partie de ce blog, vous pouvez améliorer considérablement les performances. Pour ce faire, il suffit de modifier le module fonction afin qu'il ne renvoie que l'enregistrement de contrôle et exclue les enregistrements de données et/ou d'état. Vous pouvez ainsi créer trois modules fonction distincts qui peuvent être utilisés de manière interchangeable dans les snaps IDoc Read et IDoc Write, en fonction des informations spécifiques dont vous avez besoin dans le système SAP. Les trois modules fonction peuvent utiliser le même code ABAP, mais ne diffèrent que par leur nom et leurs sélections de table (voir l'exemple ci-dessous).
* read data records - if requested
IF INT_EDIDD IS REQUESTED.
...
ENDIF.
* read status_records - if requested
IF INT_EDIDS IS REQUESTED.
...
ENDIFPour ce faire, supprimez l'une ou les deux tables indiquées dans la capture d'écran ci-dessous de votre module fonction et de l'interface appelant le module fonction IDOC_READ_COMPLETELY dans votre module. Par exemple, vous pouvez créer ces trois modules fonction.
- ZIDOC_READ_COMPLETELY (inclut tout, tout comme IDOC_READ_COMPLETELY)
- ZIDOC_READ_COMPLETELY_C (n'inclut aucune table, seule la structure de contrôle est renvoyée)
- ZIDOC_READ_COMPLETELY_CS (inclut la structure de contrôle et la tableINT_EDIDS )
Renvoi des informations d'état à SAP pour un IDoc existant
Dans la dernière partie du blog, nous bouclerons la boucle avec le traitement des IDocs en examinant la modification du statut d'un IDoc créé dans SAP à partir d'un pipeline SnapLogic. Une fois qu'un IDoc a été transféré avec succès vers un pipeline SnapLogic, le système SAP modifie le statut de l'IDoc de 30 – IDoc prêt à être envoyé à 03 – Données IDoc transmises au port OK. Du point de vue de SAP, cela signifie que le système SAP a transféré avec succès l'IDoc au partenaire configuré pour le recevoir. À ce stade, le système SAP ignore ce qu'il est advenu de l'IDoc par la suite. Si vous utilisez la surveillance des IDoc, les outils utilisés ne seront jamais en mesure de déterminer ce qu'il est advenu des données envoyées via l'IDoc. Laisser les IDoc dans le statut 03 est donc généralement insatisfaisant, car vous souhaitez naturellement savoir si les données ont bien atteint leur destination ou si un problème est survenu en cours de route afin de pouvoir éventuellement déclencher des alertes ou prendre d'autres mesures pour résoudre le problème d'informations manquantes.
Pour modifier le statut de l'IDoc dans SAP, vous devez renvoyer au système SAP un IDocSYSTAT01 nouvellement créé, de type de message STATUS.
Nous avons joint ci-dessous un exemple de pipeline qui reçoit notre IDoc ZPERSON01 utilisé tout au long du blog, écrit le contenu dans un serveur MSSQL, puis continue à construire un nouvel IDoc SYSSTAT01 contenant le code d'état 12 – Envoi OKsi l'écriture dans la base de données a réussi et 11 – Erreur lors de l'envoi si elle a échoué.
Le JSON ci-dessous contient les champs pertinents pour modifier le statut de l'IDoc, tels que le DOCNUM contenant le numéro d'IDoc de l'IDoc dont le STATUS doit être modifié, les informations textuelles dans le champ STATXT, ainsi que la date et l'heure auxquelles la modification a eu lieu.
{
"EDI_DC40": {
"MESTYP" : "STATUS",
"SNDPRT" : "LS",
"SNDPRN" : "SNPCLNT000",
"SNDPOR" : "A000000002",
"RCVPRT" : "LS",
"RCVPRN" : "A4HCLNT001"
},
"E1STATS": [
{
"DOCNUM": "1009",
"STATUS": "12",
"STATXT": "Message Processessed Successfully in Snaplogic",
"STAPA4": "status",
"LOGDAT": "20240307",
"LOGTIM": "000000"
}
]
}Pour recevoir correctement le type de message, votre configuration ALE dans SAP doit contenir le STATUS en tant que type de message entrant traité par le code de processus STA1, comme indiqué dans la transaction WE20 ci-dessous.
Dans la dernière partie de notre série d'articles sur les SAP IDoc Snaps, nous allons nous intéresser à la sécurisation de la communication entre SAP et SnapLogic en configurant Secure Network Communication (SNC). Techniquement, cette configuration ne fait pas partie du traitement IDoc, mais elle est utilisée par tous les SAP Snaps qui communiquent avec le système SAP via les bibliothèques SAP JCo. Elle concerne également les SAP Snaps qui exécutent RFC, tels que le SAP Execute et SAP RFC Listener Snaps.
