Máquinas de Estado e Workflows com WF4

Olá pessoal, tudo certo?

Essa semana resgatei um assunto a pedido de um time de arquitetura – construção de máquinas de estado com o WF4, certo Cristiano e Mario? :)

De fato, o WF 4 disponível com o .NET 4.0 não suporta nativamente templates de Máquinas de Estado (State Machine), como existia no WF 3.x.

Para quem não se lembra, uma máquina de estado em WF 3.x usava atividades como State, SetState, StateInitialization, StateFinalization, EventDriven, Terminate, entre outros. Esse tipo de implementação é bem aderente para controle de máquinas em pontos de vendo, regras de negócio orientadas a eventos e outros cenários interessantes.

Um exemplo de projeto de máquina de estado aparece na figura abaixo:

Como alternativa, podemos usar os workflows do tipo FLOWCHART, que estão disponíveis no WF4. Uma série de cenários de máquinas de estado podem ser implemetadas como FLOWCHARTS do WF4, por isso é uma alternativa interessante.

Recomendo a leitura do documento de migração de State Machine, que orienta todo o processo de migração de Máquinas de Estado WF 3.x para WF4.

Você pode baixá-lo no link a seguir:

Workflow migration guide
Ref.: https://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=bd94c260-b5e0-4d12-93ec-53567505e685

Veja o documento “WF4 State Machine Guidance.doc”

Um exemplo de transição de estados implementado com o WF4 FlowChart aparece abaixo:

A própria máquina de estado que aparece no início deste post ficaria assim em WF4::

Ainda, vale destacar que existe um projeto em andamento no CodePlex, que implementa algumas atividades para Máquinas de Estado na toolbox do WF 4, veja:

Microsoft WF State Machine Activity Pack CTP 1 Ref.: https://wf.codeplex.com/

Não deixe de conferir o pacote CTP 1 e o documento Microsoft WF State Machine Activity Pack CTP 1, que orienta sua utilização. Quando este pacote é instalado, ele adiciona algumas atividades para máquinas de estado, como vemos no Toolbox abaixo:

Como citado em um dos documentos de migração, o recurso de Máquinas de Estado é uma das funcionalidades que está sendo avaliada para a próxima atualização do WF4, para suporte nativo.

Para saber mais sobre Workflows e WF4, não deixe de conferir o blog do especialista Rafael Godinho, aqui do time Microsoft Brasil.

Blog do Rafae Godinho
Ref.: https://blogs.msdn.com/b/rafaelgodinho/

Por enquanto é só! Até o próximo post :)

Waldemir.

Comments

• Anonymous
  September 29, 2010
  The comment has been removed
• Anonymous
  September 29, 2010
  Olá Guerra, tudo certo? Sem dúvida, um cenário de workflow implementado via WF não tem a mesma performance de um cenário de lógica de negócio implementado via "switches" e "ifs" apenas com C#, concordo com você. Mas a comparação pode ser indevida. Isso porque um cenário de workflow com WF envolve outros aspectos que não temos no primeiro, como correlação de mensagens, persistência, controle de tempo para carga/descarga de memória, monitoração, tracking de mensagens, controle de eventos para disparo de atividades, etc. São muitas atividades de I/O e carga/descarga de código em memória. Porém, implementar essas funcionalidades manualmente não faz sentindo, uma vez que temos um framework que já implementa esses mecanismos. Algumas empresas, entretanto, já construiram seus próprios motores de workflows, sem usar WF (o que pode ser investimento caro hoje!). Tenho visto alguns cenários de workflow (3.5 e agora 4.0) com grande performance, durante as várias atividades de correlação, carga/descarga e execução de processos. Mas com certeza, existem cuidados que precisamos aplicar na construção de workflows com WF, para uma boa performance. Por exemplo:

• manter os workflows não muito extensos;
• equilibrar o número de workflows com o número de CodeActivities presentes por workflow;
• manter controle sobre o nível de encadeamento de workflows para uma mesma aplicação;
• controlar o número de roundtrips para bancos de dados a partir de CodeActivities, assim como o tamanho dos escopos de transação, etc. Seguindo boas práticas, é possível construir excelentes cenários WF, com performance e a facilidade da programação visual do WF no Visual Studio. Por último, o uso de APPFABRIC para hosting, persistence e monitoring não prejudica a performance da solução, uma vez que as atividades de tracking são feitas de forma assíncrona, via protocolo NET.PIPE. Cada vez mais, usar APPFABRIC como base é passo fundamental. É uma bela discussão! Obrigado pelo comentário no blog! :) Um abraço! Waldemir.