ValidateUpdateSetParentDependencies

O validador ValidateUpdateSetParentDependencies identifica todos os subfluxos que chamam o fluxo de trabalho atual como subfluxo e determina se algum desses fluxos de trabalho primários está sendo editado em um conjunto de atualizações diferente que esteja em andamento.

Este aviso informa ao usuário que o fluxo de trabalho e um ou mais fluxos de trabalho que dependem dele estão sendo modificados ativamente de uma maneira que não será implantada simultaneamente em outra instância sem esforço adicional.

Resumo da validação

• Risco: se um fluxo de trabalho primário for editado em um conjunto de atualizações e seu subfluxo dependente for editado em outro, os dois fluxos de trabalho poderão não ser compatíveis quando movidos para uma instância diferente. Mudanças feitas de maneira independente, como a edição de valores comuns ou esperados, poderão tornar os dois fluxos de trabalho incompatíveis.
• Nível de gravidade: Aviso
• Resultado válido: Válido
• Mensagem válida: Não foram encontrados problemas de dependência de conjunto de atualizações.
• Resultado inválido: Inválido
• Mensagem Inválida: Este fluxo de trabalho tem fluxos de trabalho dependentes que estão em um conjunto de atualizações diferente.
• Ação sugerida: modifique e implante ambos os fluxos de trabalho no mesmo conjunto de atualizações. Se você precisar modificar dependências em conjuntos para atualização separados, use um destes métodos:
  • Assegure que todos os conjuntos para atualização sejam migrados simultaneamente.
  • Antes de implantar o conjunto de atualizações de fluxo principal, mescle as dependências em um conjunto de atualizações antes de definir sua conclusão.
• Publicável: Sim
• Executável: Sim
• Informações relacionadas: Movimentação de fluxo de trabalho com conjuntos de atualizações

Solução de problemas

Um fluxo de trabalho é adicionado a um conjunto de atualizações somente quando o fluxo de trabalho é publicado. Este validador emite um aviso quando existe uma das seguintes condições:

• Um subfluxo publicado está em um conjunto de atualizações diferente do fluxo de trabalho primário, e esse conjunto de atualizações está em andamento.
• Um subfluxo foi submetido a check-out por outro usuário, que está trabalhando em um conjunto de atualizações diferente daquele do usuário atual.

Nota:

Este validador não procura conjuntos para atualização que foram encerrados. Ele verifica somente os conjuntos para atualização que estão em andamento ou os conjuntos para atualização de todos os fluxos de trabalho primários que chamem o fluxo de trabalho atual e sejam submetidos a check-out para usuários que estão trabalhando em um conjunto para atualização diferente.

Exemplo

O exemplo a seguir mostra um cenário de desenvolvimento em risco, no qual dois usuários criam dependências entre fluxos de trabalho em diferentes conjuntos para atualização.

Usuário A:

1. Define o Conjunto de atualizações A como o conjunto de atualizações atual.
2. Submete o Fluxo de trabalho A ao check-out.
3. Altera o valor de retorno do tipo Cadeia de caracteres no Fluxo de trabalho A para um tipo Referência/Usuário.
4. Publica o Fluxo de trabalho A, causando uma entrada no Conjunto de atualizações A.

Usuário B:

1. Define o Conjunto de atualizações B como o conjunto de atualizações atual.
2. Submete o Fluxo de trabalho B ao check-out.
3. Inclui o Fluxo de trabalho A como subfluxo.
4. Usa o valor de retorno de referência do usuário do Fluxo de trabalho A como atribuição de aprovação.
5. Publica o Fluxo de trabalho B, causando uma entrada no Conjunto de atualizações B.

Riscos

• O Usuário B move o Conjunto de atualizações B para uma instância diferente que tem uma versão mais antiga do Fluxo de trabalho A. O valor de retorno não é uma referência do usuário, o que faz com que o resultado do Fluxo de trabalho B seja diferente daquele quando foi testado no desenvolvimento.
• O Usuário B move o Conjunto de atualizações B para uma nova instância que não tem uma versão do Fluxo de trabalho A. O Fluxo de trabalho B tem uma falha de validação no tempo de execução e não pode ser executado. Uma entrada de log é adicionada ao log do fluxo de trabalho do registro atual.

Possíveis soluções

Solução 1

Migre o fluxo de trabalho primário e todos os fluxos de trabalho dependentes juntos para uma nova instância usando o mesmo conjunto de atualizações.

1. Defina o conjunto de atualizações como aquele que você quer usar para migrar as novas instâncias.
2. Verifique e publique novamente os fluxos de trabalho que precisam ser incluídos.
   Nota:

   Esta ação força uma entrada no conjunto de atualizações atual.
3. Conclua o conjunto de atualizações com todas as dependências.
4. Siga os procedimentos padrão para migrar conjuntos para atualização para instâncias locais. Para obter informações sobre conjuntos para atualização, consulte Conjuntos de atualizações do sistema.

Solução 2

Mova fluxos de trabalho dependentes entre conjuntos para atualização.

1. Identifique o conjunto de atualizações que contém o fluxo de trabalho principal a ser migrado.
2. Navegar até Conjuntos de atualização do sistema > Conjuntos para atualização locais.
3. Encontre e selecione o conjunto de atualizações que contém as dependências do fluxo de trabalho principal.
4. Na lista relacionada Atualizações do cliente, selecione a versão do fluxo de trabalho do subfluxo que você deseja mover.
5. Selecione o conjunto de atualizações que contém o fluxo de trabalho primário no campo Conjunto de atualizações. Se esse campo não estiver no formulário de atualização do cliente, configure o formulário e adicione o campo.
6. Clique em Atualizar. O sistema de base move o subfluxo dependente para o conjunto de atualizações selecionado.
7. Repita as etapas de 4 a 6 para adicionar subfluxos dependentes adicionais ao conjunto de atualizações do fluxo primário.