Même si ce blog portera principalement sur SAP XI/PI, je m’en voudrais de ne pas mentionner d’autres sujets d’intégration SAP. Ainsi, mon premier blog technique portera sur mon plus gros reproche concernant le domaine plus large de l’intégration SAP. À savoir les périls du traitement immédiat des IDOC !
J’ai découvert à la fois SAP ALE (qui signifie Application Link Enabling et prononcé par ses lettres individuelles : « A, L, E ») et la boisson dorée du même nom en 1998. J’étais à l’université à l’époque. Un de mes pairs s’intéressait à l’ALE (la boisson, pas la technologie SAP) et avait des connaissances sur le sujet bien supérieures aux miennes. Un soir, il a ramené à la maison une variété de bières d’une brasserie locale. Au fil du temps, j’ai très bien connu la bière (peut-être un peu trop bien ?) et depuis, je suis devenue accro.
Mon introduction à SAP ALE était similaire. J’étais à l’université et un de mes collègues m’a présenté l’ALE. Il faisait partie de l’équipe de distribution des données de référence sur une très grande implémentation SAP. Son travail consistait à garantir que les paramètres SAP ALE étaient corrects dans l’ensemble du paysage SAP. Il m’a appris les bases de l’ALE en quelques heures. Au fil du temps, à mesure que j’en apprenais davantage sur SAP ALE, j’ai développé un penchant pour celui-ci qui rivalisait avec mon penchant pour son homologue alcoolique.
ALE et ale se ressemblent beaucoup. Ni l’un ni l’autre ne nécessite un investissement initial important (quelques transactions pour l’ALE, quelques dollars pour la bière), mais les deux nécessitent une bonne quantité d’apprentissage et sont pleinement appréciés. Pour vraiment comprendre l’ALE, vous devez comprendre toutes ses composantes : l’eau, le malt, le houblon et la levure, ainsi que la manière dont elles interagissent. Comme SAP ALE, trop de bière vous fera tourner la tête.
Et tout comme vous ne voudriez pas boire des quantités massives de bière et faire immédiatement un tour avec une Ferrari à 150 000 $, vous ne devez pas traiter immédiatement des quantités massives d’IDOC sur votre instance SAP productive. Le problème numéro un que je vois chez les clients utilisant ALE/IDOC est la configuration du profil de partenaire pour traiter l’IDOC immédiatement.
Le problème du traitement immédiat des IDOC survient lorsqu’un grand nombre d’IDOC sont reçus en même temps. Qu’est-ce qui constitue un « grand nombre d’IDOC » ? Eh bien, cela dépend de votre système SAP. Les problèmes surviennent généralement lorsque plus d’IDOC arrivent que de processus de travail de premier plan. Lorsque plus d’IDOC arrivent que votre système ne dispose de ressources, non seulement vous pouvez affecter les utilisateurs en ligne du système (hé, il n’y a qu’un nombre limité de processus de travail de premier plan), vous courez également le risque de voir certains des IDOC entrants tomber dans le redoutable Statut “double 64”. Les IDOC qui ne peuvent pas être traités en raison de ressources limitées reçoivent un enregistrement de statut 64 supplémentaire et ne sont pas traités par le système. La seule manière de gérer ces IDOC est de les traiter manuellement (via BD87 ou BD20) ou par un job en arrière-plan (RBDAPP01).
Une bien meilleure façon de gérer les IDOC de traitement des IDOC consiste à collecter les IDOC, puis à les traiter via une tâche en arrière-plan (RSEOUT00 pour les IDOC sortants, RBDAPP01 pour les IDOC entrants). Cela réduit considérablement la charge sur le système et ne fera pas en sorte que votre système morde la poussière dans les situations de charge élevée. De plus, des options de réglage des performances sont disponibles sur RSEOUT00 et RBDAPP01 qui permettront à votre traitement IDOC de vraiment chanter ! Je couvrirai probablement les paramètres avancés de ces programmes dans des blogs ultérieurs. Je sais, vous avez hâte !
En bref, ALE est une excellente technologie, mais c’est une technologie asynchrone (c’est-à-dire par lots). Il y a très peu de raisons pour lesquelles le traitement immédiat des IDOC est acceptable. Dans la plupart des cas, une tâche RBDAPP01 planifiée toutes les 5 minutes sur 10 est plus que suffisamment rapide pour l’entreprise. Si un décalage maximum de 5 minutes (rappelez-vous uniquement les IDOC arrivés juste après la tâche précédente attendez 5 minutes, le temps d’attente moyen est de 2h30) n’est pas acceptable, une interface synchrone, basée sur des BAPI, des RFC ou des services Web, devrait être considéré.