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!
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
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 ;-)
