Movimentação de fluxo de trabalho com conjuntos de atualizações

O sistema rastreia fluxos de trabalho em conjuntos de atualizações de forma diferente de outros registros, pois as informações de fluxos de trabalho são armazenadas em várias tabelas.

As mudanças feitas em uma versão de fluxo de trabalho não são adicionadas ao conjunto de atualizações até que o fluxo de trabalho seja publicado, momento em que todo o fluxo de trabalho é adicionado ao conjunto de atualizações. Os conjuntos de atualizações armazenam fluxos de trabalho como um único registro "Fluxo de trabalho [wf_workflow]" e retêm somente a versão mais recente com o tipo de atualização "Fluxo de trabalho".

Para obter informações sobre conjuntos de atualizações, consulte Conjuntos de atualizações do sistema.

Caso de uso de migração de conjunto de atualizações de fluxo de trabalho - simples

Crie um novo fluxo de trabalho sem dependências e migre-o em um conjunto de atualizações.

1. O usuário A seleciona o conjunto de atualizações A.
2. O usuário A cria um novo fluxo de trabalho chamado "Fluxo de trabalho A".
3. O usuário A publica o fluxo de trabalho A.

   Um registro de conjunto de atualizações do cliente é adicionado ao conjunto de atualizações A que contém uma carga XML, incluindo o fluxo de trabalho A publicado e todas as dependências de atividade. A carga XML também contém as variáveis de entrada associadas ao fluxo de trabalho.

4. O usuário A conclui o conjunto de atualizações A e o migra para a instância de produção.
5. O conjunto de atualizações A é confirmado.
6. O fluxo de trabalho A funciona conforme o esperado.

Caso de uso de migração de conjunto de atualizações de fluxo de trabalho - dependência de subfluxo (sucesso)

Edite e migre um fluxo de trabalho existente e seu subfluxo dependente.

1. O usuário A seleciona o conjunto de atualizações B.
2. O usuário A faz o check-out do fluxo de trabalho A.
3. O usuário A adiciona um subfluxo chamado "Fluxo de trabalho B" ao fluxo de trabalho A.

   Suponha que o fluxo de trabalho B foi anteriormente publicado e migrado para a instância de produção.

4. O usuário A publica o fluxo de trabalho A.

   Um registro de conjunto de atualizações do cliente é adicionado ao conjunto de atualizações B que contém uma carga XML, incluindo o fluxo de trabalho A publicado e todas as dependências de atividade. A carga XML também contém as variáveis de entrada associadas ao fluxo de trabalho.

5. O usuário A conclui o conjunto de atualizações B e o migra para a instância de produção.
6. O conjunto de atualizações B é confirmado.
7. O fluxo de trabalho A funciona conforme o esperado, com o fluxo de trabalho B como subfluxo.

Caso de uso de migração de conjunto de atualizações de fluxo de trabalho - dependência de subfluxo (falha)

Edite e migre um fluxo de trabalho existente de uma instância de teste para uma instância de produção que não seja executada na instância de produção devido à ausência de um subfluxo dependente.

1. O usuário A seleciona o conjunto de atualizações C.
2. O usuário A faz o check-out do fluxo de trabalho A.
3. O usuário A adiciona um subfluxo chamado "Fluxo de trabalho B" ao fluxo de trabalho A.

   Suponha que o fluxo de trabalho B foi anteriormente publicado, porém não foi migrado para a instância de produção.

4. O usuário A publica o fluxo de trabalho A.

   Um registro de conjunto de atualizações do cliente é adicionado ao conjunto de atualizações C que contém uma carga XML, incluindo o fluxo de trabalho A publicado e todas as dependências de atividade. A carga XML também contém as variáveis de entrada associadas ao fluxo de trabalho.

   É notável a ausência do subfluxo chamado "Fluxo de trabalho B" no conjunto de atualizações C. O fluxo de trabalho B foi publicado antes que o usuário A selecionasse o conjunto de atualizações C.

5. O usuário A conclui o conjunto de atualizações C e o migra para a instância de produção.
6. O conjunto de atualizações C é confirmado com avisos.
7. O fluxo de trabalho A é invocado na instância de produção com estes resultados:

   O fluxo de trabalho A falha na verificação de validação de tempo de execução, e sua execução é impedida no sistema de produção. O sistema adiciona ao contexto de fluxo de trabalho uma entrada de registro em log de fluxo de trabalho que detalha a causa da falha, ou seja, a ausência de um fluxo de trabalho dependente.

   Para saber mais sobre as verificações de validação nas dependências do fluxo de trabalho e nos conjuntos para atualização, consulte ValidateUpdateSetDependencies.

Caso de uso de migração de conjunto de atualizações de fluxo de trabalho - dependência de subfluxo (risco)

Vários usuários migram um fluxo de trabalho de uma instância de teste para uma instância de produção sem a coordenação adequada. Este caso de uso pode ser bem-sucedido, mas somente quando cada usuário entende as dependências e faz a migração correta das partes dependentes do fluxo de trabalho para a nova instância.

O exemplo não representa uma falha do conjunto de atualizações, embora os conjuntos para atualização sejam mais frequentemente responsabilizados neste caso de uso. A validação aumenta a visibilidade das dependências do fluxo de trabalho em vários conjuntos de atualizações e oferece melhores informações aos designers. Na maioria dos casos, os avisos não impedem uma ação, mas apenas identificam o risco. O designer é responsável por executar as ações de acordo com o conselho fornecido nas verificações de validação.

1. O usuário A seleciona o conjunto de atualizações C.
2. O usuário A faz o check-out do fluxo de trabalho A.
3. O usuário A adiciona um subfluxo chamado "Fluxo de trabalho B", que retorna uma ID de usuário.
   Nota:

   Suponha que o fluxo de trabalho B foi anteriormente publicado e migrado para a instância de produção.
4. O usuário A usa o valor do retorno do fluxo de trabalho B para gerar aprovações.
5. O usuário B seleciona o conjunto de atualizações D.
6. O usuário B faz check-out do fluxo de trabalho B (o subfluxo no fluxo de trabalho A).
7. O usuário B modifica o valor de retorno do fluxo de trabalho, mudando-o de uma ID de usuário para uma Mensagem de cadeia de caracteres.
8. O usuário A publica o fluxo de trabalho A.
   Nota:

   Uma caixa de diálogo exibe os avisos associados ao fluxo de trabalho A e incentiva o usuário A a validar o fluxo de trabalho antes da publicação.
9. O usuário A cancela a publicação e valida o fluxo de trabalho A.
10. O usuário A é avisado de que o fluxo de trabalho B foi modificado por um usuário em um conjunto de atualizações diferente.
11. O usuário A ignora o aviso e publica o fluxo de trabalho A.
    Nota:

    Um registro do conjunto de atualizações do cliente é adicionado ao conjunto de atualizações C que contém uma carga XML, incluindo o fluxo de trabalho A publicado e todas as dependências de atividade. A carga XML também contém as variáveis de entrada associadas ao fluxo de trabalho.
12. O usuário A conclui o conjunto de atualizações C e o migra para a instância de produção.
13. O fluxo de trabalho A é invocado na instância de produção e executado com sucesso usando a versão mais antiga do fluxo de trabalho B que já está no sistema.
14. O usuário B publica o fluxo de trabalho B.
    Nota:

    O usuário B não é avisado sobre a dependência do conjunto de atualizações C porque o conjunto não está mais em andamento. No entanto, o usuário B é informado por uma caixa de diálogo que há avisos associados à versão do fluxo de trabalho e é instruído a validar o fluxo de trabalho B. Se o usuário B cancelar a publicação e validar o fluxo de trabalho, ele será avisado de que há fluxos de trabalho que usam o fluxo de trabalho B como subfluxo. Sabendo que o valor de retorno foi mudado, o usuário B deverá testar esses fluxos de trabalho também. Consulte ValidateUpdateSetDependencies para entender os parâmetros dos avisos sobre o conjunto de atualizações.
15. O usuário B finalmente publica o fluxo de trabalho B.
    Nota:

    Um registro de conjunto de atualizações do cliente é adicionado ao conjunto de atualizações D que contém uma carga XML, incluindo o fluxo de trabalho B publicado e todas as dependências de atividade.
16. O usuário B conclui o conjunto de atualizações D e o migra para a instância de produção.
17. O conjunto de atualizações D é confirmado sem avisos.
18. O fluxo de trabalho A é invocado na instância de produção e não é executado porque o valor de retorno do fluxo de trabalho B não gera mais uma ID de usuário.