Ir al contenido principal

Como configurar jBPM para usar nuestra propia Base de Datos en un sólo paso



Llevo un buen rato trabajando con jBPM en su serie 6.x, y mi opinión sobre este producto en la versión mecionada no ha mejorado para nada.

Es una herramienta plena de funciones y caracteristicas avanzadas, pero tambien está llena de Bugs y es realmente inestable, sobre todo en el ambiente de modelamiento. 

Así mismo, debo decir que tiene una muy aceptable API REST y que el motor de procesos y la consecuente ejecución de los procesos es estable y bastante rápida.

En esta publicación daré inicio a una serie de artículos que hablan sobre ciertas configuraciones comunes e importantes que se hacen con jBPM.

Hoy iniciamos con la configuración de jBPM para que use nuestra base de datos favorita.

Esto tiene sentido porque el producto viene con la base de datos H2 por omisión, la cual es excelente para pruebas y evaluaciones rápidas de la herramienta, pero es completamente inaceptable en un ambiente de desarrollo, QA o producción cualquiera.

Así que manos a las sobras, que digo, manos a las obras!!! jajajaja




Prerequisitos.

- Recuerde, como recomendación general para cualquier plataforma operativa (mac, linux guindows), nunca instale la JDK es una ruta o path que posee nombres de directorio con espacios en blanco.
- Recuerde configurar la variable de ambiente ANT_HOME con el path o ruta hacia la carpeta o directorio de instalación raíz del ANT.

  • Descargar el instalador de jBPM 6.x y descomprimirlo en un directorio adecuado, al cual llamaremos desde ahora JBPM_INSTALLER_HOME.

  • Tener instalada nuestra base de datos favorita y compatible con jBPM.
- Acá la lista de base de datos soportadas:
  • db2
  • derby
  • h2
  • hsqldb
  • mysql5
  • mysqlinnodb
  • oracle
  • postgresql
  • sqlserver
  • sqlserver2008

-Debe tener creado un Esquema o BD con un nombre apropiado para su instancia de jBPM, en este caso lo llamaremos jbpmdb (que creativo estoy) y usaremos Postgresql 9.x como motor de Base de Datos.

  • Tener una herramienta para la gestión de la base de datos a usar, que permita ejecutar scripts de sql. En este caso puede ser el PgAdmin, o la aplicación de consola del postgresql.

Iniciamos

1.- Configurar el acceso a datos.

1.1.-  Modificar o actualizar los archivos standalone-xxxxx.xml.

Vaya al directorio de instalación JBPM_INSTALLER_HOME, allí debe encontrar los archivos:
  • standalone-full-wildfly-8.1.0.Final.xml
  • standalone-wildfly-8.1.0.Final.xml

Para poder modificar con éxito estos archivos debe tener en claro los siguientes datos:
  • URL de conexión a la base de datos deseada. Verifique el nombre o IP del servidor, así como el nombre de la base de datos o esquema a utilizar.
  • Credenciales del usuario para acceder al servidor de base de datos. Debe usar el usuario adecuado con los permisos completos para el acceso a la BD.
  • Establecer el nombre del Driver que se configurará mas adelante.
En cada uno de ellos ubicar la sección  "datasources" que contiene:
<datasource jta="true" jndi-name="java:jboss/datasources/jbpmDS" pool-name="H2DS" enabled="true" use-java-context="true" use-ccm="true">
    <connection-url>jdbc:h2:tcp://localhost/~/jbpm-db;MVCC=TRUE</connection-url>
    <driver>h2</driver>
    <security>
        <user-name>sa</user-name>
    </security>
</datasource>

Y modificarla de acuerdo a los valores deseados, tal como se muestra a continuación:

<datasource jta="true" jndi-name="java:jboss/datasources/jbpmDS" pool-name="PostgreSQLDS" enabled="true" use-java-context="true" use-ccm="true">
    <connection-url>jdbc:postgresql://localhost:5432/jbpm</connection-url>
    <driver>postgresql</driver>
    <security>
        <user-name>jbpm</user-name>
        <password>jbpm</password>
    </security>
</datasource>


Recuerde que debe declarar o crear el datasource "PostgreSQLDS" en la consola de administración del servidor WildFly en la sección de DataSources.


1.2.- En los mismos archivos anteriores declarar el módulo de Driver a utilizar.

Esto consiste en adicionar información sobre el driver a usar, el cual ya se declaro en el paso anterior postgresql.

Así mismo debe declarar un nombre único para el Módulo del Dirver. Este nombre usa el formato separado por puntos, tal cual los nombres de paquetes en Java.  Este nombre de módulo debe corresponder al valor de la propiedad db.driver.module.prefix que modificaremos en el archivo build.properties mas adelante en este tutorial.

En la sección   ubicar la sección "drivers" :

<drivers>
    <driver name="h2" module="com.h2database.h2">
        <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
    </driver>
</drivers>

Y agregar la definición de Módulo de Driver que deseamos:
<drivers>
    <driver name="h2" module="com.h2database.h2">
        <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
    </driver>
    <driver name="postgresql" module="org.postgresql">
        <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
</drivers>

Note el nombre del módulo module="org.postgresql", el cual se hará corresponder con el valor de la propiedad db.driver.module.prefix = "org/postgresql" en el archivo build.properties antes mencionado, y con la propiedad name del archivo de módulo del paso siguiente.


1.3.- Crear el archivo para el Módulo de Driver.

En el siguiente directorio:

JBPM_INSTALLER_HOME/db

Crear el archivo postgresql_module.xml con el siguiente contenido:

<module xmlns="urn:jboss:module:1.0" name="org.postgresql">
   <resources>
     <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
   </resources>
</module>

El nombre postgresql  del arrchivo module.xml debe corresponder o corresponderá al valor de la propiedad db.name del archivo build.properties, según este criterio db.name_module.xml.


1.4.- Modificar el archivo  build.properties.

 En el directorio JBPM_INSTALLER_HOME ubicar el archivo build.properties y ubicar y comentar la sección correspondiente a la configuración para el H2.

# default is H2
# H2.version=1.3.168
# db.name=h2
# db.driver.jar.name=h2-${H2.version}.jar
# db.driver.download.url=http://repo1.maven.org/maven2/com/h2database/h2/${H2.version}/h2-${H2.version}.jar


Y descomentar o agregar la configuración correspondiente a la base de datos Postgresql o la de su elección:

#postgresql
db.name=postgresql
db.driver.module.prefix=org/postgresql
db.driver.jar.name=postgresql-9.1-902.jdbc4.jar
db.driver.download.url=https://repository.jboss.org/nexus/content/repositories/thirdparty-uploads/postgresql/postgresql/9.1-902.jdbc4/postgresql-9.1-902.jdbc4.jar

Note que se declara una URL desde la cual descargar el driver correspondiente a nuestra BD de elección. Existe la posibilidad de descargar el driver (.jar) adecuado en forma manual, y dejarlo en el siguiente directorio:

JBPM_INSTALLER_HOME/db/driver

De modo que el servidor pueda reconocerlo y usarlo en correspondencia. En esta opción es conveniente dejar comentada la propiedad db.driver.download.url.


1.5.- Cambiar el dialecto de la base de datos para hibernate.

En el siguiente directorio:

JBPM_INSTALLER_HOME/db

Ubicar el archivo jbpm-persistence-JPA2.xml, y modificar la declaración del dialecto de la base de datos del valor para H2 por el dialecto de nuestra BD favorita, Postgresql en este caso.
Original:
<property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>

Cambiar por:
<property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>

Ahora viene un paso importante a tener en cuenta.


1.6.- Modificar archivo .war de la aplicación console de jBPM.

Ir al directorio siguiente:

 JBPM_INSTALLER_HOME/lib

Ubicar el archivo .war correspondiente al console de jBPM, en la versión 6.3 es el siguiente:

jbpm-console-6.3.0.Final-wildfly-8.1.0.Final.war

Abrir con una herramienta adecuada para archivos comprimidos, winzip, 7zip, o la herramienta correcta para su plataforma que le permita modificar el .war en cuestión.

Dentro del .war  ubicar el directorio /WEB-INF/classes/META-INF y abrir el archivo persistence.xml  para su modificación. Allí modificar la propiedad:

<property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>

Y cambiar por el nuevo valor:
<property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>

Como ve son los mismos valores y propiedad que en el paso anterior. Luego se debe proceder a guardar los cambios y cerrar el editor del comprimido .war. Si la aplicación le pregunta por sí desea guardar los cambios responder que si.


1.7.- Ejecutar los scripts de sql para construir las estructuras de datos en la base de datos.

Vaya al directorio siguiente:

JBPM_INSTALLER_HOME/db/ddl-scripts/

Ubique el directorio de los scripts de sql que corresponda a su BD deseada, en este caso usaremos el directorio postgresql, allí ubicamos dos archivos:

  1. postgresql-jbpm-schema.sql
  2. quartz_tables_postgres.sql
Debe ir a la aplicación de gestión de su base de datos y ejecutar esos scripts en el orden dado con anterioridad.


1.8.- Instalar y ejecutar el servidor.

Por la consola de comandos de su sistema, vaya al directorio:

JBPM_INSTALLER_HOME

Y ejecute los comando adecuados para instalar el ambiente y ejecutarlo.

Para instalar ejecute el comando:

ant install.demo.noeclipse

Para ejecutar el servidor ejecute:

ant start.demo.noeclipse

Para detener el servidor ejecute:

ant stop.demo


Listo. Ya deberíamos tener un ambiente de jBPM configurado para usar nuestra propia base de datos, Postgresql en nuestro ejemplo.

Vieron que era UN SÓLO PASO!!! claro.... dividido en 8!!! jajajajajaa detalles, detalles.

Comentarios

  1. Buen dia:

    Tengo todo configurado y la persistencia a nivel de datos del runtime se ve reflejada en mi bd de mysql pero cuando deseo guardar informacion correspondiente a un objeto de datos el cual esta siendo capturado por un formulario de tarea me sale el siguiente error

    Unexpected error encountered : Unknown entity: comercial.Prospectos

    a que se debe este error

    Agradezco su colaboracion

    ResponderEliminar
  2. Hola Alejandro.
    ¿Por casualidad estas guardando tus datos en el mismo esquema del motor de jBPM?, es decir, ¿usas el mismo DataSource de JBPM para acceder a tus propios registros o tablas?
    -Sí es así, te recomiendo no hacerlo. No mezcles los datos de tu aplicación con los del jBPM. Es mejor que crees tu propio DataSource (DS) y lo referencies desde tus aplicaciones. Aunque obviamente esa no era tu pregunta, pero es un consejo asociado.
    -El error que me señalas indica que el DS no encuentra ninguna configuración para tu Bean o Entity.
    -También suele ocurrir que no conoce la Clase, es decir no consigue la clase en ningún .jar del ambiente.
    -Por lo general es conveniente indicarle a jBPM como lidiar con nuestro propio modelo de datos, el los graba o guarda ya sea por serialización (dentro de la BD del motor) o por JPA.
    Te voy a dejar unos enlaces que pueden ayudarte:
    -http://planet.jboss.org/post/jbpm_6_store_your_process_variables_anywhere
    -https://marianbuenosayres.wordpress.com/2013/05/14/creating-your-own-drools-and-jbpm-persistence-infinispan/

    No soy un experto en esa configuración porque normalmente mis aplicaciones externas son las que persisten su data aparte de la del motor de BPM.
    Espero esta información le sea de utilidad.

    Saludos

    ResponderEliminar
  3. Buen dia

    Gracias de antemano por la atencion

    Si señor estoy usando el mismo datasource para los dos tipos de persistencia del jbpm, lo hice asi porque intente configurar dos datasource diferentes es decir en el persistence.xml hacia referencia a otro diferente al del aplicativo pero me arrojaba el siguiente error al construir y desplegar el proyecto "No Persistence provider for EntityManager named org.jbpm.task"

    la unidad de persistencia estaba definida de la siguiente forma




    org.hibernate.ejb.HibernatePersistence
    java:jboss/datasources/taskDS
    comercial.Prospecto
    false


















    y el datasource


    jdbc:mysql://localhost:3306/task
    mysql

    1
    40
    false
    false
    FailingConnectionOnly


    task
    task


    SELECT 1
    false
    false

    ResponderEliminar
  4. Para lograr tu objetivo tendrías que registrar una marshalling strategy propia en tu kie-deployment-descriptor descriptor con la unidad de persistencia especifica de tu Kjar (persistence.xml).

    Las versiones previas de la JPAPlaceholderResolverStrategy que venían con JBPM (anteriores a 6.5) se tragaban todas las entidades que les pasaras, las manejasen o no, así que nosotros tuvimos que hacernos las nuestra propia (No esta liberada).

    En su día reportamos el Bug y ya lo corrigieron para versión 7.x en adelante.

    Lo dejo aquí como referencia.

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

El Melange todavía corre

Ese era el estribillo de un capítulo de unas de mis series favoritas de la infancia, Meteoro o Speed Racer. En ese capítulo un auto “fantasma” el X-3, aparecía de imprevisto y dejaba a todos asombrados con su rendimiento y prestaciones y volvía a desaparecer. Traigo ese episodio a colación puesto que recientemente sostuve una amena charla con un querido amigo, en la que el me manifestaba como los Mainframes habían muerto, o mejor dicho, el concepto de la computación distribuida basada en Mainframes había desaparecido. Para variar, yo no estuve de acuerdo, y le dije que por el contrario, el modelo de computación basado en Mainframes está mas vigente que nunca. Estos fueron mis argumentos:

Primeros pasos con Camunda BPM – Modelando un Proceso BPMN 2.0

Tenemos entre manos la tercera publicación de nuestra serie sobre la Plataforma de BPM de Camunda .  El día de hoy vamos, por fin, a empezar a modelar o construir nuestro primer proceso sencillo en notación BPMN 2.0. Para ello vamos a usar el modelador o editor que ya hemos instalado en nuestra primera publicación , y vamos a guardarlo en la sección de recursos del proyecto Maven Java que configuramos en la segunda publicación . Así que, como ya es costumbre, manos a las sobras…