Monitorer les interfaces : en ayant une vraie stratégie de suivi des erreurs
Que ce soit pour un projet de migration ou pour la mise en place d’une nouvelle fonctionnalité, il n’est pas rare d’avoir besoin de créer des interfaces entre 2 logiciels. Si on n’oublie jamais de tester l’automatisation et la bonne intégration des données lors de la phase de recette, on oublie en revanche souvent de poser (et partager) une stratégie pérenne de gestion des anomalies. Des clients nous appellent alors désemparés car ils voient des messages d’erreurs de plus en plus nombreux qu'ils n'arrivent pas à traiter dans des délais raisonnables. Ou à l’inverse ils se rendent compte que certaines données se sont « perdues » dans l’interface sans en avoir été notifiées. Nous allons voir pourquoi il faut s’attendre à avoir des erreurs. Mais également quelles sont les bonnes questions à se poser. Et enfin nous détaillerons plusieurs modèles de gestion des erreurs.
Les erreurs d’interfaces
Plus les contrôles demandés seront poussés, plus sûre sera l’interface. Vous ne risquerez pas d’avoir, un matin, des milliers de fiches client ayant le même SIRET ou des milliers de factures client antidatées par exemple.
Voici une liste non exhaustive d’erreurs pouvant survenir sur des interfaces :
-
Erreurs sur la donnée dans le logiciel amont : typiquement un champ n’est pas obligatoire dans le logiciel source mais l’est dans le logiciel cible. Bien que tous les services se soient mis d’accord pour que cette donnée soit renseignée, un oubli est vite arrivé…
-
Interface « coupée » : une coupure du réseau ou une désactivation de l’automatisation de l’interface.
-
Paramétrage modifié : par exemple la fermeture d’une période comptable avant un weekend alors que des flux logistiques ont lieu le samedi, la désactivation ou l’activation d’une option comme l’attribution obligatoire d’un numéro de série à un article.
-
Blocage sécuritaire nécessitant une validation/action manuelle : parfois, on souhaite vérifier avant intégration des documents ou des données de base pour lesquels il n’est pas prévu de workflow de validation.
-
Blocage temporaire : typiquement l’interface veut enregistrer une facture fournisseur mais un utilisateur est en modification sur la commande d’achat.
Les questions à se poser
La première étape est de définir les personnes ou le service « responsables » du suivi des erreurs. Ce ne sont pas forcément ces personnes qui résoudront tous les problèmes cités plus haut mais ce sont ces personnes qui s’assureront au quotidien :
-
du bon fonctionnement de l’interface
-
de transférer les messages d’erreurs aux personnes qui doivent les corriger (et de les relancer jusqu’à correction)
-
d’alerter en cas d’arrêt prolongé ou d’explosion du nombre d’erreurs sur l’interface.
Il s’agira souvent de personnes à l’informatique ou proche des services informatiques. Le support aux utilisateurs est généralement une bonne idée. Ils ont des accès souvent plus larges que les simples utilisateurs, une culture informatique qui facilite la montée en compétence sur SAP, l’habitude de créer des tickets incidents et de contacter d’autres services. On peut sinon souhaiter que les erreurs soient suivies par des responsables d’application côté informatique ou encore par des keyusers côté métier. Enfin, on peut choisir que la responsabilité redescende aux opérationnels qui réalisent la saisie. Par expérience, les messages d’erreurs étant normalement rares sur les interfaces, les opérationnels auront tendance à appeler le support utilisateur s’ils rencontrent une erreur… A noter que la technologie choisie pour l’interface peut influer sur le choix des responsables du monitoring (par exemple, les idocs sont difficiles à maîtriser pour les métiers car peu user friendly).
Une fois répondu à la question qui surveillera, il faudra se poser les questions suivantes :
-
Un outil est-il déjà présent pour surveiller la nouvelle interface ou un développement est-il nécessaire ?
-
Les personnes responsables ont-elles les droits suffisants ?
-
Faut-il prévoir une formation ?
-
Faut-il des documents spécifiques (protocoles à suivre pour chaque erreur) ?
Différentes méthodes de gestion des erreurs
Méthode 1 : suppression de l’erreur et relance totale de l’interface
Si votre interface fonctionne en « tout ou rien », c’est forcément vers cette stratégie de gestion des erreurs que vous allez vous tourner. Après avoir pris connaissance que l’interface a échoué, on corrige l’erreur si cela est possible et on relance l’interface ou bien on exclut l’erreur (pour intégrer la donnée manuellement) et on relance l’interface avec le reste des données sans erreur. Dans les deux cas, le message d’erreur a vocation à être archivé manuellement.
Cas client :
Intégration de fichiers plats (CSV) contenant des relevés financiers mensuels de remboursement d’un organisme avec un total et son détail devant amener la création de plusieurs pièces comptables. Une opération du mois précédent avait été bloquée et n’avait pas été incluse dans le transfert du mois précédent. Les comptables ayant fermé la période, cette pièce comptable ne peut s’enregistrer. Le job affiche un statut « Interrompu » et envoie un courriel à l’exploitation. Après s’être mis d’accord avec le service comptabilité, le service informatique a modifié la date comptable sur la ligne du fichier CSV et à relancer l’intégration de tout le fichier en créant un nouveau job.
Méthode 2 : retraitement de l’erreur
Cette méthode est applicable lorsque l’interface permet une « mise en pause » puis reprise de l’intégration. Les données sont conservées dans des tables de travail en attendant une action corrective. Une fois l’action corrective effectuée, le programme reprend là où il s’était arrêté et efface lui-même le message d’erreur qui n’a plus lieu d’être.
Cas client 1 :
Utilisation d’idocs pour intégrer les données, SAP fournit un outil de monitoring pour afficher les idocs en erreurs qui n’ont pas pu s’intégrer et qui permet de les modifier et de les relancer. Cet outil est plutôt à destination de profils informaticiens car les noms techniques sont visibles.
Afin de donner la main à des utilisateurs métier, un autre outil a été développé avec 4 boutons plus parlants pour eux : Relancer l’idoc, Archiver l’idoc, Corriger, Mode opératoire (raccourci vers la documentation) :
Cas client 2 :
Interface plusieurs fois par jour entre SAP et un logiciel de gestion d’entrepôt. Après l’expédition d’un colis, deux documents doivent être créés dans SAP SD (une livraison avec prélèvement dans le stock, une facture). Le choix a été fait d’un programme structure qui va suivre des étapes entre 00 et 99, selon une table spécifique de paramétrage. Chaque colis arrive donc « brut sans contrôle » dans des tables de travail à l’étape « 00 ». A chaque étape correspond un module fonction. Si lors de l’appel du module fonction est renvoyé un succès, le programme structure fait passer l’enregistrement au numéro de l’étape suivante (jusqu’à 99). Si c’est un échec, le programme ne modifie pas le numéro de l’étape. Certains colis vont donc s’arrêter lors de la phase de contrôle des données, d’autres après la création du doc de livraison dans SAP mais ont une erreur lors du prélèvement, tandis que d’autres auront peut-être une erreur à la génération de la facture. L’outil de monitoring spécifique qui a été développé permet d’afficher les erreurs à chaque étape et de renvoyer en traitement le colis à l’étape où il est tombé en erreur.
Méthode 3 : préenregistrement de la donnée et workflow de correction dans SAP
Pour certains documents, SAP a prévu un préenregistrement du document lorsque l’enregistrement n’est pas autorisé. C’est le cas dans le module MM où il est possible de préenregistrer une commande d’achat ou une facture. Dans le module SD, les documents peuvent être enregistrés dans un statut “incomplet”, ce qui bloquera tout flux de document tant que le document n’aura pas été complété.
Cas client :
Utilisation de l’outil Readsoft pour la gestion des factures fournisseurs entrantes (dématérialisées ou papier). En cas d’écart à la commande d’achat, la facture est préenregistrée dans SAP mais est encore modifiable. Les comptables peuvent choisir de déclencher un ou plusieurs workflows de litiges (écart de prix, de quantité ou d’article) à destination des entrepôts ou peuvent corriger la facture s’il s’agissait d’une mauvaise reconnaissance du scan du document papier.
Exemple d’application FIORI standard permettant de suivre des documents incomplets :
Conclusion
Ce problème de monitoring d’interfaces est généralement identifié lors d’une phase VSR (Vérification de Service Régulier) de projet : les développements ont été installés en production, la solution est déployée auprès des services concernés, le nombre de données échangées est plus important et les erreurs s’accumulent. Pour travailler de manière sereine, il faut donc anticiper et aborder le sujet de la gestion des erreurs dès la conception. En fonction de la stratégie choisie, le chiffrage pourra être impacté et un travail supplémentaire sera à prévoir dans certaines équipes.