Campaign Classic - Query incremental seleciona todos os registros em vez de somente os novos

Descrição

O cliente tem vários queries incrementais que não estão funcionando como esperado. Em vez de apenas pegar novos registros desde a última execução, eles estão coletando todos os registros de cada vez - como um Query atividade .

Resolução

O culpado é o Limpeza fluxo de trabalho.

O Query incremental O fluxo de trabalho funciona desta forma:

  1. Mantenha uma tabela de histórico com resultados de iterações anteriores.
  2. Busque TODAS as linhas do query de destino.
  3. Filtrar todas as linhas presentes na tabela de histórico
  4. Adicione os resultados restantes na tabela de histórico para a próxima filtragem de iteração.

Portanto, esse nome da tabela de trabalho do histórico é da seguinte notação:

wkfhistoworkflowid activityName_

Agora, para workflowIDs 0 (para clientes em que a variável xtknewid permite sequências negativas), vemos que é na verdade:

wkfhisto(uint)workflowid activityName_

Embora isso esteja certo para a execução do workflow.

Assim, por exemplo, a atividade incremental incremental1 da ID do fluxo de trabalho=-1 criará uma tabela wkfhisto4294967295_incremental1.

O que falta é o Limpeza fluxo de trabalho.

Aqui, temos um código que tenta excluir tabelas de trabalho de fluxos de trabalho excluídos.

Um código dedicado aqui lista todas as tabelas wkfhisto*, extrai o workflowId de seus nomes (da convenção acima) e exclui todos, exceto aqueles cujas worklowIDs são encontradas na tabela xtkworkflow.

No entanto, ela não tem a uint parte.

Portanto, ele tenta procurar um fluxo de trabalho com ID 4294967295 em vez de reenviá-lo para int. Como esse workflow não foi encontrado, esta tabela é excluída. Na próxima vez, quando esse workflow for executado, a variável Query incremental A atividade do não encontra uma tabela de histórico existente e a cria pensando nisso como a primeira execução de sempre.

Correção:

A correção para esse problema está disponível na versão 20.1.1 do Adobe Campaign Classic (build 9122 e posteriores).

Soluções alternativas que os clientes podem usar:

Solução 1: Pare o workflow de limpeza e execute-o intermitentemente para limpar o Banco de Dados e o HDD até que a correção seja tomada e disponibilizada. Não recomendado se você não tiver uma atualização planejada.

Solução 2: Suponha que a variável Query incremental A atividade é afetada e soluciona isso fazendo a mesma coisa que a variável Query incremental O faz criando um schema persistente para manter o conteúdo da tabela do histórico. Use uma combinação de Query e Atualizar dados para imitar o comportamento. Isso precisará ser feito para todos os workflows que exigem o query incremental.

Solução alternativa 3:  Suponha que a variável Query incremental A atividade é afetada e soluciona isso adicionando um campo de auditoria (tsCreated/tsLastModified) ao schema em questão. Seu query incremental será convertido em uma atividade de query normal com uma cláusula where como tscreated GetDate().

Solução alternativa 4:

  • Crie uma nova sequência xtknewworkflowid e inicialize-a em algo que esteja longe dos intervalos workflowId atuais.
  • Altere o esquema xtkworkflow para usar isso pkSequence
  • Solicite ao cliente que clone todos os workflows afetados e exclua os originais.
  • Quando o cliente estiver pronto para uma atualização, remova essa correção revertendo para xtknewId para a criação do workflow (para evitar surpresas indesejadas).

Nesta página