Entendendo o Desenvolvimento de Workflows

Workflows são recursos muito importantes para os projetos SharePoint, isso porque eles agregam muito valor para o cliente. Grande parte desses workflows são criados pelo SharePoint Designer, mas alguns necessitam ser desenvolvimentos utilizando o Visual Studio, que na minha opinião são os artefatos mais complexos que podem ser gerados com o SharePoint 2010, porque são eles que irão gerenciar outros recursos de forma direta ou indireta. Um serviço pode ser chamado diretamente a partir do workflow, enquanto uma formatação condicional em formulários InfoPath podem ser utilizadas a partir de campos alterados pelo workflow.

É comum um workflow ser o núcleo de uma solução com diversos componentes.

Mas o que acontece muitas vezes é os workflows não são feitos de uma forma amigável e geram mais trabalho (incômodos) do que solução. O que leva ao descrédito da tecnologia e as pessoas fugirem dele de toda forma.

Na minha visão o workflow é uma ferramenta (recurso) muito útil em determinados projetos e a sua utilização é fundamental para o seu sucesso. Neste post vou falar sobre algumas boas práticas que acho importantes serem seguidas nesse desenvolvimento e evitar problemas futuros.

Gosto muito de trabalhar com workflows e acredito que são ótimas soluções para diversos cenários, indispensável para clientes que precisem de aprovações de tarefas, documentos e processos mais complexos. Agilizando e desburocratizando o fluxo de negócio.

Este post faz parte de uma série de posts sobre entendimento do SharePoint 2010, acesse o post principal para ver os outros assuntos: Entendendo o SharePoint 2010

 

Regras de Negócio

É comum vermos workflows criados como se fossem repositórios de regras de negócio, ou seja, todas as regras de negócio envolvidas estão escritas dentro do próprio workflow.

A criação de workflows dessa forma acarreta em muitos prejuízos futuros, um deles é a constante atualização das dlls do seu workflow no servidor, veja o post Desenvolvimento de Workflows para entender um pouco melhor o trabalho para resolver isso.

Os workflows devem ser mais enxutos possíveis e, se possível, sem regras de negócios. Mas para que serve um workflows então? Ele serve para organizar (orquestrar) regras de negócio com interação com o usuário, não para hospedá-las. Com base em uma ação do usuário, o workflow irá chamar uma regra de negócio ou outra, que estão disponibilizadas em serviços externos ao workflow. Dessa forma as regras de negócio podem ser alteradas conforme for necessário, sem impactar no workflow.

Um workflow ideal seria composto por laços de repetição, controle de interação com o usuário (criação de tarefas, alteração de tarefas, conclusão de tarefas), condições (if else) e diversas chamadas à serviços e sem nenhuma regra de negócio programada diretamente.

 

Contexto

O contexto do workflow são todos os dados que ele precisa para tomar decisões e executar alguma ação. Quando ele cria alguma tarefa ele precisa algumas informações como título, descrição, responsável e data de vencimento, isso seria um exemplo de parte do contexto do workflow.

Essas informações podem ser carregadas quando o workflow iniciar ou sempre que necessário. A vantagem de fazer tudo no início é que o resto do processo é teoricamente mais simples, já que está tudo no contexto. Por outro lado, se alguma dessas informações precisar ser alterada, o trabalho será bem maior.

A melhor maneira de carregar o contexto, na minha visão, é carregar o mínimo de informação possível e apenas quando necessário. Se para criar uma tarefa é necessário obter alguns dados, somente na hora de criação da tarefa específica é que isso seria feito. Evitando pegar todas as informações do contexto. Assim todas as informações obtidas serão sempre atualizadas.

Lembre-se que workflows geralmente são utilizados para executar processos de média e longa duração (vários dias ou até anos) e que dependam de interação com usuários. Então é fácil de imaginar que as informações necessárias para os processos irão alterar muito durante a execução de um workflow do início ao fim. Esse é um dos principais argumentos para utilizar esse carregamento do contexto o mais “lazy” (tarde) possível.

 

Conclusão

Workflows são muito bons e ajudam demais os clientes e quem está desenvolvendo, tome alguns cuidados que a chance de sucesso na utilização de processos automatizados será muito maior.

Anúncios

2 Respostas to “Entendendo o Desenvolvimento de Workflows”

  1. Entendendo o SharePoint 2010 « Fabian André Gehrke Says:

    […] Entendendo o Desenvolvimento de Workflows […]

  2. Entendendo o SharePoint 2010 « Fabian André Gehrke Says:

    […] Entendendo o Desenvolvimento de Workflows […]


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: