Arquitetura de Aplicações com Workflows – WF, BizTalk e SharePoint
Olá pessoal, tudo certo?
Semana passada acompanhei algumas discussões sobre aplicações com workflows. Com certeza, esse assunto é constante em muitas empresas. Vou aproveitar esse post para registrar algumas idéias sobre o assunto.
Existem diversos cenários de aplicações com workflows, como:
- Processo de aprovação e revisão de documentos financeiros;
- Processo de abertura de um incidente em TI, envolvendo emails de alertas e formulários;
- Movimento automático de documentos entre repositórios;
- Retirada de documentos para um respositório através de regras de expiração;
- Disparo de atividades e workflows através de um scheduler/calendário;
- Coordenação de serviços em soluções distribuídas;
- Shopping cart workflow, etc.;
Entre as principais características de um workflow temos:
- Um workflow precisa ser executado por um processo host (container);
- Um workflow envolve a exposição de funcionalidades e não de interfaces;
- O ciclo de vida de um workflow é responsabilidade de um workflow runtime;
- Um workflow runtime realiza tarefas como criação, execução, caching, persistência, tracking de mensagens, mensageria, eventos, hosting, comunicação, transformação, identidade, autenticação, segurança, etc.
Podemos classificar workflows em dois grandes tipos: Human Workflows e System Workflows.
System Workflows (ou machine-centric) – são workflows envolvendo atividades automáticas ou disparo de tarefas e serviços entre sistemas. Por exemplo, imagine um processo de compras/cotações envolvendo diversas empresas. A partir do disparo da requisição de cotação, diversas chamadas para serviços em outras empresas são feitas automaticamente, com a execução remota de workflows ou tarefas em sistemas externos. A partir do retorno de todas as chamadas, a resposta consolidada é entregue para o usuário.
Veja a figura abaixo, que ilustra esse cenário:
Human Workflows (human-centric ou people-driven processes) – são workflows envolvendo interação humana para atividades como aprovação, colaboração, revisão, monitoração, etc., em fases específicas do processo em execução.
Imagine um Human Workflow que envolve um usuário candidato, que submete formulários preenchidos para um sistema. A submissão do formulário dispara um processo de aprovação, que envolve a revisão do documento por outro usuário revisor no processo.
O desenho abaixo ilustra esse cenário:
Para a construção de aplicações com workflows temos diversas alternativas na plataforma Microsoft. Para simplificar, podemos destacar 3 principais alternativas: WF – Windows Workflow Foundation, BizTalk Server e SharePoint Server.
Para system workflows com grande número de adaptadores, integração entre sistemas ou mesmo transformações entre chamadas, o BizTalk Server oferece um ambiente interessante para a orquestração de tarefas, como vemos na figura abaixo:
Para system workflows customizados, que envolvem chamadas para sistemas, web services, ou dentro do escopo de uma aplicação podemos usar o WF 4 – Windows Workflow Foundation. Através do WF, construímos workflows sistêmicos, com grande flexibilidade para integração. A principal diferença em relação ao BizTalk Server é que com WF, sua aplicação será responsável pela construção de mensageria, transformações, adaptadores, etc. Lembre-se, usando um motor como BizTalk algumas tarefas já estão prontas, enquanto que usando o WF, precisamos construir esses componentes.
Para ilustrar, a figura abaixo apresenta um workflow construído com o WF 4, veja:
Finalmente, para human workflow podemos usar tanto o WF, para cenários customizados, como a própria plataforma SharePoint Server, que oferece uma série de recursos para o tratamento de coleções, repositório de documentos, mailing, etc.
A figura abaixo ilustrar uma das telas de criação de workflows na plataforma SharePoint Server, veja:
Para terminar, veja a figura a seguir. Ela apresenta um desenho de arquitetura de aplicação para human workflow, que prevê diferentes interfaces de usuários, em ambientes web, desktop, mobile, etc.
Retirei a figura acima de um belo artigo sobre workflows da arquiteta Michele Leroux Bustamante, da IDesign , veja:
WF Scenarios Guidance: Human Workflow
Ref.: https://msdn.microsoft.com/en-us/library/cc709416.aspx
Claro, esse post não pretende ser uma descrição completa sobre as principais diferenças entre WF, BizTalk Server e SharePoint Server quando o assunto é workflow. Mas fica a dica de que essas alternativas oferecem bons recursos para diversos cenários de orquestração de atividades. Vale o estudo!
Por enquanto é só! Até o próximo post :)
Waldemir.
Comments
Anonymous
July 14, 2010
Olá. Parabens pelo artigo. Só fico encomodado do porque a microsoft não adota BMPN para o WF. Hoje é complicado mostrar um fluxo em WF para alguem de processos, parece coisa de outro mundo. Sendo que eles já estão acostumados com o padrão de mercado que é o BMPN.Anonymous
July 15, 2010
Olá Rafael, tudo certo? Obrigado pelos comentários no blog. Só para checar, você está falando de BPMN - Business Process Modeling Notation, correto? Veja mais aqui: en.wikipedia.org/.../Business_Process_Modeling_Notation Não sou especialista em BPM, mas lembro que havia algumas diferenças importantes entre o mapeamento BPMN e WF até o .NET 3.5. Nessa versão, o WF era estruturado em blocos, o que impedia o mapeamento de fluxos com retorno para atividades passadas (algo equivalente ao comportamento GOTO, lembra?) Agora com o WF 4.0, é possível implementar esse tipo de comportamento, o que é bem interessante para diversos cenários de aplicações. Ao mesmo tempo, vale lembrar que o WF 4.0 agora é declarativo, o que permite a extensão ou customização de shapes e atividades no framework. Assim, seria possível construir um mapeamento dos mesmos shapes que temos no BPMN para o mapeamento de workflows. Finalmente, é possivel construir aplicações customizadas com o WF Designer extendido, o que permite a construção de interfaces de workflows para usuários de negócio. Não vi ainda um plug-in ou mapping automático para esse tipo de mapeamento entre BPMN e WF 4, mas creio que é bem possível. Um tempo atrás vi uma iniciativa interna na Microsoft para isso, mas não tive maiores informações. Ainda vale citar que o BPM é focado fortemente em system-workflow, enquanto que o WF permite cenários mais flexíveis de human-workflow e system-workflow. É uma bela discussão! Fique a vontade para seus comentários. Um abraço! Waldemir.