Versão de fluxo de trabalho

5

Eu acredito que tenho um mal-entendido fundamental quando se trata de mecanismos de fluxo de trabalho, o que eu apreciaria se você pudesse me ajudar a resolver. Não tenho certeza se meu mal-entendido é específico para o mecanismo de fluxo de trabalho que estou usando ou se é um mal-entendido geral. Por acaso, uso o Windows Workflow Foundation (WWF).

Versão do TLDR

O WWF permite que você implemente processos de negócios em fluxos de trabalho de longa duração (pense meses ou até anos). Quando iniciado, os fluxos de trabalho não podem ser alterados. Mas qual processo de negócios não pode mudar a qualquer momento? E se um processo de negócios mudar, você não desejaria que seu software refletisse essa alteração para as 'instâncias' já iniciadas do processo de negócios? O que estou perdendo?

Plano de fundo

No WWF, você define um fluxo de trabalho combinando um conjunto de atividades. Existem diferentes tipos de atividades - algumas delas são para controle de fluxo, como IfElseActivity e WhileActivty, enquanto outros permitem que você execute tarefas reais, como a CodeActivity, que permite que você execute o código .NET e o InvokeWebServiceActivity, que permite chamar serviços da web. As atividades são combinadas em um fluxo de trabalho usando um designer visual. Você praticamente arrastar e soltar atividades de uma caixa de ferramentas para uma área de designer e conectar as atividades uns aos outros. O fluxo de trabalho e as atividades possuem parâmetros de entrada, parâmetros de saída e variáveis.

Temos um único fluxo de trabalho que às vezes é executado em questão de alguns dias, mas pode durar de cinco a seis meses. O WWF cuida de persistir o estado do fluxo de trabalho (qual atividade estamos atualmente executando, quais são os valores das variáveis e assim por diante).

Até agora eu acho que o WWF faz sentido. Algumas pessoas preferirão implementar uma representação de software de um processo de negócios usando um designer visual, escrevendo tudo em código.

Então qual é o problema então?

O que eu realmente não obtenho é o seguinte:

O WWF é projetado para cuidar de fluxos de trabalho de longa duração. Mas, ao mesmo tempo, o WWF não tem nenhuma funcionalidade embutida que permita modificar os fluxos de trabalho em execução. Portanto, se você modelar um processo de negócios usando um fluxo de trabalho e executá-lo por 6 meses, é melhor esperar que o processo de negócios não seja alterado. Porque se isso acontecer, você terá que ter várias versões do fluxo de trabalho em execução ao mesmo tempo. Isso parece ser um erro de design fundamental para mim, mas ao mesmo tempo parece mais provável que eu tenha entendido mal alguma coisa.

Para nós, isso teve alguns efeitos reais :

  • Lançamos novas versões todo mês, mas alguns fluxos de trabalho podem ser executados por um ano. Isso significa que temos várias versões do fluxo de trabalho em execução paralelamente, em outras palavras, várias versões das lógicas de negócios. Isso é o mesmo que ter várias versões diferentes do seu código sendo executadas em produção no mesmo sistema ao mesmo tempo, o que se torna um pouco difícil de entender para os usuários. (dependendo se eles clicaram em um botão 'Iniciar' 9 ou 10 meses atrás, o software se comportará de maneira diferente)
  • Nosso fluxo de trabalho se refere a diferentes tipos de entidades e, como o WWF agora persistiu e serializou essas entidades, não podemos realmente refatorar as entidades, pois os fluxos de trabalho existentes não poderão ser retomados (a desserialização falhará

Recebemos algumas sugestões sobre como lidar com isso

  • Quando criamos uma nova versão do fluxo de trabalho, cancelamos todos os fluxos de trabalho em execução e criamos novos. Mas em nossos fluxos de trabalho há muito trabalho manual envolvido e se começarmos do zero muito as pessoas têm que refazer seu trabalho.
  • Acompanhe o que foi feito no fluxo de trabalho e quando você criar uma nova atividade de pulo que já tenha sido executada. Eu sinto que essa alternativa pode funcionar para fluxos de trabalho simples, mas torna-se difícil determinar automaticamente quais atividades ignorar se houver uma grande refatoração feita em um fluxo de trabalho.
  • Quando criamos uma nova versão do fluxo de trabalho, atualize as versões antigas usando a nova funcionalidade do WWF 4.5 para atualizar os fluxos de trabalho. Mas então teríamos que pular o visual designer e escrever código para injetar atividades nos lugares certos no fluxo de trabalho. De acordo com o MSDN, essa funcionalidade de atualização destina-se apenas a pequenas correções de bugs e não a alterações maiores.

O que estou perdendo?

    
por Nitra 08.10.2013 / 20:55
fonte

2 respostas

1

tl; dr: Não é esperado que os fluxos de trabalho de longa duração sejam alterados durante a sua vida útil. Se houver a possibilidade de que eles possam mudar, divida-os em fluxos de trabalho cada vez menores e junte-os para criar um fluxo de trabalho maior.

Alterar a lógica de execução é difícil

Por que o seu sistema de computador às vezes exige uma reinicialização? Porque você não pode alterar os drivers de dispositivo enquanto estiverem em uso. Como você contorna isso? Tornando as coisas imutáveis e escrevendo programas de estilo funcional.

A linguagem de programação Erlang foi projetada especificamente para ser atualizada durante a execução dos programas. Como isso acontece? Mantendo instâncias imutáveis de funções na memória. Quando você faz um hot-patch em um programa em Erlang, Erlang simplesmente mantém as instâncias funcionais existentes até que elas terminem a execução. Quaisquer novas instâncias das funções usarão a nova versão da função e, como as funções são imutáveis, a estabilidade é garantida durante a transição.

Observe que isso não o ajudaria em seus fluxos de trabalho, pois você ainda não conseguiria fazer o hot patch em um fluxo de trabalho existente enquanto estiver em execução. Hot patching refere-se a sistemas inteiros de funções, não instâncias individuais de funções em execução. Seu fluxo de trabalho (essencialmente uma função de longa duração) ainda teria que terminar de executar primeiro.

Como você já apontou, muda para a execução Os fluxos de trabalho destinam-se a pequenos ajustes, e não a alterações por atacado no fluxo de trabalho.

    
por 08.10.2013 / 21:51
fonte
1

Track what has been done in the workflow and when you create a new one skip activites which have already been executed. I feel that this alternative may work for simple workflows, but it becomes hairy to automatically figure out what activities to skip if there's major refactoring done to a workflow.

O problema é que ele pode ficar até mesmo manualmente para descobrir quais atividades ignorar. Por exemplo, e se a atividade atual no fluxo de trabalho antigo não tiver atividade equivalente na nova? Então, sugiro que você use uma estratégia combinada:

  • use a abordagem "track & skip", onde é possível
  • use o "cancelar e reiniciar" quando não for possível
  • para casos especiais, você pode tentar criar subfluxos de trabalho para evitar um reinício completo, projetado especificamente para continuar um fluxo de trabalho já iniciado (antigo) em uma atividade específica, mas sem a necessidade de reiniciar desde o início completo
  • tente manter o número de "pontos de transição" pequenos (as atividades em que os atores precisam mudar da versão antiga do fluxo de trabalho para as novas) - certifique-se de que os atores alcancem um desses pontos até que o antigo substitua a nova versão. Os pontos de transição devem estar sempre com um pingente na nova versão. Isso ajudará em todos os casos acima.
por 08.10.2013 / 23:22
fonte