Dans mon dernier article sur ce sujet, j’ai discuté de plusieurs méthodes d’investigation des données de pointeur de modification que j’utilise pour m’orienter dans la bonne direction de nettoyage.
L’analyse des données du pointeur de modification déterminera comment concevoir le processus de nettoyage. Armé de statistiques significatives, j’approche généralement les propriétaires fonctionnels de l’entreprise pour collaborer sur une solution. Les nombreuses questions que je pose sont typiques des suivantes : « Pourquoi les pointeurs de modification sont-ils configurés pour ce type de message si nous ne distribuons jamais les IDOC ? »
Points de discussion et procédures pour le processus de nettoyage.
1. Sauf s’il existe un code ABAP personnalisé dépendant de l’existence continue des pointeurs de modification traités, ils ne servent à rien et doivent être supprimés. Le programme ABAP RBDCPCLR doit être planifié régulièrement afin que les pointeurs de modification « traités » récents soient purgés.
S’il existe une grande quantité d’enregistrements de pointeur de modification « traités » très anciens, envisagez des exécutions spéciales de RBDCPCLR où la plage de dates sélectionnée est suffisamment ancienne pour collecter et purger ces enregistrements.
Pour nettoyer les pointeurs de modification traités, utilisez la section Pointeurs de modification traités sur l’écran d’option de sélection du programme RBDCPCLR. Assurez-vous que la case « Pointeurs de modification traités » est cochée et entrez la plage de dates appropriée. Vous pouvez limiter davantage la sélection des données en saisissant un type de message dans la zone Type de message.
Notez que sur l’écran de sélection, il y a également une case à cocher « Test Run » qui répertorie les enregistrements qui seraient sélectionnés pour la purge, sans les purger réellement. Je trouve cette fonctionnalité très utile et je recommande fortement de l’utiliser avant la purge proprement dite.
2. Les enregistrements de pointeur de modification « non traités » qui sont très anciens ne sont probablement pas utilisables. Si les IDOC qu’ils représentent étaient déclenchés maintenant, les données distribuées pourraient ne plus être valides. Le point de discussion important ici est la définition de « très vieux ». Est-ce un an, six mois, deux semaines ? Est-ce un an, six mois, deux semaines ?
Une fois la définition de « très ancienne » établie, planifiez les exécutions de RBDCPCLR avec la case « Pointeurs de changement obsolètes » cochée et la date « très ancienne » convenue saisie dans la case de date. Cette exécution supprimera les enregistrements de pointeur de modification « traités » et « non traités » jusqu’à la date spécifiée.
Notez que sur l’écran de sélection, il y a également une case à cocher « Test Run » qui répertorie les enregistrements qui seraient sélectionnés pour la purge, sans les purger réellement. Je trouve cette fonctionnalité très utile et je recommande fortement de l’utiliser avant la purge proprement dite.
3. Les pointeurs de modification « non traités » jugés récents doivent être analysés pour déterminer pourquoi ces enregistrements sont configurés pour la création s’ils ne sont jamais réellement traités. Peut-être qu’ils étaient nécessaires à un moment donné et qu’ils ne le sont plus maintenant. Ce dont j’ai besoin ici, de la part des propriétaires d’entreprise fonctionnels, c’est d’un accord pour désactiver, lors de la configuration, la création de ces pointeurs de changement. Ne pas les désactiver ne fera que continuer à ajouter des enregistrements inutiles aux tables de pointeurs de modification.
Une fois la création de ces pointeurs de modification désactivée dans la configuration, planifiez une exécution de RBDCPCLR à l’aide de la section obsolète de l’écran de sélection. Entrez le type de message dans la zone Type de message et la date actuelle. Cela purgera tous les pointeurs de modification du type de message spécifié, quel que soit leur statut, jusqu’à la date spécifiée. Il convient ici de veiller particulièrement à ce que les options de sélection soient saisies correctement.
Notez que sur l’écran de sélection, il y a également une case à cocher « Test Run » qui répertorie les enregistrements qui seraient sélectionnés pour la purge, sans les purger réellement. Je trouve cette fonctionnalité très utile et je recommande fortement de l’utiliser avant la purge proprement dite.
4. Comparez la liste des types de messages configurés pour créer des pointeurs de modification (utilisez la transaction SAP BD50) à la liste des types de messages dans les exécutions RBDMIDOC et à la liste des types de messages dans les exécutions RBDCPCLR. Assurez-vous que les trois listes concordent. Passez en revue ces listes avec les propriétaires fonctionnels de l’entreprise. Assurez-vous que ce qui est configuré répond aux besoins des processus métier actuels.
Je demande également aux propriétaires fonctionnels de l’entreprise de revoir les valeurs des champs de table sélectionnées qui, lorsqu’elles sont modifiées ou créées, déclencheront la création d’enregistrements de pointeur de modification (utilisez la transaction SAP BD52). L’objectif, encore une fois, est de s’assurer que ce qui est configuré répond aux besoins des processus métier actuels.
Maintenant que nous avons fait le ménage, comment pouvons-nous contrôler la taille des tables de pointeurs de modification ?
Dans mon prochain article, je discuterai des éléments que je recommande de surveiller.