Quick Tip: Integrando jBPM + JBoss ESB + POP3

Neste quick tip, irei mostrar um passo a passo de como criar um endpoint do tipo E-mail/POP3 no JBoss ESB para realizar a leitura de um e-mail, e realizar o processamento do conteúdo deste e-mail usando um processo de negócio do jBPM. O exemplo, é uma adaptação de um projeto que precisei fazer para auxiliar o desenvolvimento de uma solução para um cliente de governo.

1) Criando um endpoint customizado para o JBoss ESB

O JBoss ESB possui uma grande gama de gateways para os mais comuns tipos de acesso e exposição de serviços que um arquiteto de integração deva precisar. Entre eles, constam endpoints para EJB, File, SOAP, HTTP, JMS, SQL, Hibernate e FTP. A proposta do JBoss ESB para endpoints que porventura ele não suporte, é uma arquitetura simples e plugável para criação de novos endpoints usando JCA (Java Connector Architecture).

A idéia por trás desta solução, é usar um adaptador JCA que esteja disponivel no servidor e criar um endpoint customizado que será disparado pelo adaptador e que irá gerar a mensagem enviada a lista de ações de um dado serviço. Em verdade, um endpoint no JBoss ESB nada mais é do que um tipo de componente que "escuta" um dado evento externo e dispara uma mensagem contendo os dados deste evento.

No JBossESB, para que você possa criar um endpoint personalizado, basta implementar a interface InflowGateway. A listagem abaixo mostra a implementação de um endpoint que é um ouvinte de uma caixa de mensagens POP3.


2) Configurando o Endpoint JCA no arquivo jboss-esb.xml

Feita a implementação do endpoint usando a API do JBoss ESB, é hora de configurar o endpoint JCA no arquivo de configuração do módulo ESB. Edite seu arquivo META-INF/jboss-esb.xml conforme mostrado na listagem abaixo.


Conforme mostrado na listagem acima, a configuração é baseada no uso de um tipo especial de listener chamado de 'jca-gateway'. Neste listener, você deverá informar qual é o arquivo que define seu adaptador JCA. Neste caso, usamos o arquivo 'mail-ra.rar' que é o conector JCA para e-mail do JBoss ESB. A declaração é feita através da propriedade 'adapter'. É necessário informar também qual é a classe que será usada como endpoint para disparar o envio inicial da mensagem para a cadeia de ações. Neste caso, através do atributo 'endpointClass' definimos que a classe usada seria a classe implementada na listagem anterior.

3) Efetuando o processamento das mensagens usando Pipes and Filters

Uma vez que o endpoint tenha feito a escuta do evento externo, e disparado a mensagem inicial para o ESB, é hora de efetuar o processamento da mensagem (agora, uma mensagem do ESB) usando a lista de ações do pipeline do JBoss ESB. A listagem anterior mostra como esta lista foi fundamentada. Primeiro, é feito o recebimento de um arquivo em anexo usando uma classe personalizada chamada 'DownloadListAction' que faz o download de um arquivo texto enviado em anexo ao e-mail.

O arquivo, é nada mais do que um arquivo contendo várias linhas que representam os produtos de um loja virtual, enviados pelos fornecedores a um e-mail especifico da loja. Os campos do produto, são separados por vírgula, formando portanto um arquivo CSV. Para ler este arquivo, usamos o recurso de Smooks do JBoss ESB para realizar o parse do arquivo sem maiores esforços. A listagem abaixo mostra a configuração de Smooks usada.


Depois que o arquivo fora processado via Smooks, é feita o disparo de um processo de negócio chamado de 'recebimento-produtos'. Este processo é um cenário onde é feito um conjunto de tarefas e ações relacionadas principalmente a validação dos produtos enviados pelos fornecedores (feito por um analista especifico) e a atualização de estoque e re-catalogo dos produtos na loja on-line caso os produtos estejam todos corretos, ou, caso exista algum problema, a notificação de retorno aos fornecedores sobre inconcistências nos produtos enviados. A figura abaixo mostra o esboço destes processo de negócio usando jBPM.

Boas Integrações ;)

Integração do JBoss ESB e IBM CICS

Pesquisando na internet, achei uma solução interessante sobre integração de soluções de mainframe com o JBoss ESB. A solução é o LegStar-JBoss ESB, atualmente hospedado no Google Code. Através de uma arquitetura flexível e plugável baseado em filas do Websphere MQ, e motores de eventos do JBoss ESB para JMS, é possível realizar o acesso de envio de dados e recebimento de dados no CICS.

Para saber mais sobre a solução, clique neste link. O líder técnico do projeto JBoss ESB Mark Little, em conjunto com um dos criadores da solução LegStar fizeram também um post muito legal no site da InfoQ sobre o assunto. Para lê-lo, clique aqui.

Boas Integrações ;)

Quick Tip: BPM é Melhoria Contínua. E ai?

Neste quick tip, irei discorrer uma questão que acredito que 98% das pessoas envolvidas em BPM se perguntam. Todos falam que BPM têm a ver com melhorar continuamente um processo de negócio através de análise, mas como isso ocorre na prática? Isto é, melhorar continuamente processos é uma frase bonita e pomposa, mas como isso é feito na prática? Alguém já o fez? Vou mostrar alguns exemplos aqui para responder a tais questões.

Patterns? Sim, isso também "dá pra fazer" em BPM

Isso mesmo. Em BPM existem design patterns que auxiliam a confecção de processos de negócio. Assim como o GOF, os padrões de desenho sobre processos estão catalogados num livro. Dois deles que considero essenciais são o Essencial Business Process Modeling da O'Reilly e o Business Process Management - Concepts, Languags and Architectures da Springer.

Exclusive Choice Pattern

Este pattern fala sobre o cenário onde você deve realizar uma decisão num processo. Sabemos que decisões são cenários clássicos em processos de negócio, mas existem algumas questões que refletem boas práticas e melhorias no processo. Por exemplo, Toda vez que uma decisão é empregada, é interessante que além dos possiveis caminhos que a decisão tomará, se tenha um caminho genérico para avaliação da decisão. Em processos de negócio, muitas das vezes não podemos prever todos os possíveis casos de um evento, e nos primeiros estágios de entrega daquele processo, quando ele ainda nos é obscuro, é interessante registrar o caso onde nenhuma das opções foi tomada. A experiência fala: Isso, sempre vai acontecer nos primeiros estágios de um processo.

Parallel Split and Syncronization Patterns

Um caso comum quando usuários iniciantes de BPM começam a modelar processos, é tentar colocar as maioria das atividades (etapas) de um processo, numa ótica sequencial. Quando mais sequencial estiver, menos complexo um processo fica. É assim que as pessoas iniciantes de BPM pensam. Em alguns casos, isso pode ser interessante, principalmente aqueles onde uma atividade, têm como pré-condição outra atividade.

De fato, a sequência de atividades de um processo denota dependência. Se num processo de aquisição de ticket para uma viagem corporativa, eu digo que o primeiro passo é a solicitação do ticket e o segundo é a analise do ticket, estou dizendo que o segundo passo não se dá sem o primeiro. Ele é a sua pré-condição. Atividades sequenciais são interessantes, mas tenham em mente esta questão quando modelar. Voltando ao problema, as pessoas as vezes esqueçem do fato da pré-condição (que deve ser o motor para a sequenciação) e se empolgam em colocar tudo como uma grande sequência de atividades. O problema disso é a alocação de recursos.

Sabemos que num processo, que realiza as atividades dele hora serão pessoas, hora serão um mecanismo computacional. Seja o recurso qual for, através da sequenciação de tarefas, você aloca recursos por um período de tempo. Se três atividades não tiverem pré-condição umas com as outras, por que colocas como em sequência? Imagine por exemplo, num processo de compra de produtos on-line, que existam as atividades 'Revisar Pedido', 'Checar Crédito' e 'Checar Estoque', todas estas, atividades que são disparadas através do evento 'Finalizar Compra' feito pelo ator comprador. Essencialmente, todas estas atividades levam um tempo para serem executadas. Por exemplo, imagine que a atividade 'Revisar Pedido', notadamente uma tarefa humana, seja feita em média em 2 horas.

Já a atividade 'Checar Crédito' feito também por uma pessoa, seja feito em média em 1 hora. E, finalmente, a atividade 'Checar Estoque' feita por uma pessoa leve 3 horas. Se estas atividades forem postas sequencialmente, estamos falando que, esta etapa da compra, levará 6 horas para ser completada, pois a tarefa de 'Checar Estoque' só poderá ser executada quando as demais forem concluidas. Pior ainda, na execução de um processo, os recursos são aprovisionados para atender aquela execução (Thread), neste caso, apenas de 6 em 6 horas instâncias daquele etapa poderão ser feitas. Ou seja, o processo não irá escalar.

Uma forma de otimizar este cenário, é reconhecer que nem tudo é sequencial, e coloca-las para serem executadas em paralelo. Normalmente, isso é feito através de mecanismos como Fork-Join ou, no BPMN, usando o Parallel Split and Syncronization. Aplicando esta solução (pattern) no cenário descrito, poderiamos tirar a média dos valores de tempo, e este seria o tempo gasto por esta etapa, algo em torno de 2 horas. Diminuir o tempo de uma etapa e melhorar o uso efetivo dos recursos alocados no processo, é efetivamente um caso típico de melhoria de processos.

Boas Entregas de Valor ;)

BPM na Prática: Como quebrar o Medo?

Se ainda existe até hoje um assunto que assusta as pessoas quando o assunto é SOA, sem dúvida alguma este assunto é BPM. A razão disso é que, diferentemente dos demais assuntos relacionados a SOA, BPM não é uma disciplina técnica. Ela não é composta de um conjunto de conceitos ou tecnologias que facilmente são dominados através da leitura de livros aplicados, e, principalmente, ela não é uma disciplina que possa ser aprendida apenas com um exemplo; são necessários vários exemplos diferentes até que alguem se sinta seguro quando a BPM. Neste post, irei falar um pouco sobre este fênomeno, e o que tenho aplicado de técnica em meus projetos para combater isso.

Explicando o Mito ...

Apesar de ser um assunto que assusta várias pessoas, a teoria de BPM em si não é complicada. Sob uma ótica simplista, podemos definir BPM como um conjunto de técnicas que quando aplicadas, mapeiam as etapas de concepção, desenho, execução e monitoração de processos organizacionais. Fazendo uma analogia, é como se tivessemos um conjunto de técnicas para as disciplinas do RUP de requisitos (concepção de processos), análise e desenho (desenho dos processos), implementação (execução de processos) e tivessemos uma disciplina auxiliar cujo propósito seria de monitorar o comportamento e execução dos processos em tempo de execução, não para garantir que o mesmo esteja funcionando de acordo com os requisitos, mas para garantir que o mesmo dê feedback na forma de números, sobre cada passo do negócio de uma organização.

Dada a definição, a pergunda ainda paira no ar: Por quê, algo aparentemente tão simples como esse, é motivo de receio e duvidas para as pessoas de TI? Bem, a resposta curta é que BPM, ao contrário de tudo em TI, é algo que é mensurado através de resultados. Uma coisa, é você criar uma solução que um dado setor de uma empresa solicitou. Outra coisa, é a TI identificar falhas no processo gerencial e tático de uma organização, e propor uma melhoria no mesmo. A diferença básica é como a TI se posiciona quanto aos problemas da empresa, de forma reativa ou pró-ativa. Quando a TI é apenas reativa (espera que demandas guiem seu trabalho) ela não agrega valor e é apenas unidade meio para um objetivo de negócio. Quando ela se torna pró-ativa, ela obtêm maior visibilidade em nivel organizacional e passa a ser um mecanismo tático para oportunidades de negócio. Mas é ai que se diferenciam os homens das crianças ...

Qual é o problema na prática?

O fato é, pessoas de TI têm medo de ousar, de dar a cara a tapa, de propor algo que será motivo de risadas pela alta direção. A TI gosta de estar na zona de conforto, sendo apenas reativa. Mais de 40 anos de feedback neste setor comprova este fato. Ninguem gosta de colocar um alvo nas costas, pois quando as coisas dão errado, ele será o primeiro que irá levar um tiro. Escolas ágeis pregam valores humanos muito interessantes para questões como essas, e, se algum guru do Agile tivesse que dar um conselho sobre como agir nestas situações, esta pessoa diria: Primeiro, tenha humildade de tentar e potencialmente errar, segundo, tenha coragem para agir.

Através destas duas técnicas, é que uma iniciativa de BPM pode dar realmente certo numa organização. Claro, a coragem a ser aplicada deve ser comedida, você não deve também sair fazendo as coisas só por fazer e esperar que dê certo. Você deve criar um ciclo curto de realizar, mensurar, dar feedback e aprender com os fracassos e sucessos, técnica essa que costumo chamar de RATL, sigla de Realize + Analyse + Talk + Learn. Ciclos de RATL devem ser curtos, para que você possa controlar o impacto que sua iniciativa pode causar. Como diz o didato, quanto maior o salto, maior a queda. O mesmo vale para o RATL. Se você investir somente em RATL grandes, você terá muito mais o que dar feedback e aprender do que se fosse um RATL curto.

Colocando o RATL em prática

Uma abordagem BPM deve ser antecedida de um plano de RATL. Assim como em processos iterativos e incrementais, você deve criar um plano de iterações para o RATL. O primeiro passo é elencar os possiveis casos de RATL. Casos de RATL são na verdade situações candidatas de uma organização para automação. Lembrando que a palavra automação aqui não sgnifica automatizar via software, portanto, esqueça por hora fírulas de ESB's, Web Services, UDDI's, REST's, etc. Essa parafernalha técnica mais atrapalha do que ajuda quando você mensura um plano de RATL. Um bom consultor SOA deve lhe ajudar a dosar quando a parte técnica deve entrar ou sair num caso de RATL.

Elencado a lista de casos de RETL, você deve priorizar esta lista. Os critérios de priorização devem ser: risco (RSC), custo (CST), importância (IPT) para o negócio e fato organizacional (FAO) nesta ordem. Aredito que apenas o ultimo deva ter parecido estranho correto? Vou explicar. Um fato organizacional é um caso de ataque de uma organização que já é meta da empresa ou é um projeto já conhecido que espera apenas pela execução. Ou seja, aquilo que já é fato de acontecer.

Ao contrário dos que métodos iterativos e incrementais pregam, os casos que apresentam maior risco necessariamente não deve ser os primeiros atacados. A mitigação de riscos não é importante numa abordagem BPM e sim, a entrega de valor. Se um caso de RATL apresenta um risco alto de dar errado, ele não deve ser primordial, pois o compromisso de entrega é muito mais importante do que provar que você conseguiu resolver o risco. Quando um caso de RATL deve ser atacado primeiro? Quando ele tiver consigo outros atributos de qualidade como importância para o negócio ou custo baixo.

Assim que você tiver uma lista de casos de RATL, você deve criar colunas que representem os atributos RSC, CST, IPT e FAO, e, para cada uma destas colunas, você deve escrever um valor que represente um nível de ocorrência daquele atributo, algo como 0 - Baixo, 5 - Médio e 10 - Alto. Feito isso, use um bom algoritmo de priorização da lista, baseado nos valores escritos na coluna. Quando você consegue chegar num número, fica fácil priorizar, pois números são que nem fatos, não deixam margem para dúvidas. Uma analise, preferencialmente deve ser baseado em números, e não em palavras.

Para efeitos de conferência, segue abaixo um modelo esquemática de como você deve aplicar os atributos de qualidade nos casos de RATL:

• RSC: Os casos de RATL com risco maior devem ser postergados ao máximo
  
• CST: Os casos de RATL com custo maior devem ser postergados ao máximo
• IPT: Os casos de RATL com maior importância devem ser atacados primeiro
• FAO: Os casos de RATL que forem fato na organização deve ter o mesmo peso que o IPT.

Ao realizar um caso de RATL, é de suma importância que todas as etapas sejam fielmente cumpridas. A experiência fala que normalmente, apenas as etapas de realizar e analisar são feitas. O feedback normalmente torna-se opcional porque dar a má noticia ninguem quer, e a etapa de aprender quase ninguem faz, porque a petulância e o orgulho não deixam que isso aconteça.

A técnica RETL não é documentada em lugar algum. Ela é na verdade o reflexo do que eu já vivi em projetos que precisei aplicar BPM. Ela também não surgiu do nada porque sou alguma espécie de gênio. Ela me foi inspirada principalmente na técnica ATAM (Architecture Trade-Off Analysis Method) documentada no livro Evaluating Software Architectures e claro, no modelo iterativo incremental do RUP. Maiores informações da técnica ou formalização da mesma como um estudo de caso posso estar operacionalizando como um serviço, como já feito em algumas empresas de Minas Gerais. Me procure em particular para detalhes disso.

Boas Entregas de Valor ;)

Service-Oriented Architecture with Java

Me foi solicitado recentemente pela diretora de marketing da Packt Publishing que fosse divulgado neste blog um livro que a mesma está lançando sobre SOA. O livro é o Service-Oriented Architecture with Java, e fala sobre como aplicar alguns conceitos de desenvolvimento de serviços usando a plataforma JEE como base. Não pude ler o livro completamente, mas é bem acabado e bem formatado.

O livro, apesar de ser extremamente voltado apenas a Java, fala com grande exaustão sobre os detalhes técnicos sobre web services em Java, WSDL, UDDI e demais tecnologias laterais do Technical SOA. Como guia técnico sobre Java, é um livro bem interessante, mas não espere muitos detalhes sobre SOA em si, detalhes estes que, conforme sempre defendo neste blog e em palestras, vão muito mais além do que detalhes técnicos. No mais, é um bom livro técnico. Fica ai a dica!

Cordialmente,

RF