Introduction
La gestion des chargements en mode delta dans SAP BW n’est pas évidente à appréhender que ce soit pour les données de base (master data) ou les données transactionnelles (transaction data).
Nous avons déjà rencontré chez des clients des systèmes BW avec des données de base chargées systématiquement en full car la raison pour laquelle la modification de donnée de base dans SAP n’a pas déclenché de mise à jour delta pour BW n’était pas connue.
Nous vous proposons donc aujourd’hui un article sur la gestion du delta des données de base dans SAP BW.
Charger en full systématiquement les données de base peut augmenter énormément les temps de chargement de BW, surtout sur des flux non optimisés HANA. Sur des InfoCubes classiques avec agrégats, la répercussion des données de base doit se faire dans tous les niveaux supérieurs (activation des données et change-run).
Fonctionnement de la gestion du delta des données de base
Une batterie de tables dans SAP permet de gérer (DataSource par DataSource) la liste des zones qui doivent être prises en compte dès lors qu’elles sont modifiées dans SAP.
Le système SAP dispose déjà d’un système de suivi des modifications des données au travers des tables CDHDR et CDPOS.
Exemple ci-dessous de modification d’un article au niveau du « Groupe de marchandises » (MARA-MATKL), modification de la valeur L003 à la valeur L004. On s’attend donc à avoir du delta pour BW au niveau du DataSource des données de base article 0MATERIAL_ATTR.
Le suivi des modifications a enregistré la modification ancienne et nouvelle valeur.
La modification (31644) est stockée dans SAP au niveau des tables CDHDR et CDPOS.
Ce suivi de modification s’effectue à condition que l’option « Doc de modif » de la zone modifiée soit cochée au niveau des propriétés de l’élément de données MARA-MATKL.
La modification (31644) est ensuite reprise dans la table BDCP2 pour générer du delta pour BW si la zone MARA-MATKL est présente dans la table TBD62.
Sur l’ensemble des zones suivies en modification dans SAP, toutes n’intéressent pas forcément BW, raison pour laquelle il existe la table TBD62 qui liste les zones qui déclencheront du delta pour BW.
Cette table se gère au niveau de la transaction BD52.
Dans la table TBD62, la zone MARA-MATKL est présente donc la modification va déclencher du delta.
C’est dans cette table par exemple que les zones spécifiques Z vont pouvoir être ajoutées afin de déclencher du delta.
Pour un datasource donné (ici 0MATERIAL_ATTR) correspond un type de message. Ce type de message se trouve dans la table ROOSGEN.
Le type de message dans notre exemple est RS0001. On interroge donc la table TBD62 ou la transaction BD52 avec ce type de message.
La table ROMDDELTA contient la liste des datasources activés en RSA5 et la table BDCPV contient les pointeurs de modification.
CONCLUSION DE L’EXPERT
Sur de faibles volumétries, charger toutes les données de base en full ne posera pas de problèmes et sera même plus simple à gérer. On se ne pose pas de question, c’est un mode annule et remplace.
Sur des volumétries de type 800 000 articles croisés avec un gros volume de données transactionnelles, cela peut avoir de grosses répercussions sur les temps de chargement.
Cette gestion de tables permet des réglages plus fins pour une mise à jour delta optimisée.
