Archive for the ‘drools’ Category

Drools persistence on top of HashMap
February 7, 2011

Introduction

This post shows a reference implementation of drools persistence on top of a non transactional HashMap. This should serve as inspiration for more complex scenarios (like the Berkley DB one). This work was also developed under Intalio’s sponsorship.

As the new abstraction is heavily inspired on JPA there are some mechanisms which should be emulated in order to get the same behavior on both implementations.

Involved classes

Starting from the abstraction described in my previous post this is the new hierarchy for persisting drools runtime into a HashMap.

Drools abstract storage persistence diagram

Drools abstract storage persistence diagram

I’ll try to explain the most relevant objects in the diagram relating them to JPA components.

MapBasedPersistenceContext
behaves like the EntityManager, it stores all objects which are not yet commited. Finding objects is also resolved through this interface, for support this behavior it has to have access to the KnowledgeSessionStorage.
KnowledgeSessionStorage
represents the real persistent storage. This is the extension point for support any other non-JPA implementation. It provides saveOrUpdate and find methods and is the responsible to assign id’s to the entities.
ManualTransactionManager
as we cannot rely on JTA to manage our session Drools hooks explicit calls whenever things should be serialized. This component must access the NonTransactionalPersistenceSession to get the entities waiting for being persisted into the KnowledgeSessionStorage.

JBPM5

The same concepts have been applied into JBPM5 codebase and we have there proper extensions for managing process semantics.

You’ll find there:

  • MapBasedProcessPersistenceContext
  • ProcessStorage
  • ManualProcessTransactionManager
  • etc

Usage

You must setup the environment you gonna pass to the JPAKnowledgeService (still keeping the name for backward compatibility) setting the TRANSACTION_MANAGER and PERSISTENCE_CONTEXT_MANAGER keys. For this I have just created simple factories but you can build them the way you want.

I suggest using KnowledgeSessionStorageEnvironmentBuilder or ProcessStorageEnvironmentBuilder. There doesn’t exist a default implementation of this storage, the one on top of HashMap is only used for testing porposes, so you have to pass to the builder your own implementation of the desired storage.

Testing further implementations

To test this two implementations (and any new one which wants to respect the drools persistence semantic) together, I have created a simple set of abstract tests(*).
For Drools Expert:
https://github.com/droolsjbpm/droolsjbpm/[…]/MapPersistenceTest.java
For JBPM5
https://github.com/krisv/jbpm/[…]/MapPersistenceTest.java
In a future will be great to abstract the current tests on JPA to be able to run abstract of the lower persistence layer.

What’s next

Clean up this interfaces a bit more and start working on a DB Berkley implementation

(*) tests names are not declarative enough, I’m holding a commit for this until coming repository split is done

Simple Drools Rule Flow to BPMN2 migration tool
December 28, 2010

For ease the transition from Drools Flow files to the new BPMN2 standard drools gives you a nice but hidden feature, a XmlBPMNProcessDumper.
This tiny piece takes a RuleFlowProcess instance and spits nice well formed BPMN2 files.
So, for making your life just a little better, I’ve created a project on github exposing this internal piece with a nice interface. Take a look at the class RuleFlow2BPMN2Migrator in

https://github.com/diega/rf-bpmn2-migrator

Enjoy.

Disclaimer: calling a 7-line class a tool isn’t fair enough, but you know…

Are you ready for Drools 5.2 + jbpm5?
December 16, 2010

Great things are happening into the core of Drools and it will impact into the whole community.
This post is not about the great features we gonna have soon but about how to make the transition painless.
From the developer point of view things are getting better and better.

    Git migration
    Maven 3 compliance
    Repository cleanup (no more .classpath and .project files)
    Guvnor building coming less and less painful
    Huge internal refactors and optimizations

The major of this tasks were leaded by ge0ffrey who has made our lives a lot better :)

As regular user of the framework when you finally decide to move from 5.1.1 to 5.2 you will find a big difference. Drools Flow is gone… but it has reborn as JBPM5!.
So the concepts remains the same but you’ll need to adjust your dependencies and make a reorganization of your imports. This is the first step on breaking backward compatibility preparing us for the big crash arriving on 6.0 :)
Basically u gonna need to add

<depdency>
  <groupId>org.jbpm</groupId>
  <artifactId>jbpm-[flow | persistence-jpa | bpm2 | ...]</artifactId>
  <version>${jbpm.version}</version>
</dependency>

Doing so you should change a lot of your org.drools packages into org.jbpm.

w00t

New Guvnor Feature – Rule Templates
May 28, 2010

Here is a screencast showing guvnor rule template features

As you can see here,  the Template Editor is an extension of the famous Rule Editor which now has a Template Data tab. On this tab you’ll find a grid having the template placeholders (a.k.a. “template keys”) as columns. So in your knowledge base you’ll finally add the rules generated by the drools-template module, using the data into the grid and the parametrized rule that you’ve created in the editor.

Drools Flow :: Work Items
April 19, 2010

Introduction

Working on improve our knowledge about the Drools platform and to give something back to the community. This time we’ll discuss a language extension called Work Items. The official documentation says: “[Drools Flow] offers constructs that are closely related to the problem the user is trying to solve”. In other words, creating your own WorkItems lets you extend the business modeling language to a domain oriented way.
Creating a language for your process gives you an enormous flexibility in what you can express. The funny thing is that with this great power doesn’t come a great responsibility, meaning there is no more responsibility than needed to write any bored and unflexible process language.

(more…)

Jetty + DataSource + JTA
April 18, 2010

Working on my next post about Drools Flow Work Items I wanted to have a one click example. This example involves a web application so I started with Jetty which fits perfect for a mvn jetty:run example. In the standalone example we run our own JNDI directory provided by Bitronix. Jetty has JNDI directory embedded so we have to register the datasource and the transaction manager. Doing this task for a totally jetty noob could be a little difficult and time consuming. So, hoping nobody has to spend too much time on this, I’ll try to summarize the steps I did to make this.
(more…)

Primer caso de éxito (personal) de Drools
May 8, 2009

Escribo para comentar mi primer experiencia con el uso de drools-expert en el campo comercial.
El desafío era realizar un servicio de búsqueda de servicios de correo entre distintos destinos. El problema con estos es que son muy arbitrarios, cambiantes y además el sistema debía soportar el agregado de distintos servicios menores que realizaran trayectos específicos.
Lamentablemente el post no será introductorio, para comprender lo siguiente deberían tener algo de jerga Drools o bastante imaginación. Igualmente puede ser útil que algo de esto quede en la cabeza mientras estén aprendiendo. Decidid vosotros.
También cabe destacar que todo el desarrollo estuvo basado en la versión 5.0.0.CR1 con lo que puede cambiar en las siguientes versiones.

En el camino, aparte de formar mi cabeza en modo Drools (pensar en activaciones, updates a la working memory, etc), me he topado con algunas cosas a tener en cuenta que no encontré en la documentación:

  • El KnowledgeAgent, daemon que me permitiría el traspaso de compilar las reglas de manera local al uso de guvnor, no soporta el compilado de reglas basadas en un DSL.
  • Los archivos de reglas escritas en DSL, tienen que ser del tipo DSLR y no se pueden mezclar reglas en DSL y reglas en mvel puro.

También como experiencia personal me queda como positivo la capacidad de cambio de reglas a medida que uno va aprendiendo más del lenguaje y cómo funciona. En un principio usamos hasta un RuleFlow para que un conjunto de reglas se ejecute antes que otras (se podría haber usado AgendaGroup también pero eso nos obligaba a setear el foco desde dentro de cada regla) y terminamos volando todo siendo este cambio completamente transparente a la aplicación.
Todo depende de definir un dominio agradable, y unas interfaces piolas, pero en sí, el flujo de evolución de Drools resultó absolutamente gratificante.
Como producto final puedo mostrarle el tipo de reglas que cualquier persona puede llegar a escribir:

regla “CA Cap Fed Rosario”
cuando
hay un envio de “Correo Argentino” con
ciudad de origen “Capital Federal”
ciudad de destino “Rosario”
entonces
el servicio es “Regional”
fin

El próximo paso del proyecto es manejar el flujo de un envío, así que voy a hacer todo lo posible para introducir Rule-Flow, no necesariamente porque haya hecho una comparación contra JBPM (del cual cuento con cierto background), sino que voy a intentar no diversificar tanto las tecnologías utilizadas. En las próximas entregas más novedades.

Primeros pasos con GIT-SVN
April 22, 2009

Partiendo de una infraestructura de SVN, todavía se puede aprovechar la versatilidad que te provee GIT para trabajar en tus modificaciones diarias e inestables (incluso muchas veces destructivas).
En el ejemplo voy a intentar hacer una demo con el svn de JBoss particularmente con el módulo de Drools.

$ git svn clone -s http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/ drools-upstream && cd drools-upstream

si bien es interesante hacer esto, tarda realmente mucho, mucho, MUCHO… me fui a dormir cuando iban 6 horas… y parece que daba para bastante más. Igual vale bien la pena si uno está pensando en colaborar con alguno de estos proyectos.
Para empezar a trabajar creamos un nuevo branch del master (o el trunk en jerga SVN)

$ git checkout -b mi-feature-loca

el -b nos situa directamente en ese branch.
Comandos relacionados con la interacción git-svn:

  • git svn fetch, trae todos los cambios del repositorio SVN remoto
  • git svn rebase, igual que el anterior pero hace fast-forward de nuestros commits así quedan alineados con el árbol principal (explotando cuando no puede resolver solo los conflictos)
  • git svn dcommit, envía nuestros cambios locales como sucesivos commits de svn con los mensajes exactamente como los teníamos localmente.

Cosas útiles en el desarrollo diario:

  • git branch muestra los branches que tenemos en nuestro repositorio local resaltando el que estamos parados. Para esto también está bueno tener agregado en algún lado del PS1 de bash lo siguiente $(__git_ps1 “#%s”) , que nos agrega el branch sobre el que se trabaja.
  • git status muestra el estado del index, que es la lista de los archivos conocidos por git.
  • git add para agregar los archivos del próximo commit. A diferencia de SVN hay que agregar cada archivo antes de commitear.
  • git commit es evidente, pero para los que prefieran ahorrarse el paso anterior, pueden hacer git commit -a que envía todos los cambios en el index.

Nota al pie:
Cada vez que quieras hacer un git svn rebase luego de haber felizmente levantado todo el entorno en eclipse o sencillamente habiéndole pasado el bienaventurado mvn eclipse:eclipse, git te va a decir que los .classpath y los .project están distintos, que los mergees.
Lo primero que tienen que hacer es aumentar el karma negativo hacia cualquiera de los core developers, esto puede ser aleatorio o en grupo da igual, por permitir que esto sea así. La idea final es que en su próxima vida vuelvan en modo alimaña–.
Después lo más sano es volar todos los archivos estos y dejarle que los vuelva a cero. Para ellos copien esta línea que hará su trabajo.

git checkout drools-ant/.classpath drools-api/.classpath drools-clips/.classpath drools-compiler/.classpath drools-container/drools-mc/.classpath drools-core/.classpath drools-decisiontables/.classpath drools-examples/drools-examples-drl/.classpath drools-examples/drools-examples-drl/.project drools-examples/drools-examples-fusion/.classpath drools-examples/drools-examples-fusion/.project drools-guvnor/.classpath drools-jsr94/.classpath drools-persistence-jpa/.classpath drools-pipeline/drools-messenger-jms/.classpath drools-pipeline/drools-transformer-jaxb/.classpath drools-pipeline/drools-transformer-jxls/.classpath drools-pipeline/drools-transformer-smooks/.classpath drools-pipeline/drools-transformer-xstream/.classpath drools-process/drools-bam/.classpath drools-process/drools-process-task/.classpath drools-process/drools-workitems/.classpath drools-repository/.classpath drools-server/.classpath drools-solver/drools-solver-core/.classpath drools-solver/drools-solver-examples/.classpath drools-templates/.classpath drools-verifier/.classpath

git checkout nos sirve para volver para atrás, al último estado commiteado, a un archivo.