Você, que está usando o Windows Workflow Foundation – WWF para desenvolver algumas aplicações orientadas a processos, usando o “Sequential Workflow”, já notou que ao tentar desenhar um fluxo como o abaixo, desenhado usando BPMN, não consegue?
O processo tem uma regra de negócio básica, presente em qualquer processo de empresa: da atividade A, uma condição é avaliada e o processo segue para B ou C. Se for para C, após essa atividade, deve voltar para “A”. O modelo “Sequential Workflow”não permite diretamente esses “loops” para pontos passados do processo, da mesma maneira que processos baseados em BPEL também não deixam. Isso pois o modelo XAML, utilizado pela Microsoft para descrever os processos do WWF, similarmente ao BPEL, é em formato bloco-estruturado, onde cada “perna” do processo deve ser fechada antes de o processo continuar, e onde não é possível referenciar elementos anteriores.
A solução? Vemos algumas:
- Existem alguns métodos na internet que chamarei carinhosamente de “gambiarra” para representar uma volta no “Sequential Workflow”, e que prefiro não citar aqui;
- Posso redesenhar o fluxo acima, tornando-o compliance com o XAML. Isso foi demonstrado no nosso post anterior, onde falamos sobre a diferença entre e o BPMN e BPEL;
- Posso utilizar o outro modelo de workflow do WWF, o “State-Machine”. Apesar de bem mais flexível, esse modelo é muito distante do modo como os processos são mapeados usando BPMN pelos analistas de negócio, fazendo com que o projeto técnico final fique destoante de uma fase de levantamento e mapeamento dentro de um projeto de BPM;
Você conhece outra alternativa? Colabore e faça um post aí.
Por esses e outros motivos, nos projetos em que trabalho, o WWF tem tido maior utilidade em processos de menor complexidade, como workflow básico (aprovações, revisões, etc…) e pequenas integrações. Em processos de colaboração complexa com mais de 50 atividades e uma infinidade de possibilidades, o WWF pode dificultar.
6 de Outubro de 2007 às 16:15
Rafael Bortolini
Um dos assuntos mais importantes em BPM, com certeza, é a integração entre o modelo de negócio do processo, desenhado por um analista, e o modelo de execução, gerenciado por um técnico. Para grande parte das plataformas e projetos hoje, é integração entre o desenho BPMN e a execução BPEL do processo. O fato é que, apesar do que vemos com grande destaque no mercado, essa integração não é nada, nada, nada simples e direta, dando origem ao conhecido problema de round-tripping.
O round-tripping consiste na possibilidade de manter sincronizado o desenho de negócio, feito em BPMN, e a aplicação de execução do processo, em BPEL. Consiste em poder alterar o modelo de negócio do processo e que essa mudança seja facilmente replicada para o sistema. E vice-versa também, ou seja, que a alteração de um processo que está sendo executado em um sistema seja automaticamente propagada para o modelo de negócio, ou BPMN (deixando assim a “documentação” sincronizada com o “sistema”). Qualquer semelhança com o problema de atualização dos modelos UML de uma aplicação em manutenção não é mera coincidência.
A boa notícia é que diversas ferramentas de mercado destacam que conseguem fazer esse processo de sincronização “nativamente”. A má notícia é que em muitos casos isso não é tão “nativo” e direto assim. Na prática, quero mostrar que esse round-tripping é um assunto extremamente complexo e que deve ser levado muito a sério.
Vamos a um exemplo prático. Meu analista de negócio mapeou o seguinte processo seguindo a notação BPMN:
É um processo simples. Após o início uma condição é avaliada e o processo segue para um lado ou para o outro. Se o valor do investimento for menos do que 10.000 será enviado para um assessor, se for maior do que 10.000, para aprovador verificar. Se for para o assessor e for de alto risco, ainda assim o aprovador será acionado.
O fato é que, ao passar esse simples fluxograma para o modelo BPEL, “emperramos” e não conseguimos representá-lo nessa linguagem. Esse fluxograma simplesmente não é compatível com o modelo BPEL.
A representação de um processo em BPMN segue um modelo de desenho livre, onde posso abrir diversos “braços” no desenho que, eventualmente, não serão sincronizados ou unidos ao final, serão simplesmente finalizados . Além disso, no BPMN tenho a liberdade de, estando em uma determinada atividade, ir para qualquer outra atividade, mesmo que seja uma anterior no desenho.
Já o BPEL possui um formato bloco-estruturado, onde todo o braço que é aberto precisa necessariamente ser fechado e onde não posso diretamente fazer coisas simples como representar a volta para um ponto passado do processo.
Assim, é conhecido que todo o processo em BPEL pode ser representado graficamente em BPMN, mas nem todo desenho BPMN pode ser representado em uma estrutura BPEL. Não diretamente.
No caso do nosso exemplo, acima veja como ele ficaria para se transformar em BPEL-compliance:
Sim, é isso mesmo, você não está vendo errado. Os dois fluxogramas representam o mesmo processo de negócio, a diferença é que este último foi adaptado para funcionar em uma ferramenta de execução em BPEL. Existem várias outras formas, entretanto, que poderíamos usar para representar esse mesmo processo para se ele ser compatível com BPEL.
Alguns ferramentas que usam BPMN e BPEL, para evitar ter que tratar com esse problema, simplesmente bloqueiam o desenho BPMN impedindo que o usuário monte processos que não sejam compatíveis. Veja o exemplo do desenho abaixo: quando tento criar uma conexão entre a última tarefa e a primeira tarefa, representando uma volta a um ponto passado do processo, o sistema me diz que “preciso colocar as tarefas dentro de um sub-processo em loop”, ou seja, devo utilizar um artifício de sub-processo para poder representar esse retorno. Chato não?
Assim, infelizmente, concluímos que muitos diagramas BPMN não são compatíveis com o modelo BPEL e tem que ser reescritos ou repensados antes de serem automatizados. Como fazer essa transformação? A primeira opção é transforma-se em um expert em BPMN e BPEL e gênio em lógica de processos para conseguir fazer essas adaptações. A segunda opção é verificar alguma das ferramentas de mercado que, de modo bastante discreto, dizem que conseguem fazer essa transformação diretamente . Os mais sérios inclusive divulgam: conseguimos converter automaticamente X% dos diagramas que você possui, os restantes Y% você terá que redesenhar. A terceira e última opção é avaliar muito bem os seus requisitos e verificar se você realmente precisa de BPEL.
De um modo ou de outro, a verdade que fica é que BPMN e BPEL foram criados por instituicões diferentes, grupos de empresas diferentes, em momentos diferentes. Então, essa integração que parece a primeira vista tão natural pode representar uma grande dor de cabeça se não for bem avaliada desde o início.
2 de Outubro de 2007 às 00:40
Rafael Bortolini
Pela segunda vez nos últimos 2 meses recebi uma RFP de prospect onde, no detalhamento de requisitos, estava escrito que a ferramenta de BPM escolhida deveria possuir obrigatoriamente ” recurso para mapeamento de processos em linguagem BPEL”.
Como vimos em posts anteriores, o BPEL não é um padrão para modelagem de processos, e sim um padrão para execução de processos. O BPEL não tem representação visual, com caixinhas e setas ligando os elementos, o BPEL é um arquivo XML com uma lógica e um padrão. Se a sua ferramenta de BPM possui uma editor gráfico para montagem de BPEL, isso é outra história: esse editor assim como a notação utilizada é uma interpretação do fabricante para o modelo BPEL. Outras ferramentas terão outra notação gráfica, a não ser que , enfim, esteja-se utilizando um padrão de mapeamento e desenho de verdade, como o BPMN.
Por isso, em última instância, se eu fosse capacitar alguém em modelagem de processos com BPEL, eu usuaria o bloco de notas e digitaria um monte de tag’s no arquivo XML.
A dúvida que fica é: de onde essas empresas tem tirado essa idéia de que o BPEL é tão mágico assim?
1 de Outubro de 2007 às 23:43
Rafael Bortolini