Um BPMN para cada propósito de modelagem de processos

Há alguns anos, quando a Business Process Modelling Notation (BPMN) ainda estava na versão 1.1, os pesquisadores Michael zur Muehlen e Jan Recker escreveram o artigo How Much Language is Enough? Theoretical and Practical Use of the Business Process Management Notation?, analisando processos de negócio modelados com esta notação e questionando o quanto alguns elementos eram realmente necessários.

De lá pra cá, milhares de novos processos de negócios foram desenhados com BPMN, e a notação aumentou seu toolkit com muitos novos elementos, em especial com a chegada da versão BPMN 2.0 (veja especificação publicada em jan/2011 aqui).

Você olha para as páginas e páginas da especificação BPMN e se pergunta “mas afinal, preciso usar todos esses elementos?”. A resposta está no propósito para o qual você está desenhando o processo.

 Um dos aspectos que mais me agrada no BPMN é o de que ela oferece uma ampla gama de elementos para a modelagem de processos de negócio que varia de acordo com a etapa do ciclo de vida de um projeto BPM, e que permitem que um processo possa ter a sua documentação progressiva, agregando informações ao fluxo à medida que um processo passa pelas etapas do projeto.

Ciclo de vida BPM - Extraido do material de treinamento da iProcess - Direitos reservados.

Para cada etapa do ciclo de vida de um projeto BPM, um conjunto diferente de componentes de modelagem de processo BPMN devem ser utilizados:

  1. Identificação e Mapeamento de Processos

Nesta etapa é gerado o modelo do processo chamado AS IS.

O objetivo da modelagem AS IS é obter uma formalização sobre o fluxo do processo de negócio como é realizado na situação atual em que é executado na organização. Os aspectos a serem priorizados nesta documentação de processo são: que atividades são realizadas (tarefas), a sequencia entre estas tarefas, o caso feliz do processo e as condições que levem a cenários de negócio alternativos.

Para esta modelagem, os elementos de BPMN mais relevantes são: Pools, Lanes, Activities,  gateways do tipo parallel e exclusive data-based, eventos de início e fim. Podem ser utilizados componentes de annotations para apoiar no entendimento do modelo.

Este modelo de processo em geral tem dois propósitos: A) servir de documentação para conhecimento do processo atual; B) servir como insumo para a próxima etapa do ciclo de vida de um projeto BPM.

Por isso, esses modelos tendem a possuir uma vida curta. Minha recomendação nesta etapa é: não invista muito tempo na documentação AS IS se sua organização construiu este modelo especialmente como insumo para a próxima etapa. No decorrer das minhas atividades em consultorias já vi muitas organizações investirem  uma energia muito grande em um processo AS IS, quando o objetivo real do projeto era buscar a melhoria do processo através do redesenho TO BE.

  1. Redesenho de Processos

Nesta etapa é gerado o modelo do processo chamado TO BE.

Ele é uma evolução do modelo anterior (AS IS), no qual são reavaliadas as questões de negócio envolvidas buscando-se, através de melhorias culturais e organizacionais, maior eficiência na execução do processo.

O modelo de processo TO BE também possui um foco sobre o processo de negócio, e por isso os mesmos tipos de elementos BPMN podem ser utilizados nesta etapa:  pools, lanes, activities,  gateways do tipo parallel, inclusive e exclusive data-based, eventos de início e fim. O processo começa a ser melhor detalhado em procedimentos, e mais atividades podem surgir para apoiar a realização de algumas tarefas, notificações de atraso, etc. Assim, convém considerar utilizar subprocess para agrupar tarefas com objetivos específicos e possível reuso. Eventualmente, alguns tipos de eventos como timer, link e message podem ser interessantes de serem incorporados no modelo se forem beneficiar o seu entendimento.

Alguns projetos de BPM  partem diretamente para a implantação do processo TO BE, com a realização de ações de gestão de mudanças em nível organizacional e cultural para beneficiar-se das  melhorias sugeridas. Outros projetos seguem para a etapa seguinte do ciclo, no qual ao redesenho de negócio são agregadas melhorias tecnológicas.

  1. Modelagem Técnica

A modelagem técnica busca proporcionar um olhar da análise de sistemas sobre o processo, de forma a identificar como agregar maior valor ao processo com uso de recursos de tecnologia. Pode ser  a aquisição de produtos que apóiem em atividades específicas do processo, soluções que possibilitem a integração de diferentes sistemas para prover melhores informações e eliminem tarefas humanas que não agreguem valor ao processo, customização de ferramentas existentes para melhorar a realização das tarefas, até mesmo a adaptação do processo para a automação através de um BPMS.

Esta modelagem técnica é a transformação do processo TO BE no modelo TO DO.

Porque há mais informações a serem atribuídas ao modelo do processo, os elementos de BPMN utilizados podem ser mais específicos, usando-se, além dos já citados, também eventos do tipo signal, conditional, exception, escalation, gateways do tipo event-based, componentes do tipo data objects, e a especificação dos tipos de tarefas (manuais, humanas, automáticas…).

  1. Implementação

Se um processo de negócio for ser implementado através de utilização de um BPMS, o modelo TO DO irá requerer um detalhamento técnico ainda mais refinado, possibilitando agregar ao processo informações específicas para a interpretação do motor de processo. Este modelo de processo, que será interpretado pelo sistema, é chamado informalmente de TO RUN. O modelo TO RUN utilizará muitos elementos que a maior parte dos usuários da notação BPMN sequer virá a usar em seu trabalho, mas que serão requeridos para fornecer ao sistema detalhes relevantes para a sua execução automatizada, tais como controles de transação, compensação e tratamentos de erros.

Como se pode ver, existe um grupo de elementos de BPMN apropriado para cada etapa do ciclo de vida de projetos BPM.

Conhecer o potencial desta notação é o primeiro passo para se construir diagramas de processos claros, legíveis para todos os participantes e eficazes na representação do fluxo de atividades de acordo com o propósito do modelo.

Exportação e importação de Objetos do Oracle BAM

A interface padrão do Oracle BAM permite criar e salvar objetos diretamente no servidor do Oracle BAM. Desta forma, não é necessário salvar os objetos em arquivo na máquina local.

Porém, em determinados momentos é necessário exportar os objetos criados no servidor atual para outro servidor (ex: para testar os dashboards criados no servidor de desenvolvimento no servidor de testes).

Neste post, aprenderemos como exportar e importar objetos criados no Oracle BAM. Todos os componentes do Oracle BAM, podem ser exportados para um arquivo XML através do comando ICOMMAND.

iCommand

O iCommand é um utilitário que permite importar e exportar os diversos componentes do Oracle BAM através do prompt do DOS.

Exemplo de comando para exportar:

 icommand type=export name=myComponent type=dataobject file=myFile.xml

Exemplo de comando para importar:

 icommand type=import file=myFile.xml

Procedimentos antes de executar os comandos de importação e exportação:

  1. Se necessário, setar o Java Home: export JAVA_HOME=/home/oracle/Middleware/home_soa11g/jdk160_11
  2. No servidor do BAM, entrar no diretorio /home/oracle/Middleware/home_soa11g/Oracle_SOA1/bam/bin e executar o comando de exportação ou importação
  3. Caso os reports a serem exportados tenham drill, os reports referenciados devem ser exportados separadamente, e importados sempre ANTES dos reports que os referenciam. Do contrário, irá ocorrer a mensagem “DrillAcross Destination Report not found.”

Mensagens de erro comuns:

  1. Se o iCommand retornar o erro “BAM-01261: Cannot connect to the Oracle BAM Server”, verificar no arquivo /home/oracle/Middleware/home_soa11g/Oracle_SOA1/bam/config/BAMICommandConfig.xml se o parâmetro “ADCServerPort” está setado com a porta no qual o BAM foi efetivamente instalado (o valor padrão é 9001). Caso seja diferente, ajustar para a porta correta e tentar novamente.

Exemplos diversos:

Exportação de reports:

Exportando a pasta “Meus Relatórios” (e todos os relatórios dentro dela):

./icommand -cmd export -name ”/private:weblogic/Report/Meus Relatórios/Coleções” -type folder -file teste.xml

Exportando a pasta “Relatórios compartilhados” (e todos os relatórios dentro dela):

./icommand -cmd export -name ”/public/Report/MainFolderInShared” -type folder -file C:\FolderExportTest2.xml

Exportando um relatório privado:

./icommand -cmd export -name ”/private:bamadmin/Report/MyReport” -type report -file C:\MyReport.xml

Exportando um relatório da pasta “Relatórios Compartilhados”:

./icommand -cmd export -name ”/public/Report/SharedReport” -type report -file C:\SharedReport.xml

Exportação de Data Objects:

Exportando um Data Object da pasta raiz:

./icommand -cmd export -name TestDataObject -file “C:\TestDataObject.xml”

Exportando um Data Object de dentro de uma pasta específica:

./icommand -cmd export -name ”/Samples/Call Center” -file “C:\CallCenter.xml”

Exportando uma pasta de Data Objects inteira:

./icommand -cmd export -name ”/public/DataObject/Colecoes/Desempenho por Marcas” -type folder -file objects.xml

Importação de objetos (reports, data objects, etc):

./icommand -cmd import -file /home/oracle/Middleware/home_soa11g/Oracle_SOA1/bam/bin/teste.xml

Para maiores informações, consulte:
http://download.oracle.com/docs/cd/E12839_01/integration.1111/e10224/bam_app_icommand.htm

Construção de serviços simulados utilizando Java

No desenvolvimento de sistemas com base na arquitetura orientada a serviços (SOA), frequentemente nos deparamos com a necessidade de utilizar serviços já existentes na infraestrutura do cliente, mas que não estão disponíveis no nosso ambiente de desenvolvimento local. Ainda, na maioria das vezes não temos a possibilidade de instalar localmente tais serviços devido a dependências destes com outros serviços, bibliotecas ou outros componentes que somente estão disponibilizados no ambiente integrado do cliente.

Nestes casos, podemos fazer uso de um recurso muito útil: a construção de versões simuladas de serviços, ou mocks como são chamados em inglês. A ideia é podermos disponibilizar no ambiente local um serviço que exponha o mesmo contrato WSDL que o serviço original, ou seja, as mesmas operações e tipos de dados.

Uma das alternativas para a criação de um serviço simulado é implementá-lo observando as operações e os tipos de dados expostos pelo serviço original e recriando-os completamente, por exemplo, utilizando Java e JAX-WS. Porém, para os casos em que temos acesso ao contrato WSDL do serviço original, é mais simples e seguro construirmos o mock diretamente a partir dele.

Vamos então demonstrar como construir um serviço simulado em Java, a partir do contrato de um serviço original, em um passo-a-passo utilizando o Oracle JDeveloper.

Primeiramente, para exemplificar, vamos supor que estamos desenvolvendo um sistema que deverá invocar o serviço de cálculo de prazo e custo dos Correios, mas o serviço real somente deverá ser utilizado quando a solução for integrada no ambiente do cliente. Logo, em tempo de desenvolvimento, devemos construir um mock do mesmo.

1 – Criação da aplicação

Comece criando uma nova aplicação genérica no JDeveloper:2 – Criação de novo projeto

Crie um novo projeto genérico a partir do passo seguinte do wizard de nova aplicação ou a partir da opção de Novo Projeto, se você estiver criando um segundo mock dentro de uma aplicação já existente no JDeveloper.

Não é preciso selecionar nenhuma tecnologia para o projeto, podendo-se encerrar o utilitário de criação do novo projeto clicando no botão Finish.

3 – Criação do webservice

Clique com o botão direito no projeto criado e escolha a opção New. Na janela de opções, selecione no lado esquerdo a categoria “Web Services” e no lado direito “Java Web Service from wsdl”.

No wizard de criação do serviço, escolha como plataforma “Java EE 1.5, with support for JAX-WS RI”:

Clique em Next. Neste momento é preciso abrir o arquivo WSDL do serviço original. No nosso exemplo vamos especificar a URL para o WSDL do serviço original dos correios, que está disponível em http://ws.correios.com.br/calculador/CalcPrecoPrazo.asmx?WSDL (marque para criar cópia local do contrato).

Clique em Next novamente, especifique o nome do pacote Java e finalize o wizard. Pronto! Está criado o novo serviço mock, expondo o mesmo contrato WSDL que o serviço original. Deverão ter sido criadas classes Java para todos os tipos de dados envolvidos nas mensagens de entrada e saída das operações, bem como a implementação do serviço com as devidas anotações.

Como passo final, edite o novo arquivo XXXImpl.java (onde XXX corresponde ao nome do seu serviço simulado) para codificar o retorno de dados de teste nas operações expostas pelo serviço, como no exemplo a seguir:

Agora basta fazer o build do arquivo .war do serviço e disponibilizá-lo em seu servidor de aplicações local. Veja os valores que setamos sendo retornados em um teste de invocação do serviço simulado, depois de disponibilizado em um servidor Weblogic 11g:

Respostas sobre o webinar: A orquestração para integração de sistemas

Recentemente tive a oportunidade de apresentar um webinar pela iProcess sobre “A orquestração como instrumento para integrar sistemas”, que apresentou conceitos de SOA, BPEL e orquestração de webservices, além de apresentar uma breve introdução sobre como desenvolver projetos de integração utilizando orquestração.

Você pode rever o webinar no canal do Youtube da iProcess ou nos links abaixo:

Ao final do webinar recebemos algumas perguntas dos nossos participantes. Procurei resumir abaixo em principais idéias, levando em consideração que alguns assuntos são amplos e seria impossível esgotar o argumento nas respostas. Deixo aos leitores completarem com seus comentários e percepções.

1) Quais são as principais vantagens da utilização de BPEL em relação ao desenvolvimento de um serviço orquestrador, escrito em Java por exemplo?

Entendo, com essa pergunta, que estamos falando da utilização de um produto que implementa o SOA/BPEL. Vou pegar como exemplo o Oracle SOA Suite 11g, que inclusive foi desenvolvido em Java.

Falemos, então, de vantagens e desvantagens da utilização desse tipo de produto.

VANTAGENS

  •  a principal vantagem é poder contar com uma infraestrutura de middleware pronta (estilo caixa-preta) que possibilita o rápido desenvolvimento de soluções complexas, além de incluir o controle de instâncias de curta e longa duração, a disponibilização de adaptadores para conexão direta a diferentes serviços (banco de dados, AQ, MQ, JMS, arquivos, webservices, etc), monitoramento do ambiente, ferramentas de configuração, etc;
  • a possibilidade de implementar rapidamente processos de negócio bem definidos;
  • no caso do Oracle SOA Suite, é possível utilizar toda a infraestrutura disponibilizada pela suite, que inclui, além do BPEL, componentes de business rules, tarefas humanas (human task), mediator e BPM.

DESVANTAGENS

  • quando trabalhamos em projetos que exigem alta-disponibilidade, grandes quantidades de operações por minuto, cloud-computing, grande quantidade de serviços, entre outros desafios, o middleware deixa de ser uma caixa-preta e passa a ser uma caixa-cinza, exigindo do time de arquitetura, desenvolvimento, infraestrutura e suporte um conhecimento profundo do produto, o que nem sempre é fácil;
  • o custo do produto costuma ser alto;
  • o middleware é um produto que inclui muitas camadas (sistema operacional, máquina virtual [Java, por exemplo], banco de dados, conexões diversas, além de utilização de memória, disco, processador, temperatura). Em ambientes de produção tudo isso deve ser controlado. Nem sempre é fácil identificar rapidamente quando um problema ocorre, exigindo novamente grande conhecimento do produto.

 

 

2) Quando vai ser feita a implantação de uma orquestração, espera-se que já esteja implementada uma arquitetura orientada a serviço?

Não necessariamente. Como foi comentado durante a apresentação, uma boa orquestração prevê a descrição do processo de negócio que será orquestrado e todos os pontos de orquestração bem definidos.

Porém já tivemos casos de orquestração que utilizavam somente troca de arquivos, conexões a banco de dados e filas e acesso direto a API’s de outros sistemas utilizados pela empresa, sem que existisse, de fato, uma arquitetura orientada a serviço na empresa.

É certo, porém, que os projetos que podem contar com esse pré-requisito acabam utilizando melhor todos os recursos que a orquestração dispõe, desde o controle das instâncias, erros e execuções até o completo monitoramento do ambiente como um todo.

3) É comum construir orquestração de serviços e “expor” essa orquestração dentro de um ESB?

Já atuei em projetos que nem sequer utilizavam ESB e outros que expunham sempre um serviço no ESB. Na minha visão isso depende da arquitetura que será utilizada no projeto.

4) Gostaria que o Eduardo comentasse mais sobre os papéis dos projetos e a interação entre eles.

Durante a apresentação utilizamos a imagem abaixo:

Falando um pouco sobre a função de cada um desses papéis:

  • Arquiteto de integração: ele será responsável por desenhar toda a solução técnica da integração e definir quais serão os padrões utilizados. É papel do arquiteto, também, desenhar os diagramas de componentização das integrações.
  • Analista de processo: irá trabalhar junto aos usuários de negócio na definição dos processos que serão orquestrados e na definição da estrutura de dados.
  • Desenvolvedores e técnicos de infraestrutura que farão o desenvolvimento das integrações propriamente ditas.

Nos projetos nos quais trabalhei a figura do arquiteto foi essencial. Ele deve ter clara a visão do todo e entender realmente o problema, definindo quais recursos de TI serão utilizados na integração. Além dele, o analista de processo tem um papel fundamental na compreensão e na documentação dos processos que serão automatizados e orquestrados, cabendo aos desenvolvedores uma boa implementação e aos técnicos de infraestrutura a garantia de que o middleware estará bem configurado para suportar a solução.