Je développe donc des interfaces SAP IDOC depuis près de 20 ans. J’ai commencé avec IDOC à l’époque R/3 .0D. J’ai vu beaucoup de scénarios IDOC vraiment mal configurés. Voici donc 5 choses que je fais toujours lors de la configuration d’IDOC.
Voici 5 choses que vous devriez faire avec SAP IDOC Interface Design :
- Je n’utilise jamais le type de message livré. Qu’est-ce que je veux dire par là ? Vous implémentez une interface ORDERS sortante, de sorte que le type de message SAP standard et le type IDOC livrés seraient ORDERS:ORDERS05. Je configure toujours immédiatement un nouveau type de message. Quelque chose d’aussi simple que ZORDERS:ORDERS05 mais généralement quelque chose d’un peu plus complexe comme /xstream/orders_web ou zorders_web. Vous dites donc pourquoi feriez-vous cela alors que vous pouvez simplement utiliser le message standard délivré. Il y a un certain nombre de très bonnes raisons ; 1) Vous n’êtes probablement pas le seul à devoir utiliser ces interfaces. 2) Lorsque vous améliorez les interfaces, ce que vous devrez probablement faire, vous aurez potentiellement un impact sur les autres qui en tireront parti ou sur vous. 3) La plupart des tiers développant l’intégration dans SAP pour leurs produits respectifs ne savent pas vraiment ce qu’ils font et utilisent les noms standard et finissent donc par avoir un impact sur votre scénario d’intégration particulier avec leurs modifications. 4) Vous disposez toujours de l’interface Vanilla standard pour vous comparer lors de développements et de dépannages futurs. 5) Vous pouvez organiser votre dénomination sur plusieurs équipes/systèmes intégrés afin que le type de message vous permette de voir rapidement quel système utilise quelle transaction. Plus précisément, vous souhaitez examiner toutes les commandes pour tous les systèmes intégrés. Vous pouvez le voir si vous nommez vos types de messages de manière intelligente. REMARQUE : Ce n’est pas parce que vous avez renommé le type de message que vous avez créé une interface personnalisée. Vous venez de lui donner un nouveau nom logique. J’ai eu cet argument à plusieurs reprises au fil des années où Chicken-Little dit que toute l’intégration est personnalisée et que nous n’utilisons pas l’interface SAP standard, ce n’est pas vrai, nous utilisons une interface standard avec un nouveau nom logique.
- Si vous améliorez une routine de traitement entrant ou sortant WE41 et WE42 (même si vous venez d’implémenter un exit utilisateur), créez un nouveau code de processus, même s’il n’est pas requis. Encore une fois, de bonnes raisons pour cela ; 1) Vous permet de garder votre traitement isolé des autres traitements. 2) C’est un indice immédiat pour aider les équipes que quelque chose de non standard ne fonctionne pas. 3) Si vous modifiez le traitement à la suite de votre modification, vous pouvez toujours revenir à la norme pour voir comment le code standard se comporte.
- N’utilisez jamais de traitement immédiat sur le profil partenaire WE20 en production. JAMAIS!!! (Je pourrais écrire un livre sur toutes les mauvaises choses qui peuvent et vont arriver)
- Lors de l’amélioration des interfaces IDOC entrantes, utilisez le wrapper de pré et post-traitement autour de la routine de traitement standard lorsque cela est possible au lieu d’améliorations ou de sorties. Lorsqu’un IDOC est publié ou créé via des pointeurs de modification ou un contrôle de message, il est généralement traité via une fonction standard. Ces fonctions comportent souvent des sorties intégrées et de nombreux points d’amélioration qui vous permettent de modifier le traitement IDOC standard. Il existe des cas où ces sorties et points d’amélioration sont requis et constituent un choix logique pour mettre en œuvre votre changement spécifique. Cependant, d’après mon expérience, j’ai constaté que l’encapsulation d’une fonction standard avec une fonction wrapper peut généralement faire le travail. Pourquoi est-ce que je préfère les emballages ? Parce qu’ils sont plus faciles à trouver et à dépanner. Le traitement s’effectue avant ou après l’entrée dans la fonction de traitement standard et est contenu en un seul endroit. J’ai vu des cas où plus de 3 sorties/améliorations ont été mises en œuvre et ont causé des problèmes. Creuser le code pour trouver le code personnalisé à l’origine du problème peut prendre beaucoup de temps. Encore une fois, il y a certaines choses pour lesquelles un wrapper ne fonctionnera tout simplement pas, dans celles-ci envisagez d’encapsuler la fonction et de l’utiliser pour documenter les sorties/améliorations spécifiques que vous utilisez, car 5 ans après avoir écrit votre amélioration, le pauvre supporteur suit vos pas. ne pourra jamais trouver la documentation que vous avez créée et enregistrée dans Solution Manager. Techniquement, vous ne trouverez probablement pas la documentation que vous avez créée et enregistrée dans le gestionnaire de solutions.
- À moins que vous n’envoyiez des données sensibles, que vous disposiez de volumes de données inimaginables ou que vous implémentiez un scénario IDOC standard qui génère une tonne de données segmentées dont vous n’avez tout simplement pas besoin, évitez d’utiliser des techniques de filtrage IDOC. Plus précisément, la réduction des messages IDOC, les filtres de segments IDOC et les vues IDOC. Il y a 20 ans, ces fonctionnalités étaient importantes pour contrôler le volume du réseau et le volume de stockage. Aujourd’hui, le trafic réseau et la charge de stockage sont assez insignifiants lorsqu’ils sont conçus correctement et ne font que vous rendre la vie plus difficile lors de la maintenance de l’interface. La plupart des IDOC passent par un outil middleware, la couche de mappage est souvent un filtre IDOC naturel pour mapper uniquement les données dont vous avez besoin. Si vous appliquez des filtres en amont du middleware et que quelqu’un demande certaines des données filtrées en amont, vous devez apporter 2 modifications. Vous devez défiltrer les données, puis mettre à jour le mappage. Encore une fois, le seul endroit où j’applique des filtres aujourd’hui est celui des données sensibles dont je n’ai pas besoin pour le mappage et que je préférerais ne pas exposer dans la couche middleware. BTW, j’ai très probablement dit le contraire dans des documents publiés précédemment il y a 10 à 15 ans, car il y a 10 à 15 ans, la charge IDOC était un facteur réel sur la charge globale du système.
Encore une chose à considérer. Choisissez la bonne technologie pour votre intégration. Il existe de nombreuses approches qui peuvent être utilisées pour intégrer SAP. Dans presque tous les cas, une interface basée sur des fichiers n’est pas un bon choix, les problèmes qu’elle crée du point de vue du support sont énormes. Si vous avez besoin d’un flux asynchrone, vous devez envisager les IDOC ou les PROXY. Si vous avez besoin d’une communication synchrone, vous pouvez envisager des services RFC, BAPI, Web Services ou SAP Gateway O-Data Services directs. Chaque technologie d’intégration SAP a ses forces et ses faiblesses, alors choisissez celle qui correspond le mieux à vos besoins et à votre stratégie globale d’infrastructure.