Nota 1: recomenda-se conhecer Maven e Java ao ler esse artigo para correto entendimento. Embora não obrigado, vamos utilizar termos familiares a programadores Java e usuários de Maven;
Nota 2: Os exemplos de código foram retirados da documentação
Conhecimento é tudo
O fato é que na história dos sereumaninhos, nada é mais importante do que o conhecimento adquirido e passado para outras gerações. Podemos dizer que conhecimento é tão importante quanto a reprodução, essencial para qualquer animal.
 |
| Já dizia o ET Bilu.... |
Alguns projetos JBoss são parte de um "guarda chuva" de projetos chamado KIE, sigla que vêm do inglês e significa Knowledge is Everything(conhecimento é tudo). Por esse motivo, boa parte da API que vamos mostrar vêm do pacote Java org.kie. Os projetos desse guarda-chuva são:
- jBPM: Ferramentas e engine para execução de processos comerciais conforme já abordamos aqui no blog;
- Uberfire: Um framework para construção de aplicações WEB com workbench. O console WEB do Drools e do jBPM foram construídos utilizando esse ótimo framework;
- OptaPlanner: Nasceu do Drools Planner, o OptaPlanner tem a interessante missão de ajudar no melhor uso de recursos no negócio, auxiliando na resolução de problema sem resolução (NP-Completo). Isso mesmo que você leu!
- Dashbuilder: Uma completa aplicação WEB para criação de Dashboards de negócios. Quem explorou o console do jBPM já deve ter visto o Dashbuilder em ação lendo dados das tabelas do jBPM.
Estrutura de aplicações KIE
Toda a API KIE é explicada na documentação do Drools, por esse motivo, iremos focar nas partes essenciais da API.
Um projeto KIE é um projeto maven(nesse artigo falamos sobre Maven) como usual com uma pequena exceção: ele contém um descritor especial no diretório META-INF chamado kmodule.xml. É nesse descritor que podemos declarar outras partes importantes da API, mas na versão mais simples, o kmodule.xml pode simplesmente estar vazio, como mostrado abaixo:
Criem um projeto maven, adicione um kmodule.xml em src/main/resource/META-INF , faça o build e temos um KIE JAR, ou melhor, um kJAR.
Cada kJAR tem um KieContainer, que é a abstração de maior nível de um projeto Kie. Dentro de um KieContainer temos diversos KieBase. Uma KieBase é, enfim, onde colocamos os arquivos do Drools, como arquivo de regras DRL, e do jBPM, como arquivos de processo comerciais BPMN2 e devemos declarar as mesmas dentro do arquivo XML kmodule.
Ao declarar uma KieBase, informamos o nome dela e o pacote onde podemos encontrar os arquivos mencionados anteriormente para aquela KieBase. Caso usamos um kmodule sem nenhuma KieBase, como mostrado acima, todo o conteúdo do diretório resources é considerado uma KieBase chamada de defaultKieBase.
A execução de regras e de processos em si dependem da KieSession. Uma KieBase pode ter várias KieSession. KieSession é sobre runtime, ela não conhece os arquivos em si e sobre runtime temos dois interessantes paradigmas: Stateful, onde criamos uma KieSession que mantém a informação de execução até que ela seja explicitamente descartada e Stateless, que não mantém informação de execução. Na declaração da KieSession, declaramos também diversos componentes utilizados em runtime, componentes que não abordaremos nesse artigo!
Carregando KieContainer
Agora que entendemos a estrutura das aplicações, vamos falar um pouco como podemos carregar as mesmas no nosso código Java. Tenham o seguinte em mente quando carregando um KieContainer:
- Um projeto java pode ser também um kJAR e podemos carregar as KieBase que declaramos no kmodule.xml presente no classpath da nossa aplicação, ou seja, KieContainer é criado baseado no que temos no nosso classpath;
- Os kJARs podem estar em um repositório Maven e podem ser carregados na aplicação Java. Dessa forma, o KieContainer é carregado através de módulos Maven, ou melhor dizendo, um KieModule;
- Você pode de forma "programatica" carregar arquivos do seu disco e criar um KieContainer utilizando o KieFileSystem auxiliada pelo KieResources(resources são recursos carregados sejam de uma URL ou do próprio disco)! Para isso é também necessário criar os detalhes do KieModule de forma programática
O ponto de entrada para tudo isso é a classe KieServices que é exclusivamente acessível através do método KieServices.Factory.get(), com essa classe podemos:
Acessar um KieContainer do nosso classpath e então acessar as KieBases configuradas
KieServices kieServices = KieServices.Factory.get(); KieContainer kContainer = kieServices.getKieClasspathContainer(); KieBase kBase1 = kContainer.getKieBase("KBase1"); KieSession kieSession1 = kContainer.newKieSession("KSession2_1"); StatelessKieSession kieSession2 = kContainer.newStatelessKieSession("KSession2_2");
KieServices kieServices = KieServices.Factory.get(); ReleaseId releaseId = kieServices.newReleaseId( "org.acme", "myartifact", "1.0" ); KieContainer kieContainer = kieServices.newKieContainer( releaseId );
KieModuleModel kieModuleModel = kieServices.newKieModuleModel();
kfs.write( "src/main/resources/KBase1/ruleSet1.drl", stringContainingAValidDRL )
.write( "src/main/resources/dtable.xls",
kieServices.getResources().newInputStreamResource( dtableFileStream ) );
Realizando o "Build"
Agora que entendemos a estrutura de um projeto, devemos entender como realizar o "build", ou transformar os arquivos KIE em um módulo pronto para uso. Para isso temos o KieBuilder que verifica os arquivos e retorna as mensagens com erros e avisos lançados durante o Build:KieServices kieServices = KieServices.Factory.get(); KieFileSystem kfs = ... kieServices.newKieBuilder( kfs ).buildAll(); KieContainer kieContainer = kieServices.newKieContainer(kieServices.getRepository().getDefaultReleaseId());
KieBuilder kieBuilder = kieServices.newKieBuilder( kfs ).buildAll(); assertEquals( 0, kieBuilder.getResults().getMessages( Message.Level.ERROR ).size() );
Após realizar o build "programaticamente" do nosso projeto, podemos adicionar ele a um KieRepository, utilizando o release ID default.
Caso tenhamos o nosso kJAR em um projeto Maven, podemos utilizar o kie-maven-plugin, que é ativado durante build do maven:
<build> <plugins> <plugin> <groupId>org.kie</groupId> <artifactId>kie-maven-plugin</artifactId> <version>${project.version}</version> <extensions>true</extensions> </plugin> </plugins> </build>
Resumão
Em seguida você pode encontrar diversas imagens de classes mencionadas nesse artigo.
Nenhum comentário:
Postar um comentário