jBPM 4.3: Decisões baseadas em Drools

Foi lançado recentemente a mais nova versão do JBoss jBPM, e com este lançamento, vários recursos novos e interessantes foram incorporados, além de claro, correções e melhorías de falhas encontradas nas versões anteriores. Estive testando nos últimos dias esta nova versão, e gostaria de compartilhar com vocês um recurso que achei super interessante: A integração do jBPM com o Drools para resolver questões de decisões.

Vamos ver como este recurso funciona. A idéia básica do recurso é fazer com que um conjunto de regras do Drools possa decidir qual transição aplicar num grafo de processo em execução. Nas versões anteriores, você podia fazer de três formas: Usando um Decision Handler (classe Java que implementa a lógica da decisão), uma expressão ou baseado no valor de uma variável booleana. Em todos os três casos, são técnicas que envolvem algum conhecimento de programação o que impossibilita que pessoas não técnicas possam definir regras de decisão.

O recurso da integração do Drools veio justamente para sanar este problema. Agora, você pode dar a possibilidade a pessoas não técnicas definirem regras de fluxos de processos, usando Drools para definição (aliado a bons recursos de DSL) ou usando tabelas de decisão baseadas em planilhas do Excel ou OpenOffice.

Um bom exemplo é melhor que mil palavras!

Vejamos como funciona o recurso com um exemplo. Imagine que você define uma meta de final de ano, daquelas metas que depois que você estoura um champagne e brinda com todos o ano que sai e o ano que entra, você promete a si mesmo. Uma das metas que você estabelece é que irá cuidar mais da saúde e ser mais zeloso quanto ao seu peso. Para ajudar a decidir que ação tomar, você define um processo de negócio usando jBPM como o mostrado abaixo:

Para criar este processo, usei o designer do jBPM que acompanha a instalação do jBPM 4.3. Consulte o documento "User Guide" do jBPM que fala como instalar este designer numa distribuição do Eclipse. A dica para este processo, é que ao invés de usar um "decision" tradicional (como sugere o ícone do designer) eu usei um "rules-decision", que é efetivamente o tipo de decision que integra com o Drools. A listagem abaixo mostra meu arquivo "meta-anual.jpdl.xml":

Repare que no "rules-decision" não há nenhuma informação sobre qual transição o processo irá tomar. isso se dá porque a decisão será feita por um punhado de regras do Drools. Crie um arquivo chamado "regras-peso.drl" e entre com o seguinte conjunto de regras:

Na listagem acima, existem três regras distintas que falam sobre que caminho tomar de acordo com o valor do seu peso. Repare que o peso é representado por uma variável global chamada "pesoAtual" que é definida junto com a variável "outcome", usada para definir qual transition do jBPM tomar. Estas variáveis serão injetadas automaticamente pelo jBPM quando uma instância do processo for criada.

Feito isso, faça o deploy deste processo no seu servidor de processos. Com o JBoss Application Server no ar, crie um arquivo JAR que contenha os arquivos "meta-anual.jpdl.xml" e "regras-peso.drl" e mude a estensão deste arquivo para BAR. Depois, copie este arquivo para a pasta deploy do seu JBoss. O scanner do jBPM irá identificar este pedido de deployment e irá fazer o registro deste processo na engine do jBPM.

Testando o exemplo usando o componente ProcessEngine

Para testar este processo, iremos criar um pequeno programa Java que irá conectar com o servidor de processos e solicitar uma instância do processo que foi registrado. Crie um programa Java conforme mostrado abaixo. O programa usa a API do jBPM que também acompanha a instalação da versão 4.3 do mesmo.

Note que solicitamos uma nova instância do processo passando uma variável chamada "pesoAtual" . Esta variável será inserida no contexto do Drools e será acessível via variável global conforme vimos no arquivo de regras. Note também que solicitamos duas sinalizações. A primeira orienta o grafo do processo para se posicionar na atividade "Respirar Fundo" e a segunda orienta o posionamento da próxima atividade que é exatamente a decisão baseada em Drools. Quando você executar este programa, você poderá ver no BPM console do jBPM que uma instância do mesmo está realmente em execução:

Eu executei este processo passando meu peso atual, e pra minha desgraça, o processo me mandou ir direto para academia. Veja o resultado de clicar no botão "Diagram":

Legal heim? a grande sacada é deixar todos os seus arquivos do Drools no root do classpath do seu arquivo .BAR e tudo será linkado automaticamente pra você. Nenhum código usando a API do Drools precisou ser escrito, assim como nenhum código de deployment do jBPM.

Bom, agora que mostrei como as coisas funcionam e que a integração realmente funciona, preciso desligar o notebook e me preparar para ir pra academia, pois segundo o jBPM, eu estou muito gordo ;-)

Boas Decisões!

Microsoft Azure com suporte a Ruby on Rails

A plataforma de cloud da Microsoft está agora investindo pesado em soluções open-source para agregar um público cada vez maior. A mais nova façanha é o suporte a RoR. Dentre as soluções já suportadas, encontran-se MySQL, MemCached, MediaWiki e o Tomcat. Leia mais em:

http://blogs.zdnet.com/microsoft/?p=4672

"Twittando" via um Banco de Dados SQL

Imagine o seguinte cenário: Você quer realizar um acesso ao Twitter para atualizar o status de alguma conta, mas a única coisa que você tem em mãos é o acesso a um banco de dados. Você não têm acesso a internet devido a restrições de firewalls e DMZ's e portanto não pode acessar a API REST do Twitter. E você usa uma linguagem que não possui uma API nativa para tal, como é o caso do Borland Delphi 7 baseada em Object Pascal.

Imaginou? Então vamos ver como criar uma solução de integração que possa satisfazer este cenário. Para isso, iremos usar o JBoss SOA Platform da Red Hat como middleware de integração (EAI) e o JBoss Operations Network como plataforma de gerenciamento e monitoramento do JBoss.

Criando um pool de conexões do JBoss usando JON

A primeira coisa a se fazer é criar um banco de dados e uma tabela que conterá os pedidos de requisição para o Twitter. A idéia é que alguma aplicação faça um INSERT nesta tabela contendo a mensagem a ser enviada para a conta do Twitter. Para este exemplo, irei usar o banco de dados MySQL. Crie um banco de dados chamado "twitter-db" e crie uma tabela nele como mostrado na listagem abaixo:

Agora é hora de criar um pool de conexões para que o SOA Platform possa monitorar o banco de dados. Para isso, entre no seu servidor JON e acesso o servidor do JBoss SOA Platform:

Clique na guia "Inventory" e seleciona a criação de um novo datasource. Na lista de templates, escolha "Default template" e clique no botão "Continue". Será apresentado a janela de edição dos parâmetros do datasource. Configure-os como mostrado na figura abaixo:

Clique em "Submit" para que o JON possa criar o arquivo XML que define o novo pool de conexões. Dentro de alguns segundos, o SOA Platform irá detectar o novo datasource e colocar no ar para fins de acesso e monitoração, graças ao recurso de Hot Deployment nativo do JBoss.

Criando um projeto para o ESB

Usando o JBoss Developer Studio, crie um novo projeto e chame-o de "twitter-adapter". Neste projeto, iremos fazer uso da API do Twitter4J disponível livremente para download. Baixe a ultima versão do Twitter4J e descompacte o pacote em qualquer lugar do seu computador. No JBoss Developer Studio, crie uma nova biblioteca Java chamada "Twitter4J Libraries" e adicione-a ao projeto criado:

Criando um adaptador para o Twitter

Uma das tarefas mais temidas na maioria dos ESB's do mercado é a criação de novos adaptadores. Adaptadores são estensões do ESB para manipular aspectos externos ao barramento, como por exemplo, enviar uma mensagem ao Twitter. Veremos então a complexidade de se criar um novo adaptador no SOA Platform. Crie uma nova classe Java como mostrado abaixo:

Como você pode ver, um adaptador pro SOA Platform é nada mais que uma classe que estende AbstractActionLifecycleProcessor. No método process() você define o comportamento que será aplicado a mensagem, e no construtor da classe, você recebe um objeto que contêm parâmetros especiais que você pode passar para sua classe via arquivo de configuração XML. Note que usamos a API do Twitter4J que e super simples de usar.

Criando um serviço do ESB que usa o adaptador do Twitter

Estando com o editor do ESB aberto, clique com o botão direito do mouse em cima da opção "Services" e escolha "Add Service ..."

Clique com o botão direito do mouse em "Actions" em escolha "New -> Generic Action". Será aberto o editor de criação de uma nova action. Configure-a como mostrado abaixo:

Configure os parâmetros de conexão que serão enviados para o adaptador do Twitter, a saber, o nome da conta e a senha do Twitter:

Configurando o serviço para escutar o MySQL via Pooling

aClique com o botão direito na opção "Providers" e escolha "New -> SQL Provider". Na caixa "Name" entre com "SQL Provider" e clique no botão "Next". Na caixa "Channel ID" entre com "sqlChannel". Clique no botão "Finish".

Configure o provider do tipo SQL para acessar o datasource criado. Na caixa "Datasource" entre com "java:/TwitterDBDS":

Edite os filtros do canal SQL para com os parâmetros abaixo:

Crie um listener no serviço do tipo "SQL Listener" e faça com que ele seja o gateway de entrada do serviço basedo no canal "sqlChannel" criado anteriormente:

Testando a solução com o Twitter

Agora é a hora mais divertida, fazer um teste na solução. Para isso, conecte em seu banco de dados, e execute a seguinte instrução de INSERT:

Quando um novo registro que tiver "P" na coluna "request_status" for detectado pelo SOA Platform, ele irá ler o campo "twitter_message" indicado no ESB como coluna que armazena a mensagem e irá criar uma mensagem para o serviço "TwitterProxyService". O valor da mensagem será o conteúdo do campo "twitter_message" em si, portanto, nenhuma transformação precisará ser feita. Depois que o ESB processar a mensagem, ele irá fazer um update na tabela alterando o campo "request_status" do valor "P" de "Pending" para "D" de "Done".

Agora, qualquer aplicação que tenha acesso a este banco de dados vai poder realizar notificações baseadas no Twitter da forma mais simples e trivial possível ;-)

Software AG Products in Action!

I've found this link that enabled a serie of demonstrations of webMethods products in action. Since we're not able to download the software to test it (god, that's why I like open source) it's a good start to see the features of the products. If you need to download the software to do a proof of concept, it's necessary to make a contact with Software AG local office and request a trial copy of the software. It sucks but, at least they're very compreensive.

Software AG has one of the most complete, mature and robust software for SOA, BPM and Governance of services. Even being a reference for Natural and Adabas technologies, they've a vast portfolio of middleware software. Application Modernization is one of the topics that they're the best. webMethods ApplinX, is one example of good software of their portfolio.

See U ;-)

Process Governance (CDL) usando Overloard

Neste post, irei comentar um pouco sobre um dos projetos mais badalados da comunidade JBoss dos últimos tempos: O projeto JBoss Overloard!

Trata-se de um projeto que visa criar uma infra-estrutura para governança de processos e serviços de negócio usando como tecnologia de referência a especificação de WS-CDL. A idéia é você poder criar um arcabouço conceitual para seus processos e serviços onde cada interação entre eles é rastreada a partir de uma interação de negócios, onde então questões como papéis, responsabilidades, políticas e mapeamento do negócio podem ser, pragmaticamente definidos.

O projeto já têm sua versão 1.0 disponível para download, além de um designer de CDL bastante interessante que roda no Eclipse. Este designer foi resultado de uma doação do conhecido Thomas Erl numa tentativa de tornar a prática de governança de processos mais acessível e solidificado na comunidade de profissionais que usam arquiteturas centradas em serviços. A parte interessante é porque ele escolheu a Red Hat como a empresa que irá cuidar da sua criação original:

"There is a real need to have some support for the specialized service-oriented analysis service modeling process that is required in a typical SOA delivery lifecycle to precede the physical design and development process that comes thereafter. This is a tool that is specifically designed to accommodate service modeling."

Você pode ler mais sobre o assunto em: http://news.softpedia.com/news/Red-Hat-Gets-SOA-Modeler-Tool-60957.shtml

Generating EDI Documents on JBoss ESB

We all know that the XML is the better format to interchange data between applications. It's text based, it's structured and most of the development platforms have support for it. We should consider it as the main (and perhaps) the unique form of data integration.

But when we speak about integration, we've to consider platforms that must not support XML documents, or even that they support, the application could not be changed for some reason. I've worked in a project that must integrate platforms using EDI documents. I've used JBoss ESB as the software for the EAI broker. The JBoss ESB should receive a EDI document, transform this EDI document in XML to be sended for a Web Service endpoint. That part was very easy todo since JBoss ESB has a native smooks support for EDI reading (See the "transform_EDI2XML_Groovy_XSLT" demo for more details).

Have the document processed asynchronously by a legacy platform (the platform that received the SOAP request made by the ESB), this legacy platform notifies the ESB that the request is done sending a JMS message for the Broker. The ESB JMS gateway just deliveries the message for a internal service that makes a series of transformation on the message to prepare it for FTP delivering. Using the current resources of JBoss ESB this was not a hard task to accomplish. But the problem cames when the target endpoint (the application that was waiting for the response) asked me to send a EDI document back to it.

I'd all the data in XML format, and using JBoss ESB transformation features, I could transform this document to anything that I could imagine (CSV, Java, other XML using XSLT). But the customer requirement was delivery a message response using the EDI format, and for my surprise (and bad luck), JBoss ESB does not have support for EDI generation. And because this scenario, this post has been written. I've created a generic action that creates a EDI document from a Java regular object. To solve my problems, I'd transformed the XML response to Java (using Smooks) and from that point, I've used my custom action to generate the EDI document. I'm going to share with you this implementation, since could help you at scenarios like mine. Here we go ...

Imagine for instance, that you've the following XML document at your ESB pipeline:

Using the JBoss ESB current transformation features, we could easily transform this document to a Java instance based on the following group of classes:

At this point, we could generate our EDI document using the following ESB action declaration:

And the result of this transformation would be:

Cool isn't? with this little configuration we can generate a complex EDI document to be sent for every channel that JBoss ESB supports as outbound since it's text based. That's the code I created to support this configuration:

In the implementation above, there are a Java interface mentioned. It's used to define custom behaviors for field processing in that cases when logic are related to a specific field. For instance, suppose that you want to guarantee that a specific field must have 40 characters of length even when the value only have 20. You could write a custom handler for that field and put this logic of characters. Here's the interface code:

Hope that help anybody like me that not every time can determine the format of messages that must be delivered by the ESB. We see around ;-)

Applying Agile and Lean Principles to the Governance of Software and Systems Development

Reading a couple DeveloperWorks articles at IBM portal, I've found this very interesting Scott Ambler work that talks about agile and lean methods applied to IT governance. For those that work day by day on a IT environment trying to maintain projects aligned to the business and delivering value at every project milestone, it's a good reference.

The article is freely available to download at the following link:

ftp://ftp.software.ibm.com/software/rational/web/whitepapers/Lean_Development_Governance.pdf

Enjoy It!

Plugin de Governança SOA para o RMC

Já está disponível (a um certo tempo) um plugin de governança SOA para o Rational Method Composer (aka RMC). O plugin oferece um conteúdo bem interessante para a composição de métodos de entrega baseados nas melhores práticas da Rational sobre governança em SOA.

Você precisa ter instalado o RMC 7.1 ou superior para instalar este plugin. Dentre as features encontradas, existe uma bilbioteca densa sobre cenários de governo e empresas de telco (minha área) que envolvem a aplicação de CoE's e corpos de governança. Através do modelo de framework, é simples usando o RMC a criação do seu próprio método de governança baseado nas melhores práticas. Fiz uma PoC com este plugin e criei, para um cenário fictício, um método em apenas uma semana. Vale a pena conferir!

Problemas com o NotifyFTP do JBoss ESB

Estou fazendo uma prova de conceito para um cliente estes últimos dias, e me deparei com uma situação que merece um blog, por se tratar de um problema daqueles que não adianta ler documentação, acessar google, nem tentativa de erro.

Usando o componente Notifier do JBoss ESB para enviar uma mensagem do barramento para um diretório FTP remoto, vi que mesmo fazendo tudo certo, o arquivo não é enviado de forma alguma. Este tipo de situação te faz revisar coisas bem atípicas como regras de firewall, configuração do servidor FTP, parâmetros do Apache entre outros. A listagem abaixo mostra como, de acordo com a documentação, deve ser utilizado o Notifier para envio de mensagens a um FTP:

A chave para resolver o problema é utilizar o atributo "passive" na declaração do notificador. A configuração então ficaria assim:

Ai você me pergunta? - "Mas Ricardo, como você achou este parâmetro?" E a resposta é simples: Conversei com os desenvolvedores do ESB e eles me explicaram detalhadamente sobre este parâmetro. Este é um benefício de trabalhar numa empresa como a Red Hat, benefício este que, pessoas que contratam uma subscrição também têm. O acesso as informações se torna muito mais eficiente, e a resolução de problemas é feita de uma forma confortável para seu orçamento e prazos.

E ainda têm gente que acha isso caro ... dizendo que têm que ser de graça. Pois então, sendo de graça, você pode ainda mandar um e-mail para os core-developers dos produtos e rezar para que eles leiam, e se lerem, que eles respondam. Ou espere por blogs que nem este, que também dependem da boa vontade e paciência das pessoas. Como exemplo do que estou falando, não explicarei no post qual é a razão do parâmetro "passive", mande um e-mail que eu explico ... se eu puder ;-)

Boas Integrações!

Criando Variáveis de Contexto no JNDI do JBoss

Este post é pra deixar registrado uma dica que acredito ser interessante pra quem desenvolve aplicações em JBoss. Um amigo me perguntou sobre isso e tendo esse tipo de coisa registrada em blog me pouca alguns minutos de pesquisa nas docs do JBoss. Vamos lá ...

Imagine que você têm uma aplicação rodando em JBoss, mas gostaria de ter parâmetros gerais definidos num arquivo externo ao módulo da aplicação. Estes parâmetros informam coisas como por exemplo, a língua e idioma que a aplicação deverá carregar nos arquivos de bundle. Uma forma simples de se fazer isso, é usando arquivos de properties. Criando um arquivo de properties num diretório qualquer, você pode carregá-lo junto com o JBoss usando a seguinte linha de comando ao iniciar o servidor:

O problema disso é que os parâmetros não podem ser atualizados. Se você alterar o arquivo, somente na próxima inicialização do JBoss que ele verá as alterações. Outra forma de se fazer isso, é usando variáveis de contexto do arquivo web.xml (No caso de aplicações baseadas em Servlets). Através das seções "context-param" você pode criar variáveis acessíveis via JNDI. Mas para isso, você deverá ter uma ferramenta que possa instrumentar o arquivo e refazer o deployment do módulo em tempo de execução, cenário este que, em alguns casos de aplicações críticas, não é adequado, pois você não pode tirar a aplicação do ar nem que seja 1 segundo!

A solução: Usando binding de variáveis no JNDI do JBoss usando MBeans

Se você quer criar váriaveis no contexto do JNDI, usando JBoss, você pode usar o MBean "JNDIBindingServiceMgr". Este é um MBean que é capaz de criar objetos de qualquer tipo no contexto do JNDI e assinalá-lo a uma variável de binding. Vamos a um exemplo. Crie um arquivo XML. Chame-o de "custom-params-service.xml" e nele coloque o conteúdo abaixo:

Repare no arquivo que ele define uma seção chamada "jndi:bindings". Você pode criar uma ou mais entradas do tipo "jndi:binding" neste seção, sendo possível então a definição de vários parâmetros num único arquivo XML. Repare também que criamos um parâmetro chamado "springFileLocation". A idéia é fazer com que qualquer componente do JBoss em tempo de execução possa, via JNDI, recuperar o valor desta variável e carregar o contexto do Spring.

Copie este arquivo para a pasta deploy do JBoss. A partir deste ponto, você pode acessar as variáveis no contexto do JNDI da seguinte forma:

Como a variável está no contexto do JNDI, se você estiver usando EJBs ou outro componente gerenciado do JEE 5, você pode injetar este parâmetro da seguinte forma:

A parte mais interessante desta abordagem é que, como se trata de um objeto gerenciado pelo JBoss, ou seja, um MBean, você pode a qualquer momento alterar o arquivo XML que as variáveis serão atualizadas no contexto do JNDI, desde que você deixe o HotDeploy do JBoss ativo ;-)

Bons Códigos!