La requête incrémentielle récupère tous les enregistrements au lieu de seulement les nouveaux.

Découvrez comment résoudre le problème Adobe Campaign Classic où les requêtes incrémentielles ne fonctionnent pas comme prévu.

Description description

Environnement

Campaign Classic

Problème/Symptômes

Les requêtes incrémentielles ne fonctionnent pas comme prévu. Au lieu de ne sélectionner que de nouveaux enregistrements depuis leur dernière exécution, ils récupèrent tous les enregistrements à chaque fois comme une activité de requête normale.

Résolution resolution

Ce problème a été corrigé dans la version 20.1.1 de Adobe Campaign Classic (version 9122 et versions ultérieures).

Contours que les utilisateurs peuvent utiliser :

Solution 1 : arrêtez le workflow de nettoyage et exécutez-le par intermittence pour nettoyer la base de données et le disque dur jusqu’à ce que le correctif soit pris et disponible. Il n’est pas recommandé si vous n’avez pas prévu de mise à niveau.

Solution 2 : supposons que l’activité de requête incrémentale soit affectée. Pour contourner ce problème, procédez de la même manière que la requête incrémentale en créant un schéma persistant destiné à contenir le contenu de la table d’historique. Utilisez une combinaison d'activités de requête et de mise à jour de données pour imiter le comportement. Cela doit être effectué pour tous les workflows nécessitant la requête incrémentale.

Solution 3 :  Supposons que l’activité de requête incrémentale soit affectée. Pour contourner ce problème, ajoutez un champ d’audit tsCreated/tsLastModified au schéma en question. Votre requête incrémentale sera ensuite convertie en une activité de requête normale avec une clause où telle que tscreated< GetDate().

Solution 4 :

  1. Créez une nouvelle séquence xtknewworkflowid et initialisez-la à un élément éloigné des plages d’ID de workflow actuelles.
  2. Modifiez le schéma xtkworkflow pour utiliser cet pkSequence.
  3. Demandez à l’utilisateur de cloner tous les workflows concernés et de supprimer les workflows d’origine.
  4. Une fois que l’utilisateur est prêt pour une mise à niveau, supprimez ce correctif en revenant à xtknewId pour la création du workflow (afin d’éviter les surprises indésirables).

Cause
Le problème principal est le workflow de nettoyage.

Le workflow de requête incrémentale fonctionne de la manière suivante :

  1. Conserve une table d'historique avec les résultats des itérations précédentes.
  2. Récupère toutes les lignes de la requête cible.
  3. Filtre toutes les lignes présentes dans le tableau d’historique
  4. Ajoute les résultats restants dans le tableau history pour le filtrage de l’itération suivante.

Le nom de la table de travail history est de la forme suivante :
wkfhisto<workflowid> <activityName>_

Désormais, pour les workflowID < 0 (pour les utilisateurs où xtknewid autorise des séquences négatives), nous constatons que c’est en fait :

wkfhisto<(uint)workflowid> <activityName>_

Although this is okay for workflow execution.

So, for example, the incremental activity incremental1 of workflow ID=-1 will create a table wkfhisto4294967295_incremental1.

The thing which is missed is the CleanUp workflow.

Here, we have a code that tries to delete worktables of deleted workflows.

A dedicated code here lists all the wkfhisto tables, extracts the workflowId from their names (from the above convention), and deletes them all except the ones whose worklowIDs are found in the xtkworkflow table.

However, it misses the uint part.

So, it tries to look up a workflow with ID 4294967295 instead of casting this back to int. Since this workflow is not found, this table is deleted. Next time, when this workflow runs, the incremental query activity does not find an existing history table and creates it thinking of this as the first run ever.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f