Show Menu
SUJETS×

Workflow de Nettoyage de la base

Introduction

Le workflow Nettoyage de la base (cleanup), accessible à partir du noeud Administration > Exploitation > Workflows techniques , permet de supprimer les données obsolètes afin d'éviter une croissance exponentielle de la base. Le workflow se déclenche de manière automatique sans intervention de l'utilisateur.

Configuration

Le paramétrage du nettoyage de la base s'effectue à deux niveaux : dans le planificateur du workflow et dans l'assistant de déploiement.

Le planificateur

Pour plus d’informations sur le planificateur, reportez-vous à cette section .
Par défaut, le workflow Nettoyage de la base est paramétré pour se déclencher tous les jours, à 4 heures du matin. Le planificateur vous permet de modifier la fréquence de déclenchement du workflow. Les fréquences disponibles sont les suivantes :
  • Plusieurs fois par jour
  • Quotidien
  • Hebdomadaire
  • Une seule fois
Pour que le workflow Nettoyage de la base puisse se lancer à la date et heure définies dans le planificateur, le moteur de workflow (wfserver) doit être démarré. Si ce n'est pas le cas, le nettoyage de la base se déclenchera au prochain démarrage du moteur de workflow.

L'assistant de déploiement

L' Assistant de déploiement , accessible à partir du menu Outils > Avancé , vous permet de paramétrer la durée pendant laquelle certaines données sont conservées. Les valeurs sont exprimées en jours. Si ces valeurs ne sont pas modifiées, le workflow utilisera les valeurs par défaut.
Les champs de la fenêtre Purge des données correspondent aux options suivantes. Ces options sont utilisées par certaines des tâches exécutées par le workflow Nettoyage de la base :
L'ensemble des tâches exécutées par le workflow Nettoyage de la base sont décrites dans la section qui suit.

Tâches effectuées par le workflow Nettoyage de la base

À la date et à l’heure définies dans le planificateur de workflow (voir Le planificateur ), le moteur de workflow lance le processus de nettoyage de la base. Le Nettoyage de la base se connecte à la base de données et exécute les tâches dans l’ordre indiqué ci-dessous.
Si l'une de ces tâches échoue, les tâches suivantes ne seront pas exécutées. Les requêtes SQL comportant un attribut LIMIT sont exécutées de façon répétée jusqu'à ce que toutes les informations aient été traitées.
Les sections ci-dessous décrivant les tâches effectuées par le workflow Nettoyage de la base sont réservées aux administrateurs de bases de données ou aux utilisateurs familiarisés avec le langage SQL.

Nettoyage des listes à supprimer

La première tâche exécutée par le workflow Nettoyage de la base supprime tous les groupes avec l’attribut deleteStatus != 0 du NmsGroup . Les enregistrements liés à ces groupes et qui existent dans d’autres tables sont également supprimés.
  1. Les listes à supprimer sont récupérées à l'aide de la requête SQL suivante :
    SELECT iGroupId, sLabel, iType FROM NmsGroup WHERE iDeleteStatus <> 0 OR tsExpirationDate <= GetDate() 
    
    
  2. Chaque liste possède plusieurs liens vers d'autres tables. Tous ces liens sont supprimés en masse à l'aide de la requête suivante :
    DELETE FROM $(relatedTable) WHERE iGroupId=$(l) IN (SELECT iGroupId FROM $(relatedTable) WHERE iGroupId=$(l) LIMIT 5000) 
    
    
    $(relatedTable) est une table liée à NmsGroup et $(l) est l’identifiant de la liste.
  3. Lorsque la liste est de type 'Liste', la table associée est supprimée à l'aide de la requête suivante :
    DROP TABLE grp$(l)
    
    
  4. Chaque liste récupérée par l'opération de type Select est supprimée à l'aide de la requête suivante :
    DELETE FROM NmsGroup WHERE iGroupId=$(l) 
    
    
    $(l) est l’identifiant de la liste

Nettoyage des diffusions à supprimer ou à recycler

Cette tâche purge toutes les diffusions à supprimer ou à recycler.
  1. Le workflow Nettoyage de la base sélectionne toutes les diffusions pour lesquelles le champ deleteStatus a la valeur Oui ou Recyclé et dont la date de suppression est antérieure à la période définie dans le champ Diffusions supprimées ( NmsCleanup_RecycledDeliveryPurgeDelay) de l’assistant de déploiement. Voir à ce sujet Assistant de déploiement . Cette période est calculée par rapport à la date actuelle du serveur.
  2. La tâche sélectionne ensuite, pour chaque serveur de mid-sourcing, la liste des diffusions à supprimer.
  3. Le workflow Nettoyage de la base supprime les logs de diffusion, les pièces jointes, les informations de pages miroir et toute autre donnée associée.
  4. Avant la suppression définitive de la diffusion, le workflow purge les informations associées dans les tables suivantes :
    • Dans la table des exclusions de diffusion ( NmsDlvExclusion ), la requête suivante est utilisée :
      DELETE FROM NmsDlvExclusion WHERE iDeliveryId=$(l)
      
      
      $(l) est l’identifiant de la diffusion.
    • Dans la table des coupons ( NmsCouponValue ), la requête suivante est utilisée (avec des suppressions en masse) :
      DELETE FROM NmsCouponValue WHERE iMessageId IN (SELECT iMessageId FROM NmsCouponValue WHERE EXISTS (SELECT B.iBroadLogId FROM $(BroadLogTableName) B WHERE B.iDeliveryId = $(l) AND B.iBroadLogId = iMessageId ) LIMIT 5000)
      
      
      $(l) est l’identifiant de la diffusion.
    • Dans les tables de logs de diffusion ( NmsBroadlogXxx ), les suppressions en masse sont exécutées par groupes de 20 000 enregistrements.
    • Dans les tables de propositions d’offres ( NmsPropositionXxx ), les suppressions en masse sont exécutées par groupes de 20 000 enregistrements.
    • Dans les tables de logs de tracking ( NmsTrackinglogXxx ), les suppressions en masse sont exécutées par groupes de 20 000 enregistrements.
    • Dans la table de fragments de diffusion ( NmsDeliveryPart ), les suppressions en masse sont exécutées par groupes de 500 000 enregistrements. Cette table contient des informations de personnalisation relatives aux messages restants à diffuser.
    • Dans la table des fragments de données des pages miroir ( NmsMirrorPageInfo ), les suppressions en masse sont exécutées par groupes de 20 000 enregistrements pour les fragments de diffusion arrivés à expiration, mais aussi terminés ou annulés. Cette table contient des informations de personnalisation relatives à tous les messages utilisés pour générer les pages miroir.
    • Dans la table de recherche des pages miroir ( NmsMirrorPageSearch ), les suppressions en masse sont exécutées par groupes de 20 000 enregistrements. Cette table est un index de recherche qui donne accès aux informations de personnalisation stockées dans la table NmsMirrorPageInfo .
    • Dans la table de log de traitement par lot ( XtkJobLog ), les suppressions en masse sont exécutées par lots de 20 000 enregistrements. Cette table contient le log des diffusions à supprimer.
    • Dans la table de tracking des URL d'une diffusion ( NmsTrackingUrl ), la requête suivante est utilisée :
      DELETE FROM NmsTrackingUrl WHERE iDeliveryId=$(l)
      
      
      $(l) est l’identifiant de la diffusion.
      Cette table contient les URL présentes dans les diffusions à supprimer afin de permettre leur tracking.
  5. La diffusion est ensuite supprimée de la table des diffusions ( NmsDelivery ) :
    DELETE FROM NmsDelivery WHERE iDeliveryId = $(l)
    
    
    $(l) est l’identifiant de la diffusion.

Diffusions utilisant le mid-sourcing

Le workflow Nettoyage de la base supprime également les diffusions sur le(s) serveur(s) de mid-sourcing.
  1. Pour cela, le workflow vérifie que chaque diffusion est inactive (en se basant sur son état). Si une diffusion est active, elle sera interrompue avant d'être supprimée. La vérification est effectuée en exécutant la requête suivante :
    SELECT iState FROM NmsDelivery WHERE iDeliveryId = $(l) AND iState <> 100;
    
    
    $(l) est l’identifiant de la diffusion.
  2. Si l'état a pour valeur Démarrage en attente , En cours , Reprise en attente , Reprise en cours , Pause demandée , Pause en cours , ou En pause (valeurs 51, 55, 61, 62, 71, 72, 75), la diffusion est alors stoppée et la tâche procède à la purge des informations associées.

Nettoyage des diffusions ayant expiré

Cette tâche interrompt les diffusions dont la période de validité a expiré.
  1. Le workflow Nettoyage de la base crée la liste des diffusions ayant expiré. Cette liste inclut toutes les diffusions ayant expiré dont l'état est différent de Terminé , ainsi que les diffusions récemment arrêtées avec plus de 10000 messages non traités. La requête suivante est utilisée :
    SELECT iDeliveryId, iState FROM NmsDelivery WHERE iDeleteStatus=0 AND iIsModel=0 AND iDeliveryMode=1 AND ( (iState >= 51 AND iState < 85 AND tsValidity IS NOT NULL AND tsValidity < $(currentDate) ) OR (iState = 85 AND DateMinusDays(15) < tsLastModified AND iToDeliver - iProcessed >= 10000 ))
    
    
    delivery mode 1 correspond au mode Envoi en masse , state 51 correspond à l’état Démarrage en attente , state 85 correspond à l’état Arrêt , et le nombre maximum de logs de diffusion mis à jour en masse sur le serveur de diffusion est de 10 000.
  2. Le workflow inclut ensuite la liste des diffusions qui ont récemment expiré et qui utilisent le mid-sourcing. Les diffusions pour lesquelles les logs de diffusion n'ont pas encore été récupérés depuis serveur de mid-sourcing ne sont pas incluses.
    La requête suivante est utilisée :
    SELECT iDeliveryId, tsValidity, iMidRemoteId, mData FROM NmsDelivery WHERE (iDeliveryMode = 4 AND (iState = 85 OR iState = 95) AND tsValidity IS NOT NULL AND (tsValidity < SubDays(GetDate() , 15) OR tsValidity < $(DateOfLastLogPullUp)) AND tsLastModified > SubDays(GetDate() , 15))
    
    
  3. La requête suivante est utilisée pour détecter si le compte externe est toujours actif, afin de pouvoir filtrer les diffusions selon la date :
    SELECT iExtAccountId FROM NmsExtAccount WHERE iActive<>0 AND sName=$(providerName)
    
    
  4. Dans la liste de diffusions ayant expiré, les logs de diffusion dont le statut est En attente passent au statut Envoi annulé , et toutes les diffusions de cette liste passent au statut Terminé .
    Les requêtes utilisées sont les suivantes :
    UPDATE $(BroadLogTableName) SET tsLastModified=$(curdate), iStatus=7, iMsgId=$(bl) WHERE iDeliveryId=$(dl) AND iStatus=6
    
    
    $(curdate) est la date courante du serveur de la base de données, $(bl) est l’identifiant du message des logs de diffusion, $(dl) est l’identifiant de la diffusion, delivery status 6 correspond à l’état En attente et delivery status 7 correspond à l’état Envoie annulé .
    UPDATE NmsDelivery SET iState = 95, tsLastModified = $(curdate), tsBroadEnd = tsValidity WHERE iDeliveryId = $(dl)
    
    
    delivery state 95 correspond à l’état Terminé et $(dl) est l’identifiant de la diffusion.
  5. Tous les fragments ( deliveryParts ) des diffusions obsolètes sont supprimés et tous les fragments obsolètes des diffusions de notification toujours en cours sont supprimés. Une suppression en masse est utilisée pour ces deux tâches.
    Les requêtes utilisées sont les suivantes :
    DELETE FROM NmsDeliveryPart WHERE iDeliveryPartId IN (SELECT iDeliveryPartId FROM NmsDeliveryPart WHERE iDeliveryId IN (SELECT iDeliveryId FROM NmsDelivery WHERE iState=95 OR iState=85) LIMIT 5000)
    
    
    DELETE FROM NmsDeliveryPart WHERE iDeliveryPartId IN (SELECT iDeliveryPartId FROM NmsDeliveryPart WHERE tsValidity < $(curDate) LIMIT 500000)
    
    
    delivery state 95 correspond à l’état Terminé , delivery state 85 correspond à l’état Arrêt et $(curDate) est la date courante du serveur.

Nettoyage des pages miroir

Cette tâche supprime les ressources web (pages miroir) utilisées par les diffusions.
  1. Tout d'abord, la liste des diffusions à purger est récupérée à l'aide de la requête suivante :
    SELECT iDeliveryId, iNeedMirrorPage FROM NmsDelivery WHERE iWebResPurged = 0 AND tsWebValidity IS NOT NULL AND tsWebValidity < $(curdate)"
    
    
    $(curDate) est la date courante du serveur.
  2. La table NmsMirrorPageInfo est ensuite purgée, si nécessaire, à l'aide de l'identifiant de la diffusion récupéré précédemment. Une suppression en masse est utilisée pour générer les requêtes suivantes :
    DELETE FROM NmsMirrorPageInfo WHERE iMirrorPageInfoId IN (SELECT iMirrorPageInfoId FROM NmsMirrorPageInfo WHERE iDeliveryId = $(dl)) LIMIT 5000)
    
    
    DELETE FROM NmsMirrorPageSearch WHERE iMessageId IN (SELECT iMessageId FROM NmsMirrorPageSearch WHERE iDeliveryId = $(dl)) LIMIT 5000)
    
    
    $(dl) est l’identifiant de la diffusion.
  3. Un log est ensuite ajouté au journal de la diffusion.
  4. Les diffusions purgées sont ensuite identifiées afin de ne pas avoir à les retraiter par la suite. La requête suivante est exécutée :
    UPDATE NmsDelivery SET iWebResPurged = 1 WHERE iDeliveryId IN ($(strIn))
    
    
    $(strln) est la liste des identifiants de diffusion.

Nettoyage des tables de travail

Cette tâche supprime, dans la base de données, les tables de travail correspondant aux diffusions dont l'état est En édition , Stoppé ou Supprimée .
  1. La liste des tables dont le nom commence par wkDlv_ est récupérée en premier lieu avec la requête suivante (postgresql) :
    SELECT relname FROM pg_class WHERE relname LIKE Lower('wkDlv_') ESCAPE E'\\' AND relkind IN ('r','v') AND pg_get_userbyid(relowner)<>'postgres'
    
    
  2. Les tables utilisées par des workflows en cours sont ensuite exclues. Pour cela, la liste des diffusions en cours est récupérée à l'aide de la requête suivante :
    SELECT iDeliveryId FROM NmsDelivery WHERE iDeliveryId<>0 AND iDeleteStatus=0 AND iState NOT IN (0,85,100);
    
    
    où 0 est la valeur correspondant à l'état de diffusion En édition , 85 correspond à l'état Stoppé et 100 correspond à l'état Supprimée .
  3. Les tables qui ne sont plus utilisées sont supprimées à l'aide de la requête suivante :
    DROP TABLE wkDlv_15487_1;
    
    

Nettoyage des rejets générés par les imports

Cette étape permet de supprimer les enregistrements dont les données n'ont pas été toutes traitées par l'import.
  1. Une suppression en masse est exécutée sur la table XtkReject avec la requête suivante :
    DELETE FROM XtkReject WHERE iRejectId IN (SELECT iRejectId FROM XtkReject WHERE tsLog < $(curDate)) LIMIT $(l))
    
    
    $(curDate) est la date courante du serveur à laquelle est soustraite la période définie pour l’option NmsCleanup_RejectsPurgeDelay (voir Assistant de déploiement ) et $(l) est le nombre maximum d’enregistrements à supprimer en masse.
  2. Tous les rejets orphelins sont alors supprimés à l'aide de la requête suivante :
    DELETE FROM XtkReject WHERE iJobId NOT IN (SELECT iJobId FROM XtkJob)
    
    

Nettoyage des instances de workflow

Cette tâche purge chaque instance de workflow à l’aide de son identifiant ( lWorkflowId ) et de son historique ( lHistory ). Elle supprime les tables inactives en exécutant à nouveau la tâche de nettoyage de la table de travail. Le nettoyage supprime également toutes les tables de travail orphelines (wkf% et wkfhisto%) des workflows supprimés.
La périodicité de la purge de l’historique est définie pour chaque workflow dans le champ Jours d’historique (valeur par défaut de 30 jours). Ce champ se situe sur l’onglet Exécution des propriétés du workflow. Voir à ce sujet cette section .
  1. Pour récupérer la liste des workflows à supprimer, la requête suivante est utilisée :
    SELECT iWorkflowId, iHistory FROM XtkWorkflow WHERE iWorkflowId<>0
    
    
  2. Cette requête génère la liste des workflows qui seront utilisés pour supprimer tous les logs associés, les tâches terminées et les évènements terminés, à l'aide des requêtes suivantes :
    DELETE FROM XtkWorkflowLog WHERE iWorkflowId=$(lworkflow) AND tsLog < DateMinusDays($(lhistory))
    
    
    DELETE FROM XtkWorkflowTask WHERE iWorkflowId=$(lworkflow) AND iStatus<>0 AND tsCompletion < DateMinusDays($(lhistory)) 
    
    
    DELETE FROM XtkWorkflowEvent WHERE iWorkflowId=$(l) AND iStatus>2 AND tsProcessing < DateMinusDays($(lHistory))
    
    
    $(workflow) est l’identifiant du workflow et $(history) est l’identifiant de l’historique.
  3. Toutes les tables inutilisées sont alors supprimées. Pour cela, toutes les tables sont collectées à l'aide d'un masque de type wkf% utilisant la requête suivante (postgresql) :
    SELECT relname FROM pg_class WHERE relname LIKE Lower('wkf%') ESCAPE E'\\' AND relkind IN ('r','v') AND pg_get_userbyid(relowner)<>'postgres'
    
    
  4. Puis, toutes les tables utilisées par une instance de workflow en cours sont exclues. La liste des workflows actifs est récupérée à l'aide de la requête suivante :
    SELECT iWorkflowId FROM XtkWorkflow WHERE iWorkflowId<>0 AND iState<>20
    
    
  5. Chaque identifiant de workflow est ensuite récupéré afin de trouver le nom des tables utilisées par des workflows en cours. Ces noms sont exclus de la liste de tables récupérée précédemment.
  6. Les tables d'historique des activités de type "requête incrémentale" sont exclues, à l'aide des requêtes suivantes :
    SELECT relname FROM pg_class WHERE relname LIKE Lower('wkfhisto%') ESCAPE E'\\' AND relkind IN ('r','v') AND pg_get_userbyid(relowner)<>'postgres'
    
    
    SELECT iWorkflowId FROM XtkWorkflow WHERE iWorkflowId IN ($(strCondition))
    
    
    $(strcondition) est la liste des tables correspondant au masque wkfhisto% .
  7. Les tables restantes sont supprimées à l'aide de la requête suivante :
    DROP TABLE wkf15487_12;
    
    

Nettoyage des logins de workflows

Cette tâche supprime les logins de workflows à l'aide de la requête suivante :
DELETE FROM XtkWorkflowLogin WHERE iWorkflowId NOT IN (SELECT iWorkflowId FROM XtkWorkflow)

Nettoyage des tables de travail orphelines

Cette tâche supprime les tables de travail orphelines liées à des groupes. La table NmsGroup stocke les groupes à nettoyer (ceux dont le type est différent de 0). Le nom des tables de travail a pour préfixe grp . Pour identifier les groupes à nettoyer, la requête suivante est utilisée :
SELECT iGroupId FROM NmsGroup WHERE iType>0"

Nettoyage des visiteurs

Cette tâche supprime les enregistrements obsolètes de la table des visiteurs à l’aide de la suppression en masse. Les enregistrements obsolètes sont ceux pour lesquels la dernière modification est antérieure à la période de conservation définie dans l’assistant de déploiement (voir Assistant de déploiement ). La requête suivante est utilisée :
DELETE FROM NmsVisitor WHERE iVisitorId IN (SELECT iVisitorId FROM NmsVisitor WHERE iRecipientId = 0 AND tsLastModified < AddDays(GetDate(), -30) AND iOrigin = 0 LIMIT 20000)

$(tsDate) est la date courante du serveur à laquelle est soustraite la période définie pour l'option NmsCleanup_VisitorPurgeDelay .

Nettoyage des NPAI

Cette tâche permet la suppression, dans la table NmsAddress , des enregistrements correspondant à des adresses valides. La requête suivante est utilisée pour effectuer une suppression en masse :
DELETE FROM NmsAddress WHERE iAddressId IN (SELECT iAddressId FROM NmsAddress WHERE iStatus=2 AND tsLastModified < $(tsDate1) AND tsLastModified >= $(tsDate2) LIMIT 5000)

status 2 correspond à l’état Valide , $(tsDate1) est la date courante du serveur et $(tsDate2) correspond à l’option NmsCleanup_LastCleanup .

Nettoyage des abonnements

Cette tâche purge, dans la table NmsSubscription , les abonnements qui ont été supprimés par l'utilisateur, à l'aide d'une suppression en masse. La requête suivante est utilisée :
DELETE FROM NmsSubscription WHERE iDeleteStatus <>0

Nettoyage des logs de tracking

Cette tâche supprime les enregistrements obsolètes du tracking et des tables de log de tracking web. Les enregistrements obsolètes sont ceux qui sont antérieurs à la période de conservation définie dans l’assistant de déploiement (voir Assistant de déploiement ).
  1. Tout d'abord, la liste des tables de logs de tracking est récupérée à l'aide de la requête suivante :
    SELECT distinct(sTrackingLogSchema) FROM NmsDeliveryMapping WHERE sTrackingLogSchema IS NOT NULL;
    
    
  2. Une suppression en masse est utilisée pour purger toutes les tables dans la liste des tables récupérées précédemment. La requête utilisée est la suivante :
    DELETE FROM XtkTrackingLogRcp WHERE iTrackingLogId IN (SELECT iTrackingLogId FROM XtkTrackingLogRcp WHERE tsLog < $(tsDate) LIMIT 5000) 
    
    
    $(tsDate) est la date courante du serveur à laquelle est soustraite la période définie pour l’option NmsCleanup_TrackingLogPurgeDelay .
  3. La table des statistiques de tracking est purgée à l'aide d'une suppression en masse. La requête suivante est utilisée :
    DELETE FROM NmsTrackingStats WHERE iTrackingStatsId IN (SELECT iTrackingStatsId FROM NmsTrackingStats WHERE tsStart < $(tsDate) LIMIT 5000) 
    
    
    $(tsDate) est la date courante du serveur à laquelle est soustraite la période définie pour l’option NmsCleanup_TrackingStatPurgeDelay .

Nettoyage des logs de diffusion

Cette tâche permet de purger les logs de diffusion stockés dans différentes tables.
  1. Pour cela, la liste des schémas de logs de diffusion est récupérée à l'aide de la requête suivante :
    SELECT distinct(sBroadLogSchema) FROM NmsDeliveryMapping WHERE sBroadLogSchema IS NOT NULL UNION SELECT distinct(sBroadLogExclSchema) FROM NmsDeliveryMapping WHERE sBroadLogExclSchema IS NOT NULL
    
    
  2. Dans le cas de l'utilisation du mid-sourcing, la table NmsBroadLogMid n'est pas référencée dans les mappings de diffusion. Le schéma nms:broadLogMid est alors ajouté à la liste récupérée par la requête précédente.
  3. Le workflow Nettoyage de la base procède ensuite à la purge des enregistrements obsolètes dans les tables récupérées précédemment. La requête suivante est utilisée :
    DELETE FROM $(tableName) WHERE iBroadLogId IN (SELECT iBroadLogId FROM $(tableName) WHERE tsLastModified < $(option) LIMIT 5000) 
    
    
    $(tableName) est le nom de chaque table dans la liste de schémas, et $(option) est la date définie pour l’option NmsCleanup_BroadLogPurgeDelay (voir Assistant de déploiement ).
  4. Le workflow vérifie enfin si la table NmsProviderMsgId existe. Si c'est le cas, tous ses enregistrements obsolètes sont supprimés à l'aide de la requête suivante :
    DELETE FROM NmsProviderMsgId WHERE iBroadLogId IN (SELECT iBroadLogId FROM NmsProviderMsgId WHERE tsCreated < $(option) LIMIT 5000)
    
    
    $(option) correspond à la date définie pour l’option NmsCleanup_BroadLogPurgeDelay (voir Assistant de déploiement ).

Nettoyage de la table NmsEmailErrorStat

Cette tâche nettoie la table NmsEmailErrorStat . Le programme principal ( coalesceErrors ) définit deux dates :
  • Date de début : date du prochain traitement correspondant à l'option NmsLastErrorStatCoalesce ou correspondant à la date la plus récente dans la table.
  • Date de fin : date courante du serveur.
Si la date de début est supérieure ou égale à la date de fin, aucun traitement n'a lieu. Le message coalesceUpToDate apparaît alors.
Si la date de début est inférieure à la date de fin, la table NmsEmailErrorStat est nettoyée.
Le nombre total d'erreurs dans la table NmsEmailErrorStat , entre les dates de début et de fin, est récupéré à l'aide de la requête suivante :
"SELECT COUNT(*) FROM NmsEmailErrorStat WHERE tsDate>= $(start) AND tsDate< $(end)"

$end et $start sont les dates de début et de fin définies précédemment.
Si le total est supérieur à 0 :
  1. La requête suivante est exécutée afin de ne conserver que les erreurs situées au-delà d'un certain seuil (égal à 20) :
    "SELECT iMXIP, iPublicId, SUM(iTotalConnections), SUM(iTotalErrors), SUM(iMessageErrors), SUM(iAbortedConnections), SUM(iFailedConnections), SUM(iRefusedConnections), SUM(iTimeoutConnections) FROM NmsEmailErrorStat WHERE tsDate>=$(start ) AND tsDate<$(end ) GROUP BY iMXIP, iPublicId HAVING SUM(iTotalErrors) >= 20"
    
    
  2. Le message coalescingErrors apparaît.
  3. Une nouvelle connexion est créée pour supprimer toutes les erreurs survenues entre les dates de début et de fin. La requête suivante est utilisée :
    "DELETE FROM NmsEmailErrorStat WHERE tsDate>=$(start) AND tsDate<$(end)"
    
    
  4. Chaque erreur est enregistrée dans la table NmsEmailErrorStat à l'aide de la requête suivante :
    "INSERT INTO NmsEmailErrorStat(iMXIP, iPublicId, tsDate, iTotalConnections, iTotalErrors, iTimeoutConnections, iRefusedConnections, iAbortedConnections, iFailedConnections, iMessageErrors) VALUES($(lmxip ), $(lpublicId ), $(tsstart ), $(lconnections ), $(lconnectionErrors ),$(ltimeoutConnections ), $(lrefusedConnections ), $(labortedConnections ), $(lfailedConnections ), $(lmessageErrors))"
    
    
    où chaque variable correspond à une valeur récupérée par la requête précédente.
  5. La variable start est mise à jour avec les valeurs de la date du traitement précédent afin de terminer la boucle.
La boucle et la tâche s'arrêtent.
Deux tâches sont ensuite exécutées : le nettoyage des tables NmsEmailError et cleanupNmsMxDomain .

Nettoyage de la table NmsEmailError

La requête suivante est utilisée :
DELETE FROM NmsEmailError WHERE iMXIP NOT IN (SELECT DISTINCT iMXIP FROM NmsEmailErrorStat)

Cette requête supprime, dans la table NmsEmailError , toutes les lignes n'ayant aucun enregistrement associé dans la table NmsEmailErrorStat .

Nettoyage de la table NmsMxDomain

La requête suivante est utilisée :
DELETE FROM NmsMxDomain WHERE iMXIP NOT IN (SELECT DISTINCT iMXIP FROM NmsEmailErrorStat)

Cette requête supprime, dans la table NmsMxDomain , toutes les lignes n'ayant aucun enregistrement associé dans la table NmsEmailErrorStat .

Nettoyage des propositions

Si le module Interaction est installé, cette tâche est exécutée afin de purger les tables NmsPropositionXxx .
La liste des tables de propositions est récupérée et une suppression en masse est exécutée sur chacune d'entre elles, à l'aide de la requête suivante :
DELETE FROM NmsPropositionXxx WHERE iPropositionId IN (SELECT iPropositionId FROM NmsPropositionXxx WHERE tsLastModified < $(option) LIMIT 5000) 

$(option) est la date définie pour l’option NmsCleanup_PropositionPurgeDelay (voir Assistant de déploiement ).

Nettoyage des tables de simulation

Cette tâche nettoie les tables de simulation orphelines (qui ne sont plus associées à une simulation d'offre ou une simulation de diffusion).
  1. Pour récupérer la liste des simulations à nettoyer, la requête suivante est utilisée :
    SELECT iSimulationId FROM NmsSimulation WHERE iSimulationId<>0
    
    
  2. Le nom des tables à supprimer est composé du préfixe wkSimu_ suivi de l'identifiant de la simulation (par exemple : wkSimu_456831_aggr ). La requête suivante est utilisée :
    DROP TABLE wkSimu_456831_aggr
    
    

Nettoyer le Suivi

La requête suivante est utilisée :
DELETE FROM XtkAudit WHERE tsChanged < $(tsDate)

$(tsDate) est la date courante du serveur à laquelle est soustraite la période définie pour l’option XtkCleanup_AuditTrailPurgeDelay .

Nettoyer Nmsaddress

La requête suivante est utilisée :
DELETE FROM NmsAddress WHERE iAddressId IN (SELECT iAddressId FROM NmsAddress WHERE iStatus=STATUS_QUARANTINE AND tsLastModified < $(NmsCleanup_AppSubscriptionRcpPurgeDelay + 5d) AND iType IN (MESSAGETYPE_IOS, MESSAGETYPE_ANDROID ) LIMIT 5000)

Cette requête supprime toutes les entrées relatives à iOS et Android.

Mise à jour des statistiques et optimisation du stockage

L’option XtkCleanup_NoStats permet de contrôler le comportement de l’étape d’optimisation du stockage du workflow de nettoyage.
Si l’option XtkCleanup_NoStats n’existe pas ou a pour valeur 0, l’optimisation du stockage est exécutée en mode verbose (VACUUM VERBOSE ANALYZE) sur PostgreSQL et les statistiques sont mises à jour sur toutes les autres bases de données. Pour vous assurer que cette commande est exécutée, vérifiez les logs PostgreSQL. VACUUM génère des lignes au format suivant : INFO: vacuuming "public.nmsactivecontact" et ANALYZE génèrent des lignes au format suivant : INFO: analyzing "public.nmsactivecontact" .
Si la valeur de l’option est 1, la mise à jour des statistiques n’est exécutée sur aucune base de données. La ligne de log suivante apparaît dans les logs des workflows : Option 'XtkCleanup_NoStats' is set to '1' .
Si la valeur de l’option est 2, l’analyse du stockage en mode verbose (ANALYZE VERBOSE) sera exécutée sur PostgreSQL et les statistiques seront mises à jour sur toutes les autres bases de données. Pour vous assurer que cette commande est exécutée, vérifiez les logs PostgreSQL. ANALYZE génère des lignes au format suivant : INFO: analyzing "public.nmsactivecontact" .

Nettoyage des abonnements (NMAC)

Cette tâche supprime les abonnements liés à des services ou à des applications mobiles supprimés.
Pour récupérer la liste des schémas des broadlogs, la requête suivante est utilisée :
SELECT distinct(sBroadLogSchema) FROM NmsDeliveryMapping WHERE sBroadLogSchema IS NOT NULL

La tâche récupère ensuite les noms des tables associées au lien appSubscription et supprime ces tables.
Ce processus de nettoyage supprime également toutes les entrées pour lesquelles idisabled = 1 n’a pas été mis à jour depuis l’heure définie dans l’option NmsCleanup_AppSubscriptionRcpPurgeDelay .

Nettoyage des informations de session

Cette tâche nettoie les informations de la table sessionInfo , la requête suivante est utilisée :
 DELETE FROM XtkSessionInfo WHERE tsexpiration < $(curdate) 

Nettoyage des événements ayant expiré

Cette tâche nettoie les événements reçus et stockés sur les instances d'exécution et les événements historisés sur une instance de pilotage.

Nettoyage des réactions

Cette tâche nettoie les réactions (table NmsRemaMatchRcp ) dont les hypothèses ont été supprimées sont elles-mêmes supprimées.