Windows WorkFlow Foundation – Controlando e gerenciando as regras de negócios

Software coorporativos possuem natureza e padrões de funcionamento comum. Tem por objetivo normalmente controlar, reduzir custos, auxiliar na melhora de desempenho no gerenciamento dos processos empresariais internos e/ou externos do empreendimento. Percebemos que a maioria dos softwares usados, buscam de certa forma automatizar as regras de negócios dos usuários, sendo necessário criar uma rede de comunicação entre diversas aplicações. Entretanto, a maioria depende de pessoas para aprovar documentos e resolver problemas não previstos no fluxo das informações. Atraves da aplicação de algumas técnicas de analise podemos descrever os passos entre os processos, isto é conhecido como WorkFlow ou em bom português, “fluxo de trabalho”. A finalidade deste artigo é descrever uma tecnologia da Microsoft criada para facilitar a programação de WorkFlows que são executados como se fossem algoritmos das atividades das pessoas e softwares. A idéia básica é que a partir da definição do WorkFlow, a aplicação pode ser construída com facilidade orientada para resolver e apoiar os processos ou regras de negócios coorporativo em questão.

A analise e a implementação de um WorkFlow em software são desafios impares,  pois dependendo do processo a ser descrito e controlado, o mesmo pode levar horas, dias ou um intervalo de tempo maior para ser concluído. Imagine por exemplo, quando fazemos uma compra em uma loja virtual. As informações do pedido persistem pelo tempo em que estivermos usando a loja e as informações de pagamento ficam retidas no sistema até o momento em que o pedido irá ser atendido. Neste caso, temos que programar o fluxo da informação e controlar o estado conforme o tempo em que o usuário estiver usando o carrinho de compra. A modelagem do processo é relativamente simples e comum, entretanto, talvez o usuário queira mudar o fluxo de trabalho. Então, como poderemos lidar com um eventual comportamento imprevisível? Nestas situações a criação e execução de um WorkFlow  em software apresenta desafios únicos. Alguns processos de negócios pode levar segundos, horas, dias ou semanas para ser concluído.

Como devemos manter as informações de um pedido no WorkFlow? O estado atual sincronizado para este período de tempo? Como um WorkFlow de longa duração poderá se comunicar com outro software de forma que não seja bloqueado? Como podem os desafios da comunicação não sincronizadas ser fácil para os desenvolvedores?

E enquanto modelar interações entre fixos software é relativamente simples, os usuários dos sistemas tendem a querer mais flexibilidade, como a capacidade de mudar um processo de negócio em tempo real. Como o fluxo de trabalho pode lidar com este comportamento diverso e imprevisível?

A maneira mais comum de controlar WorkFlows é através da programação, mas á medida em que os fluxos forem mudando, aumenta a complexidade do caso e cria diversos problemas relacionados com a manutenção na codificação do sistema.

Apresentarei a seguir uma alternativa que facilita o desenvolvimento de soluções que envolvam controles de fluxos de trabalho.

O Windows WorkFlow Fundation (também conhecido como WF) é a tecnologia explicitamente projetada pela Microsoft para suportar WorkFlows de forma útil e muito simples.

Diversos são os cenários para aplicações em que podemos usar a tecnologia Workflow Fundation;

Processo de aprovação e revisão de documentos; 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 agendamento/calendário; Coordenação de serviços em soluções distribuídas; Carrinho de compras; Controle de nível de um estóque; Analise de situação financeira ou qualquer automação de processos baseados em regras pré-estabelecidas, 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, ou seja, o fóco de aplicação é o processo em questão; O ciclo de vida de um WorkFlow  é responsabilidade de um WorkFlow  runtime que define o tempo e a estrutura do fluxo em questão; Um WorkFlow runtime realiza tarefas do processo tais como: Criação, execução, caching, persistência, rastreamento de mensagens, messageria[1], eventos, hosting, comunicação, transformação, identidade, autenticação, segurança, etc.

Para facilitar o entendimento, classificaremos os workflows em dois grandes tipos: Workflows Humanos (Human Workflows) e Workflows de Sistemas (System Workflows).

System Workflows (ou centradas em máquinas) – são Workflows que envolvem atividades automáticas ou disparo de tarefas e serviços entre sistemas. Por exemplo, imagine um processo de controle de estoque de uma empresa envolvendo diversas filiais. A partir do disparo da requisição de uma alteração no estoque de uma filial, diversas chamadas para serviços em outras filiais 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 e atualizada no estoque central, ficando disponível para todos os usuários de todas as filiais.

O Windows Workflow Foundation (WF) foi criado pela Microsoft para atender requisitos deste tipo. Está disponível como parte dos componentes do .NET Framework á partir da versão 3.0. Ele inicialmente fornecia uma base comum para a construção do fluxo de trabalho de aplicativos baseados em ambiente Windows, e com a sua evolução hoje podemos aplicar e integrar em outros ambientes, como por exemplo em aplicações ASP.Net.

Para ter uma noção do que é exigido a partir de um quadro como fluxo de trabalho WF, é útil pensar em diferentes tipos de aplicativos que possam usar os fluxos de trabalho.

Aqui estão alguns exemplos:

Qualquer aplicativo que implementa um processo de longa duração é um lugar natural para fluxo de trabalho. Processos que interagem com pessoas, que podem levar horas ou dias para responder, são um exemplo importante disto. Por exemplo, a construção de uma aplicação de aprovação de documentos em torno de um fluxo de trabalho faria de bom senso.

Um aplicativo ASP.NET que exibe páginas de seus usuários podem usar um fluxo de trabalho para controlar a ordem em que as páginas são mostradas. Isso pode torná-lo mais fácil de mudar o fluxo de página sem alterar as páginas se, bem como limpar e separar a interface de usuário do aplicativo a partir de sua lógica de controle.
Um aplicativo composto em um ambiente orientado a serviços pode implementar o seu comportamento do núcleo utilizando um fluxo de trabalho. Como mais e mais aplicações expõe sua lógica através de serviços a tecnologia de workflow, como WF fornece uma base para a lógica que irá invocar esses serviços, em um aplicativo composto.

Uma aplicação concentrada em um problema específico, como CRM (customer relationship management), ou um software específico que gerencie serviços financeiros, pode ser construído em torno de um fluxo de trabalho. Este tipo de aplicação geralmente implementa um ou mais processos de negócios diferentes. Construindo a lógica que orienta os processos em torno de um WorkFlow comum e isto possibilita que a construção do aplicativo seja mais rápida, mais rápido para mudar, e mais fácil de dar manutenção.

A melhor maneira de começar a desenvolver é descrever o fluxo dos requisitos da solução em uma estrutura de WorkFlow verificando as estruturas de decisões necessárias para dar continuidade no controle do fluxo. A figura abaixo mostra um exemplo simples de como uma aplicação para solicitar um empréstimo em uma instituição bancária.

Diversos são os cenários para aplicações em que podemos usar a tecnologia Workflow Fundation;

Para facilitar o entendimento, classificaremos os workflows em dois grandes tipos: Workflows Humanos (Human Workflows) e Workflows de Sistemas (System Workflows).

System Workflows (ou centradas em máquinas) – são Workflows que envolvem atividades automáticas ou disparo de tarefas e serviços entre sistemas. Por exemplo, imagine um processo de controle de estoque de uma empresa envolvendo diversas filiais. A partir do disparo da requisição de uma alteração no estoque de uma filial, diversas chamadas para serviços em outras filiais 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 e atualizada no estoque central, ficando disponível para todos os usuários de todas as filiais.

O Windows Workflow Foundation (WF) foi criado pela Microsoft para atender requisitos deste tipo. Está disponível como parte dos componentes do .NET Framework á partir da versão 3.0. Ele inicialmente fornecia uma base comum para a construção do fluxo de trabalho de aplicativos baseados em ambiente Windows, e com a sua evolução hoje podemos aplicar e integrar em outros ambientes, como por exemplo em aplicações ASP.Net.

Para ter uma noção do que é exigido a partir de um quadro como fluxo de trabalho WF, é útil pensar em diferentes tipos de aplicativos que possam usar os fluxos de trabalho.

Aqui estão alguns exemplos:

Qualquer aplicativo que implementa um processo de longa duração é um lugar natural para fluxo de trabalho. Processos que interagem com pessoas, que podem levar horas ou dias para responder, são um exemplo importante disto. Por exemplo, a construção de uma aplicação de aprovação de documentos em torno de um fluxo de trabalho faria de bom senso.

Um aplicativo ASP.NET que exibe páginas de seus usuários podem usar um fluxo de trabalho para controlar a ordem em que as páginas são mostradas. Isso pode torná-lo mais fácil de mudar o fluxo de página sem alterar as páginas se, bem como limpar e separar a interface de usuário do aplicativo a partir de sua lógica de controle.
Um aplicativo composto em um ambiente orientado a serviços pode implementar o seu comportamento do núcleo utilizando um fluxo de trabalho. Como mais e mais aplicações expõe sua lógica através de serviços a tecnologia de workflow, como WF fornece uma base para a lógica que irá invocar esses serviços, em um aplicativo composto.

Uma aplicação concentrada em um problema específico, como CRM (customer relationship management), ou um software específico que gerencie serviços financeiros, pode ser construído em torno de um fluxo de trabalho. Este tipo de aplicação geralmente implementa um ou mais processos de negócios diferentes. Construindo a lógica que orienta os processos em torno de um WorkFlow comum e isto possibilita que a construção do aplicativo seja mais rápida, mais rápido para mudar, e mais fácil de dar manutenção.

A melhor maneira de começar a desenvolver é descrever o fluxo dos requisitos da solução em uma estrutura de WorkFlow verificando as estruturas de decisões necessárias para dar continuidade no controle do fluxo. A figura abaixo mostra um exemplo simples de fluxo em uma aplicação para solicitar um empréstimo em uma instituição bancária.

"Emprestimo"

WorkFlow Empréstimo

O processo começa quando um Cliente submete através da Internet um pedido de um empréstimo. A chegada de um novo pedido cria uma nova instância desse fluxo de trabalho. O WorkFlow começa por verificar se as informações fornecidas na solicitação obedece as regras da instituição para emissão da liberação. Se o requerente não atender aos critérios, o pedido é rejeitado. Caso contrário, o WorkFlow solicita o histórico do Cliente de um serviço de crédito externo (por ex: SERASA, SPC). Se não houver pendências o empréstimo é liberado imediatamente, mas se houver alto risco por conta do histórico de crédito ruim a liberação irá necessitar da aprovação de um gerente. Se esta aprovação for concedida, o empréstimo é liberado. Se não, o empréstimo é rejeitado.

A figura descreve os requisitos e WorkFlow de forma simples. Perceba que temos no decorrer do fluxo a  capacidade de tomar decisões baseadas em regras de negócio. Por exemplo no resultado de uma verificação de crédito, e regras mais complexas, como o conjunto potencialmente grande que devem ser avaliados para tomar uma decisão inicial.
Maneiras de se comunicar com outro software e outros sistemas fora do fluxo de trabalho. Neste exemplo, o pedido inicial é recebido de uma outra parte do aplicativo, como uma página ASP.NET, enquanto alguns aspectos, como entrar em contato com o serviço de crédito, exigem a comunicação usando serviços da Web ou outras tecnologias.
Maneiras de interagir com as pessoas. No exemplo a figura ilustra que o gerente deve aprovar em algum caso o empréstimo, e assim o fluxo de trabalho deve ser capaz de exibir uma interface de usuário própria ou interagir com o usuário através da interface.
A capacidade de manter o estado ao longo da vida do fluxo de trabalho. Especialmente quando as pessoas estão envolvidas, como com o gestor de, neste exemplo, um fluxo de trabalho pode levar muito tempo para completar. (E se o gerente deixou para o dia, ou está em uma férias de duas semanas?) A construção de sistemas escaláveis também requer uma maneira de desativar o fluxo de trabalho e armazenar seu estado persistentemente, em seguida, reativá-lo e carregar esse estado quando o próximo passo pode ser executada.
Todos estes são requisitos fundamentais para fluxos de trabalho. A maioria deles são também um desafio para fazer sem o desenvolvimento de uma forma projetada explicitamente para suportar fluxos de trabalho.


[1] A Microsoft define como “Messageria”como a função de troca massiva de mensagens.


 No próximo artigo irei demonstrar como é simples criar um WorkFlow para gerenciar o fluxo de uma aplicação.  Virtual abraço e até breve.

Para saber mais:

http://msdn.microsoft.com/en-us/netframework/aa663328

http://msdn.microsoft.com/pt-br/library/aa480214.aspx

http://www.windowsworkflowfoundation.eu/

http://www.microsoft.com/en-us/download/details.aspx?id=5222

 

Comentarios

comentarios