Pour ceux d’entre vous qui connaissent PI, vous savez qu’il aime traiter des messages uniques, et non plusieurs messages en masse. De nombreuses interfaces vers des systèmes « hérités » nécessitent des interfaces à fichier unique. Si vous utilisez un adaptateur d’expéditeur de fichier et un adaptateur de récepteur IDOC, j’ai une petite astuce pour vous qui vous permettra de traiter un fichier en plusieurs IDOC.
Chez un de mes clients, j’ai dû développer une interface pour accepter un fichier avec des accusés de réception IDOC. Notre système SAP envoyait des données à un système externe et le système externe renvoyait des messages de statut que nous devions publier à l’aide d’ALEAUD. Le fichier d’état était écrit périodiquement et pouvait contenir un nombre illimité d’enregistrements. Chaque enregistrement devait être son propre IDOC. Le problème est qu’il n’existe pas de solution « prête à l’emploi » permettant le mappage de fichiers 1:N vers IDOC. J’ai cherché un peu sur SDN et j’ai découvert qu’il y en avait d’autres avec mon même problème. Cependant, toutes les réponses suggèrent d’utiliser le BPM. Cela ne me semblait tout simplement pas correct. Les BPM sont géniaux et tout, mais je ne pense pas que je devrais avoir besoin d’implémenter un BPM pour faire quelque chose d’aussi simple que des corrélations 1:N. J’ai cherché une meilleure façon d’effectuer des corrélations 1:N avec les IDOC et j’ai découvert que c’était en fait très simple.
Après avoir fait mes recherches, j’ai découvert que le problème ne venait pas de l’adaptateur IDOC ni du moteur de mappage, mais plutôt des métadonnées importées de l’instance ECC. Les métadonnées décrivant les IDOC ont un élément de “1..1” – c’est-à-dire chaque message contenant un IDOC peut contenir un et un seul IDOC. Il s’avère que SAP gère le cas si plusieurs IDOC sont transmis à l’adaptateur IDOC récepteur. Le moteur de mappage peut facilement gérer plusieurs occurrences d’IDOC. La seule limitation concerne les métadonnées IDOC et, comme je vais vous le montrer ci-dessous, c’est une limitation facile à surmonter.
- Tout d’abord, dans votre référentiel d’intégration XI, téléchargez la définition IDOC à partir de votre instance ECC/R/3 comme vous le feriez normalement pour n’importe quel scénario d’intégration IDOC standard.
- Complétez le mappage des messages et le reste du développement du scénario d’intégration comme d’habitude.
Remarquez comment le message source a une occurrence de 1..unbounded, mais le message de destination est limité à une occurrence de 1..1. Si le mappage devait rester ainsi, quel que soit le nombre de balises IDOC présentes dans le XML source, une et une seule balise IDOC serait créée dans le XML résultant. Nous nous en occuperons ensuite. - Exportez le XSD de l’IDOC vers un fichier sur votre PC.
- Ouvrez le fichier dans un éditeur de texte et modifiez l’élément nommé “IDOC”. Ajoutez le texte suivant :
minOccurs="1" maxOccurs="unbounded"
Enregistrez et fermez le fichier XSD. - Dans le mappage de message créé à l’étape 2, importez le XSD créé à l’étape précédente comme référence de message pour l’IDOC. Remarquez comment la mauvaise contrainte d’occurrence “1..1” sur la balise IDOC est désormais “1..unbounded” !
- Plusieurs lignes dans le fichier créeront plusieurs IDOC ! Êtes-vous aussi excité que moi ?
Alors, qu’avons-nous appris aujourd’hui ?
- Vous n’êtes pas complètement enfermé dans les métadonnées dérivées de SAP.
- L’adaptateur IDOC du récepteur est assez indulgent (beaucoup plus que l’adaptateur IDOC de l’expéditeur – nous en reparlerons un autre jour)
- Plus important encore, il est possible d’effectuer une corrélation de récepteur IDOC multi-messages 1:N sans BPM !
