MetaMatrix Platform na Prática!

"Você conhece alguém de Roraima?" Essa é uma frase comum quando queremos enfatizar que algo ou alguém jamais foi visto ou se há dúvidas se ele realmente existe. E olha que de fato, eu não conheço nínguem de Roraima ... acredito realmente que ela efetivamente não exista. Brincadeiras a parte, este post será dedicado a mostrar na prática, o que é a plataforma de Data Services da Red Hat conhecida mundialmente como MetaMatrix, e conhecida internamente como JBoss Data Services Platform. Acredito que muitas pessoas já ouviram coisas sobre o MetaMatrix, alguns já experimentaram seus conceitos na prática através do projeto Teiid, mas poucos, o viram realmente em sua plenitude, com todos os seus recursos, e até mesmo num cenário real. O MetaMatrix é líder mundial de soluções de EII (Enterprise Information Integration) porém sofre do mal de Roraima: Ele é bem pouco difundido e conhecido. Vou tentar explicá-lo através de uma demonstração que criei usando o MetaMatrix Platform versão 5.5, disponível para assinantes da subscrição da Red Hat, e que daqui um tempo, estará integralmente disponivel no site da JBoss.ORG no projeto Teiid.

Um cenário típico para o MetaMatrix

O propósito geral do MetaMatrix é ser uma plataforma para integração de dados. Com este objetivo em mente, ele pode ser usado para resolver N problemas comuns no mundo dos dados. O cenário mais trivial possível seria por exemplo, usá-lo como Firewall de dados. Imagine por exemplo que você possui milhares de bases de dados (possivelmente de diferentes fabricantes) e que, você tenha informações nestas bases que sejam sigilosas. Mas você precisa dar acesso a um grupo de aplicações para que estas via SQL possam recuperar e modificar dados. Usando o MetaMatrix, você pode consolidar estes dados num banco de dados virtual, e este poderia ser acessado por estas aplicações.

Outro cenário interessante é a de MDM (Master Data Management). Uma questão crucial para muitas organizações é possuir uma visão 360 graus de uma dada informação, geralmente clientes e produtos. No ramo bancário por exemplo, é de extrema importância que você tenha uma visão holistica sobre determinada informação (um cliente por exemplo) para que você ganhe maior agilidade. A um tempo atrás por exemplo, participei de um projeto de automação de uma empresa do ramo de cartões, cujo problema era que um atendimento demorava cerca de 24 minutos por cliente(quase 15 minutos a mais do que o SLA contratado) e essa demora se dava porque as informações do cliente, faturas, atendimento de call center e dados de transações de cartões residiam em sistemas diferentes, alguns destes baseados em mainframe. Logo, atender um cliente era uma tarefa árdua para as pobres atendentes. Na ocasião, o projeto era justamente de criar uma interface adminstrativa que reunia dados de sistemas SQL, mainframe, sistemas em Websphere e Delphi, que reunia tudo isso numa única tela, bastando que o atendente digitasse o CPF do cliente. Através do MetaMatrix, isso também é possível.

Agregar dados de diferentes fontes de dados não é algo inovador. Sistemas baseados em OLAP ou Data warehouse já usam este conceito. Mas este tipo de solução sofre de dois problemas graves: Primeiro as informações não são de tempo real, os dados são atualizados quando programas ETLs são disparados (normalmente num período onde os transacionais estão em "descanso") e segundo, os dados são somente para consumo e leitura, eles não podem ser modificados. Usando o MetaMatrix, você agrega várias fontes de dados e ainda consegue ter dados em tempo real porque a transformação é online, e o acesso as fontes de dados é feito por conectores especiais que possibilitam transações na camada de EIS. Criar portanto soluções de BAM ou BI tendo o MetaMatrix como fundação é algo a se considerar, uma vez que o nível da informação se torna ainda mais interessante.

Vários cenários são interessantes para uso do MetaMatrix, e é justamente isso que o torna tão poderoso. Para fins de demonstração, considere o seguinte cenário: Uma empresa de seguros de vida possui um setor de atendimento que necessita visualizar todas as informações relativas a um cliente numa única interface rica escrita preferencialmente para estações de trabalho Windows. As informações a serem visualizadas são:

1) Os dados pessoais do cliente, atualmente mantidos por um sistema PHP acessando o MySQL
2) Os dados de contato do cliente, atualmente mantidos por um sistema Perl acessando o PostgreSQL
3) Os dados de apólices armazenados no DB2 do CICS, que exporta diariamente dados para TXT

A interface criada, originalmente usando a plataforma .NET, em especial, usando a tecnologia de Windows Forms é mostrada abaixo. Repare que a consulta feita é baseada apenas no CPF do cliente, e todas as informações citadas são reunidas nesta interface rica.

Bem, a pergunta seria: Como todos estes dados vieram parar numa aplicação cliente feita em .NET? E a resposta curta (e óbvia) seria: Através do MetaMatrix. Vamos ver como foi o processo de construção deste projeto de Data Services e como os dados foram disponibilizados.

Importação de Fontes de Dados, Criação de Entidades virtuais, VDBs

A primeira coisa a se fazer num projeto de federação de dados usando o MetaMatrix é realizar a importação de todas as fontes de dados que comporão um data service. Isso é feito através da ferramenta MetaMatrix Designer, um ambiente visual baseado no Eclipse altamente produtivo.

O modelo de trabalho do MM Designer é muito simples: Você cria um projeto de data services, constitui suas fontes (origens) dos dados, cria uma ou mais entidades virtuais (views) compostas das fontes de dados, e depois integra tudo isso num banco de dados virtual conhecido como VDB, sigla de Virtual Database. A importação dos dados é feita por um processo 100% visual e bem pouco complicado.

Depois que todas as fontes de dados são importadas para dentro de um projeto do MM Designer, é possível criar as entidades virtuais, ou seja, os data services. Data Services são como views de um banco de dados, só que são baseadas em tabelas, views ou procedures de diferentes tipos de bancos de dados ou de até mesmo coisas que não sejam bancos de dados, como sistemas de caixinha (Excel, PeopleSoft, Siebel, Oracle EBS), tecnologias (SOAP, HTTP, JMS) e formatos (XML, EDI, TXT). Através do MetaMatrix e seus conectores, qualquer fonte de dados vira um potencial data service, possibilitando inclusive, que transformações sejam aplicadas aos data services. Abaixo segue um exemplo de como, duas entidades virtuais foram constituídas das fontes de dados importadas, a saber, a tabela "TAB_CLIENTE" do MySQL, a tabela "TAB_ENDERECO" também do MySQL, a tabela "CONTATO" a partir de um arquivo TXT e a tabela "TAB_APOLICE" do PostgreSQL.

Criado os data services, é hora de consolidar tudo num VDB. Criei um VDB e inserir todos meus data services, web services e fontes de dados nele. A partir do VDB criado, por dentro do MM Designer, você pode testar se suas entidades virtuais estão funcionando corretamente. Basta compilar o VDB e solicitar a execução de testes.

Deployment: A hora mais temida de todas. Será?

Além do MM Designer, a plataforma MetaMatrix é também composta por dois outros elementos. Uma deles é o MetaMatrix Server, ou simplesmente, MM Server. É ele que mantêm os bancos de dados virtuais no ar e que faz todo o acesso as fontes de dados. O MM Server é na prática, um servidor de banco de dados como qualquer outro. Você conecta com ele, realiza autenticações, cria bases de dados (virtuais), executa consultas SQL, ele cria Query Plans para consultas pesadas ... enfim, tudo o que um SGBDR possui, ele também têm. É possível inclusive, criar stored procedures e trigger dentro dele usando a implementação de SQL dele nativa.

A única coisa que o difere dos demais bancos de dados, é que ele além disso, é um middleware de integração, que através dos conectores acessa várias fontes de dados, e pode, expor estes dados através de SQL (sua abordagem padrão) ou via SOAP, expondo as entidades virtuais na forma de Web Services.

O outro elemento da plataforma MetaMatrix é o MetaMatrix Console, ou simplesmente, MM Console. Ele é a interface gráfica de gerenciamento do MM Server. Através dele, você pode fazer deployments, gerar estatísiticas dos VDBS, parar e reiniciar conectores de EIS e claro, gerenciar questões de autenticação e autorização dos usuários. Fazer o deploymento de um VDB no MM Server é uma questão realmente trivial. Vamos aos detalhes. Primeiro, você deverá conectar no MM Console. O servidor do MetaMatrix deverá estar sendo executado em algum computador da rede que o MM Console possa acessar.

Estando logado no MM Console, basta clicar no item "Virtual Databases" e clicar no botão "Import VDB" para importar o banco de dados virtual que você criou. O mesmo VDB pode ser importando diversas vezes. Cada processo de import gera uma nova versão do VDB, o que torna o MetaMatrix ainda mais poderoso: Você pode ter várias versões do seu banco de dados em produção.

Depois de importar seu VDB, você deverá configurar os parâmetros especiais dos conectores que você usou durante a etapa de projeto. Por exemplo, como eu importei dados oriundos de uma base MySQL, outra PostgreSQL e de um arquivo TXT, uma instância de cada um destes conectores me foi gerada pelo MM Designer e incorporada dentro do VDB. Como o ambiente de desenvolvimento pode ser ligeiramente diferente do ambiente de produção, talvez se faça necessário a re-configuração dos parâmetros de acesso a dados a cada uma destas fontes de dados, dados como URL de conexão, endereço IP, usuários e senhas. Feito isso, seu banco de dados virtual está pronto para receber conexões de aplicações via SQL ou SOAP.

Acessando o banco de dados virtual criado via JDBC

Para fins de testes, criei este pequeno programa Java que realiza uma conexão com meu servidor do MetaMatrix, realiza uma consulta em minha entidade virtual "Cliente" e exibe os dados retornados no console. Repare que a consulta feita é uma consulta padrão baseada no puro e simples SQL. Nenhum código "mirabolante" teve que ser criado, e reparando nos imports da classe, dá pra ver que nada mais do que o JDK e o driver JDBC do MetaMatrix (que acompanha o produto) são necessários para criar um cliente destes. Um ponto interessante a se notar também, é que dentro do JAR que contêm o driver JDBC do MetaMatrix, existe uma classe de dialeto do Hibernate, portanto, é possível também criar clientes em Hibernate e JPA acessando MetaMatrix, caso desenho O.O de aplicações seja imperativo em sua organização.

Acessando o banco de dados virtual criado via SOAP

Finalmente, através do MetaMatrix é possível acessar as entidades virtuais através de SOAP. Se no seu VDB você habilitou esta opção, fazendo a distribuição dos XSDs que definem seu endpoint e os tipos complexos dos data services (facilmente gerados pelo MM Designer) você pode disponibilizar qualquer data service via SOAP. A infra-estrutura necessária para isso será ter um servidor de aplicações ou contêiner de Servlets que possa rodar um pequeno programa WAR (Web Archive). O MM Server disponibiliza uma aplicação Web Java que atua como Gateway entre o servidor de aplicações e o servidor do MetaMatrix.

Ao fazer o deploy deste pequeno WAR no servidor de aplicações de sua escolha, você apenas instrui a aplicação a saber qual é o endereço IP e porta que o MM Server estará escutando. Feito isso, basta acessar a seguinte URL: http://192.168.0.1:8080/metamatrix-soap/

Onde "192.168.0.1" é o servidor de aplicações que você escolheu para ser o gateway de SOAP. Ao acessar esta URL, você irá se deparar com a seguinte interface Web:

Clicando no link "Discover MetaMatrix Web Services" você fará com que a pequena aplicação Web (O Gateway) acesso o MM Server e pesquise em sua base de UDDI interna sobre os Web Services publicados. Uma lista será apresentada na tela com o resultado da consulta, e cada item da lista, terá um endereço WSDL disponibilizando, criado automaticamente pelo MM Server. Dai pra frente, qualquer requisição SOAP enviada para um destes endpoints, será enviada diretamente para o MM Server.

E desta forma, com as entidades virtuais (Cliente e Apólice) disponibilizadas via SOAP, pode ser criado o cliente rico em .NET. Acredito que este post mostrou um pouco do poder e robustez da plataforma MetaMatrix, que é a fundação do JBoss Data Services Platform disponibilizado pela Red Hat via subscrições. Se você achou esta solução interessante, e consegue ver soluções suas baseadas nela, não hesite em procurar a Red Hat do Brasil que possamos lhe auxiliar no que for preciso. Tão em breve, toda esta plataforma estará disponível para a comunidade. Neste meio tempo, é uma boa pedida exercitar os conceitos do MetaMatrix através do projeto Teiid.

Forte abraço e até a próxima!

Drools Guvnor em 7 Passos!

Regras de negócio é um assunto que permeia a engenharia de software a décadas. E mesmo com o passar dos anos, ainda é um assunto de suma importância para todos os projetistas de software. Muitas soluções surgiram no mercado para fomentar este tema, e em muitas destas ferramentas e soluções, regras de negócio eram tratadas como mecanismos auxiliares a construção do software. Se formos elencar alguma coisa que todas elas tenham em comum, todos irão apontar o fato da questão de separação de responsabilidades. Regras de negócio devem ser isoladas da construção de software de forma que este se mostre mais produtivo, e portanto, mais eficaz e com maior valor agregado.

Agora, separar regras de negócio do código das aplicações é de fato, uma ação que melhora ou promove a engenharia de software a um patamar mais elevado? Estudos mostram que pessoas estão cada vez mais preocupadas com o domínio de suas organizações (o conceito das empresas) e cada vez menos preocupadas em como explicar isso em termos de código. Métodos como o DDD (Domain-Driven Design) auxiam projetistas de software a criarem software baseado em domínios conhecidos. E quanto a separação de responsabilidades, bem, todos devem concordar que, isso não é nada revolucionário. A mais de 30 anos que existem diversas formas de se conseguir separação de código de regras de negócio, uma delas é colocando as regras em procedures e gatilhos de bancos de dados, processo este que é mais antigo que eu. Outra forma é de se colocar regras em componentes e não mais em objetos, possibilitando que o mercado de componentes possa crescer ainda mais. Tecnologias de componentes como CORBA, EJB, COM e por que não Web Services são excelentes candidatos para este feito.

Lembro com certa saudade, a época em que comecei a aprender Enterprise Java Beans. Na época, eles prometiam ser a forma padrão com que componentes remetiam regras de negócios que pudessem ser de facto, reutilizáveis. A tecnologia estava ali em pró deste feito, mas por alguma razão, isso foi longe de ser o objetivo principal dos EJBs. O mesmo se aplica para as demais tecnologias. Ainda com relação a separação de responsabilidades, regras foram ainda projetadas para rodarem em camadas (Layers) adjacentes as camadas de aplicação, de forma que estas pudessem ser isoladas dos impactos das mudanças de requisito e vice-versa. Enfim, posso escrever linhas e mais linhas sobre todas as evoluções e esforços criados a partir das regras de negócio, e em todas que eu citar, haverão com certeza seu efeito colateral e seu claro fracasso, porque até hoje, regras de negócio não tiveram a verdadeira atenção e respeito que deveriam ter. E esta é a razão para que regras de negócio ainda seja motivo de vergonha e piada para a maioria dos projetistas de software. Se você chegar com um CTO e falar (mais uma vez) sobre isolamento de regras de negócio em pró de maior produtividade, você com certeza irá notar um semblante de desprezo do seu rosto. Isso acontece porque as pessoas estão desacreditadas.

O ponto é, você não deve se preocupar demasiadamente com separação de regras e código, porque isso já pode ser feito com inúmeros recursos a mais de 30 anos. Você não deve achar que as regras de negócio são a chave para seu problema de produtividade de desenvolvimento, porque em média, elas representam 30% do esforço da construção de um software. Você não deve ter processos rígidos que controlem a mudança das regras, porque elas, naturalmente mudarão com frequência e intensidadade. E acima de tudo, você não deve achar que conhece regras de negócio melhor que as pessoas do negócio porque você, no final das contas, é um nerd que possui um bom conhecimento de lógica e programação, mas pouco ou nenhum senso crítico para questões não técnicas. E com base neste erro é que outro erro é gerado: De afastar as pessoas de negócio do projeto de construção de sistemas por achar que elas mais atrapalham que ajudam. Finalmente, a questão mais importante de todas. Não ache que desenvolvimento de software é a coisa mais importante para uma empresa. Software, é um investimento caro, que pouco trás resultado (históricamente falando) e que ajuda muito mais a sistematizar processos (torná-los repetitidos, controlados e previsíveis) do que efetivamente, trazer melhorías para as organizações. Toda empresa quer melhorar seus processos, reduzir suas despesas e se reinventar periodicamente para atingir um único objetivo: Mais lucro, mais rentabilidade!

O conhecimento no negócio e o intelecto que está por trás de toda organização é que lhe produz formas de ganhar mais dinheiro. E este intelecto se exterioriza na formas de regras de negócio. As regras representam o conhecimento por trás de um grupo de processos, e os processos representam as etapas a serem seguidas para se atingir um objetivo de negócio. A mensagem então a ser entendida e aceita é: Processos e regras são muito mais importantes que código. E por isso, você como projetista de software deve investir mais tempo criando ou usando recursos que ajudem neste quesito, porque é ele que irá efetivamente, trazer diferencial para a TI.

O que tudo isso têm a ver com o Drools Guvnor? O ponto deve ser que assim como projetistas de software, pessoas não técnicas devem poder criar e inventar. Pessoas de negócio devem poder criar suas estratégias, documentar seu conhecimento, compartilhar suas decisões, gerenciar todo esse conhecimento e acima de tudo, poder fazer tudo isso, sem o auxílio da TI. E é ai que entra o Drools Guvnor e o JBoss BRMS, como ferramentas que possibilitam esse foque mais acentuado em regras e conhecimento e muito menos, em baboseiras como separação de código e blá blá blá. Com o Guvnor, é possível que eles possam criar a se reinventar, mas ainda sim possibilitando que a TI possa usufruir dos seus esforços reutilizando (ou aferindo) as regras criadas por eles.

Neste post irei mostrar como instalar, configurar e criar um exemplo simples no Drools Guvnor, a plataforma de regras web do framework Drools. O Drools Guvnor é um sub-projeto do Drools que está ganhando um espaço cada vez maior no mercado de tecnologia da informação, especialmente sua versão enterprise suportada, que é o JBoss BRMS. A cada cliente que faço uma demonstração do produto, todos enxergam inúmeras possibilidades a serem exploradas, por se tratar de um software que além de robusto e estável, é bem simples de usar.

1) Baixe a última versão do Drools Guvnor

A primeira coisa a se fazer é montar um ambiente para a plataforma Guvnor. Para isso, você deverá ter uma cópia do mesmo. Baixe uma versão estável do Drools Guvnor do site da JBoss da comunidade. Você pode baixar o Guvnor já com o servidor de aplicação (opção StandAlone) ou poderá baixar o mesmo "avulso", onde apenas um .WAR será disponibilizado. Para estes testes, faça o download da versão avulsa. Para este post, usei a versão 5.0 GA do Guvnor, e um JBoss AS versão 4.2.3 GA. Utilize o JDK 5.X para estes testes, incluindo o cliente Java.

2) Instale o pacote em alguma instância do JBoss AS

A instalação do Guvnor não pode ser mais simples: Apenas copie o arquivo .WAR baixado para a pasta deploy do seu JBoss AS. Inicie o servidor JBoss e repare quando o módulo Web for reconhecido pelo JBoss Deployer. Ele irá criar o seguinte contexto web: http://localhost:8080/drools-guvnor

3) Crie um pacote de negócios e um pequeno modelo de domínio

Acesse a URL do Guvnor, e você deverá ver uma interface de login. Para ter acesso a plataformas de regras, primeiro você deverá realizar uma autenticação. Para testes, use o usuário default do Guvnor que é o "admin" cuja senha também é "admin".

Depois que você efetuar a autenticação, você será encaminhado para a interface principal do Guvnor. Nela, você poderá ver que existe um menu na lateral esquerda da tela com opções como "Browse", "Knowledge Bases", "QA", "Package Snapshots" e "Administration". Neste post não iremos dar detalhes específicos sobre todas as funcionalidades do Guvnor, a documentação do mesmo deverá ser suficiente caso você precise disso. Iremos focar na parte mais importante do Guvnor, que é o conceito de Knowledge Bases. Knowledge Bases ou "Bases de Conhecimento" são repositórios de informações sobre regras, domínios, testes e fatos. Elas são operacionalizadas através do conceito de pacotes, ou seja, repositórios de coisas relacionadas. Logo, para começar a utilizar o Drools Guvnor, você deverá criar um ou mais pacotes de conhecimento.

Vamos criar um pacote de conhecimento de testes. O cenário será o seguinte: Imagine que você deseja criar um conjunto de regras e processos sobre notas fiscais eletrônicas. A idéia é que todo conhecimento sobre notas fiscais eletrônicas esteja dentro deste pacotes que iremos criar. Para criar um pacote, clique em "Knowledge Bases" e no botão suspenso que aparece (O botão "Create New") escolha "Create New -> New Package". Uma janela será aberta para que você entre com algumas informações sobre o pacote. Entre com as informações conforme a figura abaixo e clique em "Create Package".

Depois que você confirmar a criação do pacote, o Drools Guvnor irá atualizar sua interface e você poderá ver que seu novo pacote "nfe" já possui itens internos a serem criados, a saber, os itens que formarão a sua base de conhecimento sobre notas fiscais eletrônicas.

Temos que formar nossa "opnião" sobre notas fiscais eletrônicas. Para isso, temos que formular nossas idéias e conceitos sobre o que está relacionado a notas fiscais. Isso é feito criando-se um domínio ou mapeamento de idéias sobre um determinado assunto. Todos aqueles substantivos que giram em torno de um determinado assunto são potenciais domínios a serem mapeados. Por exemplo, se você refletir um pouco sobre notas fiscais eletrônicas, irá mapear claramente em sua cabeça o processo de requisição de notas fiscais. Alguem pede a nota, e alguem fornece a nota. E neste cenário, duas informações são vitais: O valor da nota, e um status que informe a situação do pedido da nota. Podemos então colocar em nossa base de conhecimento a idéia sobre "PedidoNotaFiscal" que possui como informações vitais, o "valor" e o "status" da nota. Vamos então modelar este substantivo.

Clique novamente no botão suspenso "Create New" e agora, escolha a opção "New Declarative Model". será aberto uma janela para criação de um novo modelo. Entre com as informações abaixo e clique no botão "OK".

O que acabamos de criar foi um modelo declarativo. Um modelo declarativo é uma forma do Drools Guvnor onde podemos modelar nossos domínios usando um editor visual Web que gera um ou mais tipos baseados em XML. Pense, análogamente falando, nestes tipos como se fossem DynaActionForms do Struts, ou seja, elementos que representam entidades de um aplicativo, mas que você não quis escrever uma classe Java para isso. Caso você queira usar uma classe Java para representar seus domínios, usando por exemplo, tipos baseados em POJOs, você poderia escolher a opção "Create New -> Upload POJO Model JAR" mas iremos deixar isso para um próximo artigo.

Será aberto no editor visual do Guvnor uma interface onde você poderá criar um ou mais tipos complexos, conhecidos dentro do Guvnor como "Fact Types" ou simplesmente, tipos. Para criar nosso domínio, clique no botão "Add new Fact Type". Será aberto uma janela de popup para que você entre com o nome do seu domínio. Escreva "PedidoNotaFiscal" e clique em "OK".

Seu novo domínio será colocado dentro da interface. Se você o expandir, irá ver que abaixo dele aparece um botão "Add Field". Neste botão você poderá configurar todas as caracteristicas do seu domínio como por exemplo o valor da nota fiscal. Clique no botão "Add Field". Será apresentado uma janela como abaixo:

Na caixa "Field Name" entre com "valorNota" e em seguida, selecione no combobox ao lado a opção "Whole Number (Integer)" para informar que este campo é do tipo numérico. Clique em OK para confirmar a criação do campo. Repita este processo para criar o campo "status", porém crie-o do tipo "Text" para informar que ele será uma cadeia de caracteres (String). Depois que você fizer isso, seu domínio sobre notas fiscais terá sido criado. Agora, para confirmar a criação do domínio, clique no botão "Save Changes" para que as alterações feitas no modelo declarativo sejam persistidas no repositório do Drools Guvnor.

Agora que temos pelo menos um domínio criado no repositório, podemos dar inicio a construção de artefatos que dão mais sentido ao mundo dos negócios: Regras e mapeamentos. Lembre-se que você pode ter quantos domínios quiser dentro do Drools Guvnor, e este é apenas um exemplo. Uma pessoa de negócios que conheça de notas fiscais (por exemplo, um técnico da SEFA) poderia criar diversos domínios diferentes sobre o assunto notas fiscais tendo em vista que ele "respira" este assunto. É importante lembrar também que no Drools Guvnor, você pode ter vários pacotes de conhecimentos diferentes. Esta é uma pratica interessante pois você pode fomentar vários domínios e assuntos em "fronteiras" diferentes, assim como fazemos em engenharia de software com o conceito de camadas.

4) Crie algumas DSL's sobre o modelo de domínio

A criação de regras de negócios sobre domínios de uma organização pode ser uma tarefa bem trabalhosa. Ainda mais quando você precisa dissernir sobre um domínio que é complicado. Ao longo dos anos, a prática de DSL (Domain Specific Language) têm ajudado especialistas de várias industrias a criar uma lingua franca sobre domínios que são complexos. Por exemplo, facilmente você pode aferir sobre regras de tarifação de um imposto bancário ou um desconto de um produto, pois tratan-se de regras comuns e simples de se entender. Mas tente por exemplo, entender regras de restrições de firewalls em níveis mais baixos que a camada de aplicação, ou regras de exclusão para pacotes de MMS de um cifrador de rede. Mais ainda, tente conversar sobre regras de pacotes com um engenheiro em telecomunicações sendo você, uma pessoa de outro domínio. DSLs são mecanismos interessantes para resolver esse tipo de problema. Você cria argumentos e conceitos "entendíveis" até mesmo por pessoas que não sejam daquele domínio.

Mesmo não sendo o caso, mas para fins didáticos, vamos imaginar que o mundo de notas fiscais eletrônicas é algo complexo e que temos que criar vários argumentos (frases) que sejam deste mundo mais facilmente entendidas por pessoas de fora o que estejam iniciando no mesmo. Me vêm a cabeça os seguintes argumentos:

• Existe um pedido de nota fiscal?
• Qual o valor deste pedido de nota fiscal?
• Aprove este pedido de nota fiscal
• Reprove este pedido de nota fiscal

Com base nestes exemplos, vamos criar algumas DSLs no nosso pacote sobre notas fiscais eletrônicas. Para isso, clique no botão suspenso "Create New" e agora escolha "New DSL". Será mostrado uma janela pedindo informações sobre a nova DSL. Entre com os dados abaixo e clique no botão "OK".

Na caixa que se abre, entre com as seguintes DSLs:

Uma DSL para o Drools Guvnor é muito simples de ler: Basta você fazer equivalências. Cada entrada reflete um mapeamento de domínio entre a parte da esquerda (antes do "=") e o da direita (depois do "="). O elemento da esquerda é a abstração do conhecimento e o elemento da direita é o conhecimento concreto sob a ótica da linguagem do Drools. Feito isso, clique no botão "Save Changes" para confirmar as alterações feitas na DSL. Uma vez que você tenha domínios e DSLs criadas, elas estarão disponiveis para você no momento da criação de regras de negócio. Por isso, deve ser um processo que antecede o processo de criação de regras, preferencialmente.

5) Crie uma ou mais regras sobre o modelo de domínio

Agora é uma etapa importante no processo de descobrimento do Drools Guvnor: Vamos experimentar como é criar regras de negócios na plataforma. A única pré-condição para você fazer isso é ter pelo menos um ou mais domínios previamente criados. DSLs não são pré-condições para as regras, são apenas formas de amenizar a complexidade do conhecimento. Porém, você precisa de domínios para modelar suas asserções e pontos de vistas na forma de regras de negócio.

Vamos criar uma regra de negócio simples, ainda sem usar as DSLs. Esta regra de negócio diz o seguinte: Se uma nota fiscal eletrônica for requisitada, e seu valor for inferior a 89.90 ela será automaticamente aprovada, ou seja, não passará por um processo de aprovação. Para criar a regras, clique no botão "Create New" e escolha a opção "New Rule". Uma janela será aberta para coletar algumas informações sobre a regra, entre com as informações abaixo:

Clique no botão "OK". O Guvnor irá abrir um editor visual de regras de negócio. Neste editor, você poderá verificar três botões interessantes. Um botão com o símbolo de "+" referente as condições de avaliação (WHEN), um botão de "+" referente as ações a serem tomadas (THEN) e um botão de "+" referente a opções gerais que podem ser aplicadas a regras, como exclusões, priorizações ou condições de não looping. A parte referente a "WHEN" é na verdade a inferência dos fatos ou simplesmente condições. A parte referente a "THEN" são as consequências da inferência, ou seja, o resultado do processo de inferência de fatos. Toda regra têm uma avaliação e uma consequência clara e que normalmente estarão ligados ou farão algum sentido complementar para a regra.

Vamos avaliar um pedido de nota fiscal quanto a seu valor. Para isso, clique no botão de "+" referente a porção "WHEN" para adicionar uma avaliação. Quando você fizer isso, será aberto uma janela para criação de uma condição. Repare que todos os domínios e DSLs que você criou previamente serão listados pra você como "dicas" sobre o que avaliar:

Escolha o domínio "PedidoNotaFiscal" e clique em "OK". O item será inserido no editor. Agora clique em cima do novo item, para abrir os detalhes do pedido de nota fiscal. Na caixa "Add restriction on a field" escolha o campo "valorNota" para que possamos fazer uma avalição com base no valor da nota fiscal. O campo será automaticamente inserido no editor quando você o selecionar.

Ao lado do campo "valorNota" irá aparecer um combobox onde você deverá escolher qual método de comparação irá usar, a saber, maior, igual, menor, etc. Escolha "Less Than". Fazendo isso, você habilita logo ao lado do operador um símbolo de lápis, onde você deverá definir qual será o elemento que será aplicado a avaliação. Clique no lápis e será aberto uma caixa pra você decidir se irá usar um valor literal ou uma formula. Escolha o valor literal. Em seguida, será criado um campo para que você digite o valor literal para a sentença. Entre com 89.90. Pronto, nossa avaliação está criada.

Agora é hora de criar a consequência da regra. Clique no botão de "+" referente a porção "THEN" e escolha a opção "Modify pnf ...". Seguindo o mesmo racicínio da criação da cláusula WHEN, crie uma expressão que escreva "APROV" no campo status do tipo PedidoNotaFiscal. A regra final deverá parecer como a figura abaixo:

Clique no botão "Save Changes" para salvar as alterações feitas. Nossa primeira regra de negócio sobre notas fiscais eletrônicas foi criada. Para fins de testes, você poderá criar também uma regra que reprove um pedido de nota fiscal caso o valor desta seja superior a 89.90. Usando as DSLs que criamos anteriormente, a regra seria parecida com a figura abaixo:

Vamos testar se nossa regra de negócio funciona corretamente. Para isso, crie um cenário de testes dentro do Drools Guvnor.

6) Crie um cenário de testes para uma das regras criadas

O Drools Guvnor possui um recurso super interessante para realizar testes em regras criadas dentro dele. Você pode criar um ou mais cenários de testes para aferir condições normais e anormais de suas regras, como se fossem fluxos principais e fluxos alternativos de um caso de uso qualquer. Para criar um cenário de teste, clique no botão "Create New" e desta vez, escolha a opção "New Test Scenario". Uma janela será apresentada para você entrar com alguns dados. Digite "Happy Path NFe" no campo "Name" e clique no botão "OK". Iremos criar um cenário de testes que simula o "melhor caso" onde a regra recebe os parâmetros esperados e tudo dá certo, por isso o nome Happy Path.

No editor visual que se abre, dois botões chamarão mais atenção: O botão "GIVEN" e o botão "EXPECT". Na seção GIVEN você estipula os dados de entrada, ou seja, o que será enviado para o Drools Guvnor para avaliação. Na seção EXPECT você define o que esperar após a aplicação (inferência) de uma ou mais regras. Como normalmente as regras alteram os fatos enviados, uma boa pedida é avaliar nesta seção as mudanças ocorridas em pró de qual regra você imagina que seja executada. No caso da regra "Aprovação de NFe" esperamos que, ao passar um pedido de nota fiscal cujo valor seja inferior a 89.90, ela seja aprovada, ou seja, tenha "APROV" no seu campo status.

Clique no botão "+" referente a seção "GIVEN". Será aberto uma janela onde você deverá escolhar qual fato será inserido. O fato "PedidoNotaFiscal" deverá ser o único até então. No campo "Fact Name" entre com "pnf" que é apenas um apelido para o fato. Clique no botão "Add" para confirmar a inserção do fato ao cenário de testes. Depois de inserido, clique em "Add Field" para criar uma restrição de campo. Selecione o campo "valorNota" e depois de inserir este campo, entre com "78.50" na caixa de texto que se abre. Clique agora no botão "+" da seção EXPECT. Será aberto uma lista com todas as regras que você poderá escolher. Escolha a regra "Aprovação de NFe" e confirme a inserção do item.

Pronto! Nosso cenário de testes está criado. Agora podemos testar a regra. Clique no botão "Run Scenario". Como estamos passando um valor inferior a 89.90, nossa regra será aplicada, e o caso de testes será 100% processado. Depois de verificar isso, faça um teste: Modifique o valor para 102.14 e veja se o cenário de testes acusa sucesso. Ele irá "fracassar" nos testes pois a regra seleciona não pode ser satisfeita.

Faça experiências com os cenários de testes. Você irá verificar que o Drools Guvnor pode ser uma ferramenta poderosa para a criação de cenários de testes complexos sem que você escreve nenhuma linha de código para isso.

7) Crie um programa Java para testar a API do Rule Agent

Esse é o momento final de nosso pequeno passeio virtual sobre o Drools Guvnor. Iremos passar agora para uma seção mais "interessante" do ponto de vista dos projetistas de software. Iremos ver como criar um programa Java que conecta com o servidor de regras, e solicita que um determinado fato (o nosso pedido de nota fiscal) seja processado. Para compilar e executar este programa, você precisará das bibliotecas "drools-api", "drools-core" e "drools-compiler" bem como suas dependências. Estas podem ser baixadas do site do Drools ou "copiadas" do diretório WEB-INF/lib da aplicação do Drools Guvnor.

Para começar, você irá precisar criar um arquivo de propriedades que possua as configurações da nossa base de conhecimento. Todo pacote do Guvnor é exposto via uma URL e é acessível via HTTP a qualquer aplicação. Crie um arquivo chamado "ruleAgent.properties" com o conteúdo abaixo:

Neste arquivo você define qual pacote será chamado e onde será feito o cache do pacote quando o primeiro acesso for feito. O Drools Guvnor não executa uma chamada remota todas as vezes. Ele faz um cache local do pacote de regras e o atualiza de tempos em tempos. Esse tempo é configurado pelo parâmetro "poll" e é dado em segundos.

Com o arquivo de propriedades criado, crie o seguinte programa Java:

Execute este programa Java, e você poderá verificar que com o valor passado (78.50) o valor do status deverá ser "APROV". Passe um valor superior e veja o acontece. As regras irão dando forma aos resultados a medida em que estes forem entregues para a plataforma do Guvnor.

Espero que este artigo possa ter ajudado no entendimento e prática do Drools Guvnor e gostaria que este fosse o pontapé inicial para que o assunto regras de negócios possa ser melhor canalizados nas organizações. Conforme visto, o Drools Guvnor é uma ferramenta poderosa na construção, execução e manutenção de regras e deve sem dúvida ser a plataforma ideal para a maioria das organizações complexas. Leve estas idéias e tecnologias para suas empresas, e façam com que projetos e soluções internas sejam criadas com base nisso. Este tipo de fomento da tecnologia é a melhor coisa que você pode fazer pelo open source, em troca dos benefícios (Tecnologia, Documentação, Artigos) que lhe são oferecidos, de graça ;-)

Até a próxima!