Avec ODI, il est important de purger les données du journal (accessibles via le module Operator) pour plusieurs raisons :

• d’une part généralement lorsque l’on a de gros volumes de données de traces, seul un petit pourcentage de ces données est réellement pertinent, noyé dans la masse des données qui présentent un fonctionnement normal, qui n’atire pas l’attention ;
• d’autre part, l’accumulation des logs dans le journal peut ralentir considérablement la navigation dans le module Operator d’Oracle Data Integrator. Les filtres peuvent permettre de parer temporairement à ce problème, mais il est impératif à un moment ou à un autre de purger les logs.

PURGE MANUELLE

Il est possible de les purger « manuellement » :

• soit via l’interface graphique du module Operator :

Un bouton (en forme de corbeille) donne accès à un outil de purge :

Plusieurs paramètres peuvent alors être spécifiés concernant la purge (voir leur description en fin d’article) :

• soit en exécutant une requête SQL sur les tables systèmes d’Oracle Data Integrator ; les tables concernées sont les suivantes (dans l’ordre des contraintes référentielles) :

PURGE AUTOMATIQUE

Une autre solution, qui semble plus intéressante, est d’automatiser cette purge. Pour cela, la méthode conviviale est d’encapsuler le processus de purge dans un package ODI et de planifier l’exécution du scénario qui en découle, ou de lancer son exécution à la fin de chaque traitement souhaité.
Exemple :
On suppose vouloir automatiser la purge des données de production du journal datant de plus de 30 jours et qui se sont déroulées sans erreur.
Pour cela, on peut dans un premier temps mettre dans une variable la durée de conservation des données. On la positionne en mode « Refresh » pour qu’elle se mette à jour à chaque appel et ainsi pour que la période de conservation des logs soit « glissante ». La requête du « Refresh » peut être tout simplement la suivante :

Cette variable, ici nommée « V_FIN_PURGE », permet de garder en mémoire la date de fin de purge (la date courante reculée de 30 jours).
Ensuite il suffit de placer un composant « OdiPurgeLog » au sein du package et de spécifier ses paramètres :

Affectation des paramètres :

• Date de début : Date de début de purge. Toutes les sessions depuis cette date sont supprimées. Nous laissons ce champ vide.
• Date de fin : Date de fin de purge. Toutes les sessions jusqu’à cette date sont supprimées. Nous affections à ce champ la valeur de notre variable préalablement mise à jour : #V_FIN_PURGE.
• Code Contexte : Purge des sessions exécutées dans ce contexte. Nous le laissons vide pour purger les logs de tous les contextes.
• Nom d’agent : Purge des sessions exécutées par cet agent. Nous le laissons vide pour purger les logs de tous les agents.
• Etat des sessions : Purge des sessions dans l’état spécifié. Nous spécifions « Done » pour supprimées toutes les traces des exécutions qui se sont déroulées correctement.
• Nom d’utilisateur : Purge des sessions lancées par cet utilisateur.
• Filtre sur le nom de session : Permet de préciser un masque de nom de session à purger. Nous précisons « TEST_PROD% » pour purger toutes les sessions de test sur la production.
• Purge des compte-rendus : Indique si les comptes-rendus de scénarios (qui apparaissent sous le noeud exécution de chaque scénario). sont aussi purgés

Il est à noter que tous ces paramètres sont facultatifs. Si aucun d’entre eux n’est spécifié, toutes les données du journal seront alors supprimées.
Remarque : toutes ces manipulations sont également réalisables si vous utilisez encore Sunopsis, la méthode à appeler étant non pas OdiPurgeLog mais SnpsPurgeLog.
Ce package de purge peut alors être appelé à tout moment par d’autres packages, soit par le planificateur de tâches interne à ODI ou encore un ordonnanceur externe.