En tant que consultant, j’ai l’opportunité de travailler sur de nombreuses installations SAP différentes. Je continue d’être surpris par la découverte que bon nombre de ces entreprises ne gèrent pas correctement leurs tables de pointeurs de modifications, ce qui permet à ces tables d’augmenter continuellement en taille sur de longues périodes de temps. Grâce à l’investigation des données, j’ai constaté que le nombre d’enregistrements de pointeurs modifiés atteignait deux milliards (et continue de croître), et que les dates de création d’enregistrements de pointeurs modifiés dataient de plusieurs années avec un statut à la fois traité et non traité.
Que sont les indicateurs de changement, où se trouvent-ils et quel est leur objectif dans un système SAP ?
Lorsqu’ils sont activés dans la configuration, les enregistrements de pointeur de modification sont écrits dans les tables de données de pointeur de modification SAP lorsque les données principales sont conservées, dans le cadre de la fonction de données principales partagées. Leur objectif principal est de faciliter la distribution des ajouts et des modifications de données de base du système hôte SAP vers les systèmes distants, via ALE à l’aide d’IDOC. Le Customizing de la configuration est utilisé pour déterminer si la création d’enregistrements de pointeur de modification est activée ou non, et si elle est activée, quels types de messages et modifications de champs de table de données déclencheront la création d’enregistrements de pointeur de modification.
Les enregistrements de pointeur de modification résident dans les tables de données BDCP et BDCPS. Il existe également une vue BDCPV qui combine les champs de ces deux tables. La table BDCP est la table principale de données du pointeur de modification et la table BDCPS contient l’état (traité ou non traité) de l’enregistrement du pointeur de modification.
Un nouvel enregistrement de pointeur de modification est créé dans l’état « non traité » et crée une « demande » dans le système SAP pour créer un IDOC sortant. Cette « demande » est reconnue par le programme SAP RBDMIDOC (généralement planifié dans un travail par lots périodique) qui déclenche la création de l’IDOC sortant, puis modifie l’état de l’enregistrement du pointeur de modification en « traité ». Mais même si le statut de l’enregistrement du pointeur de modification est marqué comme « traité », l’enregistrement réside toujours dans les tables BDCP et BDCPS.
Alors, comment ces enregistrements de pointeurs de modification consommés sont-ils supprimés des tables de pointeurs de modification ? Ceci est accompli avec le programme SAP RBDCPCLR (généralement planifié dans un travail par lots périodique). En fonction de vos processus métier, le cycle de vie d’un enregistrement de pointeur de modification n’est généralement pas si long. Si vous distribuez quotidiennement vos IDOC de modification de données de base à des systèmes distants, les enregistrements de pointeur de modification associés peuvent être purgés quotidiennement. Si votre cycle de distribution est hebdomadaire, votre cycle de nettoyage doit également avoir lieu chaque semaine.
Si tout fonctionne correctement, la création de pointeurs de modification est activée, la création d’enregistrements de pointeurs de modification est conditionnée par le type de message et les champs de la table de données, RBDMIDOC s’exécute dans un travail par lots périodique planifié pour distribuer les modifications des données principales via les IDOC et marquez les enregistrements de pointeur de modification comme « traités » et RBDCPCLR s’exécute dans un travail par lots périodique planifié pour nettoyer les enregistrements de pointeur de modification « traités ».
Qu’est-ce qui pourrait alors provoquer une croissance incontrôlable des tables de pointeurs de modification ?
Dans mes deux prochains articles, je passerai en revue plusieurs méthodes que j’utilise pour identifier les sources de croissance incontrôlée dans les tables d’enregistrement des pointeurs de modification.
