Dans la deuxième partie de la série d'articles consacrés à l'intégration de SAP à l'aide des Snap SAP IDoc, nous allons examiner le comportement des Snap IDoc Write et les différents paramètres que vous pouvez définir. Nous allons également vous expliquer comment configurer SAP pour que le pipeline SnapLogic s'exécute de manière synchrone ou asynchrone, si vous souhaitez poursuivre le traitement de votre pipeline sans attendre la fin du traitement IDoc dans le système SAP.
Comprendre les paramètres dans l'IDoc Write Snap
Le paramètre le plus important que vous devrez définir est l'ajout du nom du module fonction dans le champ IDoc Read BAPI Name (Nom BAPI de lecture IDoc) qui est utilisé pour lire le statut de l'IDoc une fois qu'il a été créé dans le système SAP. Nous avons abordé le module fonction dans la première partie de notre série d'articles et avons joint un exemple d'implémentation au bas du premier blog. Une fois qu'un IDoc est créé, le Snap tentera de lire l'IDoc via le module fonction exactement une fois afin de déterminer le statut actuel de l'IDoc dans le système SAP, puis utilisera ce statut pour déterminer si le pipeline SnapLogic doit continuer à traiter le document en aval ou le diriger vers la vue d'erreurs. Pour que le Snap puisse le faire, la case « Route errors » (Acheminer les erreurs ) doit être cochée.
Les statuts IDoc dans le système SAP sont divisés en deux parties : les IDoc sortants allant de 01 à 42 et le traitement des IDoc entrants allant de 50 à 75. Vous pouvez consulter la liste complète des codes de statut IDoc à l'aide de la transaction WE47 dans le système SAP. Entrer dans les détails des codes de statut IDoc dépasse le cadre de ce blog, mais le traitement standard des IDoc entrants passe généralement par les transitions d'état suivantes :
- 50 IDoc ajoutés
- 64 IDoc prêt à être transmis
- 62 IDoc transmis à l'application
- 53 Document de candidature publié.
En ajoutant les codes d'état ci-dessus aux champs Codes de réussite, vous indiquez à Snap d'acheminer les documents vers la vue de sortie si les IDocs créés ont l'un de ces statuts au moment de la lecture du statut. Tous les autres documents qui ont créé des IDocs avec d'autres statuts seront acheminés vers la vue d'erreur. Encore une fois, comme le module fonction ne lit le statut qu'une seule fois et ne tient compte que du statut actuel au moment de la lecture, il est essentiel d'ajouter tous les statuts au champ qui doit être utilisé pour poursuivre le traitement de votre document en aval.
Le intervalle de sondage et le délai d'interrogation déterminent le temps pendant lequel Snap doit attendre pour déterminer le statut de l'IDoc. Si l'intervalle d'interrogation est défini sur 0, Snap n'utilisera pas le module fonction et n'essaiera pas de lire le statut de l'IDoc. Tout paramètre supérieur à 0 sera utilisé comme nombre de secondes à attendre entre les appels au système SAP pour lire un statut. Le délai d'expiration de l'interrogation déterminera le temps total à attendre avant de lancer une exception Java. Ces paramètres peuvent être utilisés si vous créez des IDocs dans des systèmes SAP très chargés, pour lesquels vous devez déterminer le statut de l'IDoc afin de définir votre routage.
Comprendre le comportement de traitement des IDocs dans SAP
Au moment de la rédaction du présent document, les IDocs SAP SnapLogic ne prennent en charge que le tRFC (appel de fonction à distance transactionnel) et qRFC (appel de fonction distant en file d'attente) n'est pas pris en charge. De plus, nos IDoc Snaps utilisent la la bibliothèque JCO de SAP et la bibliothèque Java IDoc qui l'accompagne bibliothèque Java IDoc pour créer des IDoc. Nous nous concentrerons donc uniquement sur le comportement de la bibliothèque Java IDoc lors de l'appel de JCoIDoc.send(..). Notez que les systèmes qui n'utilisent pas ces bibliothèques peuvent présenter un comportement différent ainsi que des options différentes.
Comportement synchrone du traitement des IDoc
Lorsque nous avons commencé à étudier les différents comportements, nous avons souvent trouvé sur Internet des commentaires affirmant que les IDocs sont toujours asynchrones. Cependant, nous avons observé un comportement différent lors de l'utilisation du snap IDoc Write, qui semblait attendre la « fin » du traitement dans SAP avant de continuer. Nous avons fini par poster une question sur réseau des développeurs logiciels de SAP. Nous avons rapidement obtenu une réponse qui nous renvoyait à la note SAP 180057 qui explique que SAP a modifié le comportement du module fonction IDOC_INBOUND_ASYNCHRONOUS et ne découple plus la création de l'IDoc dans la couche ALE du transfert vers l'application. IDOC_INBOUND_ASYNCHRONOUS est le module fonction utilisé dans la bibliothèque Java IDoc par la méthode JCoIDoc.send(..). Cela signifie que si vous avez configuré votre IDoc provenant de SnapLogic pour qu'il soit traité immédiatement dans la transaction WE20, comme le montre la capture d'écran ci-dessous.
La création de l'IDoc dans la couche ALE de SAP se fera dans le cadre du même processus que le traitement de l'IDoc par l'application, et la bibliothèque Java SAP IDoc attendra que l'application ait terminé le traitement de l'IDoc. Tant que la bibliothèque attend, l'IDoc Write Snap ne peut pas appeler le statut de l'IDoc, même si celui-ci a déjà passé les codes de statut 50, 64 et 62. Ce comportement lie effectivement le pipeline SnapLogic à l'ensemble du traitement de l'IDoc par l'application dans SAP, et le pipeline ne continuera qu'une fois le traitement de l'IDoc terminé.
Options pour le traitement asynchrone des IDocs
Si vous souhaitez dissocier votre pipeline SnapLogic du traitement de l'IDoc dans note SAP 180057 , plusieurs options s'offrent à vous. Malheureusement, la première solution consistant à utiliser le module fonction INBOUND_IDOC_PROCESS n'est pas disponible pour nous, car la bibliothèque Java SAP IDoc ne permet pas d'utiliser ce module fonction. De même, la deuxième option, qui consiste à transférer des paquets d'IDoc plus petits, ne fonctionne pas, car elle nécessite toujours d'attendre que l'application termine le traitement. Il nous reste donc deux options : la première serait de passer le traitement de votre IDoc dans la transaction WE20 de Déclencher immédiatement à Déclencher dans arrière-plan programme.
Cette configuration dissociera la création de l'IDoc dans la couche ALE de SAP du traitement de l'IDoc par l'application et permettra à SAP IDoc Write de continuer dès que l'IDoc sera créé dans la couche ALE. Cela signifie également que le statut de votre IDoc lorsque le SAP IDoc Write Snap le lit ne dépassera jamais 64.
La deuxième option consiste à utiliser un port ABAP-PI pour l'IDoc entrant dans la transaction WE21, puis à spécifier le port ABAP-PI à la place d'un port RFC transactionnel dans la structure de contrôle de votre IDoc.
La capture d'écran ci-dessous illustre la configuration du port dans la transaction WE21. Lors de la création du port, vous pouvez choisir n'importe quel module fonction. Dans ce cas, nous avons utilisé RFC_PING. Il convient de noter que le module fonction que vous spécifiez n'est pas utilisé pendant le traitement entrant, mais qu'il est nécessaire pour enregistrer la configuration.
Une fois le port spécifié, utilisez le nouveau nom de port, ASYNC0001, dans notre cas, dans le champ SNDPOR de la structure de contrôle de votre IDOC. Pour vous donner une idée, nous utilisons le JSON ci-dessous dans un Snap JSON Generator dans l'exemple de pipeline que nous avons joint à la première partie de la série d'articles, mais nous remplaçons le champ SNDPOR par le nom du port ABAP-PI.
{
"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
}
]
}Lorsqu'il est envoyé via un port ABAP-PI, le système SAP lance l'application pour un traitement direct, mais n'attend pas la fin du traitement. Votre IDoc Write Snap pourra continuer à lire le statut immédiatement.
Test du comportement lors du passage du traitement synchrone au traitement asynchrone
Pour tester le comportement, nous avons créé un IDoc dans le système SAP et développé une petite application qui récupère les données de l'IDoc entrant et les écrit dans une table de la base de données du système SAP. Pour simuler un traitement IDoc de longue durée, nous avons ajouté une instruction sleep de 60 secondes. Lorsque nous créons un IDoc en l'envoyant au port tRFC, nous pouvons voir que l'exécution du pipeline prendra un peu plus d'une minute.
Si nous envoyons le même IDoc via le port ABAP-PI, le traitement du pipeline sera terminé en quelques millisecondes.
Dans la troisième partie de notre série d'articles, nous allons nous intéresser aux snaps IDoc Listen et IDoc Document Listen. Nous allons également voir comment modifier le statut d'un IDoc dans le système SAP que nous avons reçu via les snaps d'écoute afin de refléter avec précision son statut une fois qu'il a été traité par le processus SnapLogic.
