Como evitar fluxos de trabalho duplicados

  • Versão de lançamento: Zurich
  • Atualizado 31 de jul. de 2025
  • 2 min. de leitura
  • Os conjuntos de atualizações gerenciam o estado publicado de todas as versões de um fluxo de trabalho antes de confirmar a versão em uma instância local.

    A última versão de um fluxo de trabalho confirmada como inserção ou atualização usando um conjunto de atualizações se torna a versão publicada no momento, seja qual for a sequência de publicação das versões.

    Confirmação de um fluxo de trabalho em um conjunto de atualizações

    Siga as etapas nesta página para confirmar um fluxo de trabalho em um conjunto de atualizações.

    Procedimento

    1. Fluxo de trabalho A — a versão 1 é criada e publicada no conjunto de atualizações A.
    2. O conjunto de atualizações A foi concluído e migrado para uma instância local.
    3. Quando o conjunto de atualizações é confirmado, o sistema define todas as versões anteriores do fluxo de trabalho A como publicado = falso.

      Na primeira migração, não há versões anteriores.

    4. Fluxo de trabalho A — a versão 1 se torna a única versão publicada do fluxo de trabalho.

    Exemplo de migração de conjunto de atualizações

    Não é possível ter várias versões publicadas como resultado de confirmações de conjunto de atualizações. No entanto, isso não elimina o risco e deve-se ter cuidado ao migrar conjuntos de atualizações.

    Considere este exemplo:
    1. Fluxo de trabalho A — a versão 1 é migrada e confirmada para a instância de produção.
    2. O conjunto de atualizações B é criado.
    3. O conjunto de atualizações C é criado.
    4. Fluxo de trabalho A — a versão 2 é publicada no conjunto de atualizações B.

      Um registro de atualização do cliente é adicionado ao conjunto de atualizações B com a carga da versão 2.

      Um registro de atualização do cliente é adicionado ao conjunto de atualizações B com a versão 1 do fluxo de trabalho não publicada.

    5. O conjunto de atualizações B é concluído.
    6. Fluxo de trabalho A — a versão 3 é publicada no conjunto de atualizações C.

      Um registro de atualização do cliente é adicionado ao conjunto de atualizações C com a carga da versão 3.

      Um registro de atualização do cliente é adicionado ao conjunto de atualizações C com a versão 2 do fluxo de trabalho não publicada.

    7. O conjunto de atualizações C é concluído.
    8. O conjunto de atualizações C é migrado e confirmado para a instância de produção.

      Fluxo de trabalho A — a versão 1 é definida como não publicada.

      Fluxo de trabalho A — a atualização da versão 2 é ignorada, já que o conjunto de atualizações B, que contém a versão 2, nunca foi migrado.

      Fluxo de trabalho A — a versão 3 é confirmada e se torna a única versão publicada do fluxo de trabalho.

    Risco de migração do conjunto de atualizações

    O conjunto de atualizações B é migrado e confirmado para a instância de produção.

    1. Fluxo de trabalho A — a versão 3 é definida como não publicada.
    2. Fluxo de trabalho A — a versão 1 permanece não publicada.
    3. Fluxo de trabalho A — a versão 2 é confirmada e se torna a única versão publicada do fluxo de trabalho.

      O fluxo de trabalho retrocedeu uma versão, talvez de maneira não intencional. A versão regredida se torna a versão publicada no momento.