2008.06.08.Introduccion a un BPM.pdf - Willy .Net

Introducción sobre BPM
BPM es un paradigma para la administración de procesos de negocio. El concepto es algo
abstracto y en realidad engloba numerosas actitudes y tareas a desarrollar en una empresa, pero en
nuestro caso lo enfocaremos a una de sus técnicas principales: La gestión de procesos de negocio a
través de flujos, lo que se suele denominar workflow.
Mediante BPM se persigue el modelado de las actividades de negocio para lograr una mejor
administración, automatización y optimización.
El sistema implantado en una empresa para lograr estos objetivos y adherirse al paradigma lo
denominan BPMS.
Algunos ejemplos de aplicaciones de BPM o motivos de implantación son las que siguen:
Implantación o mejora del sistema de calidad
Comprensión y mejora de procesos
Establecimiento real de SLA
Reingeniería de procesos
Optimización de tareas
Establecimiento de metodología a nivel de empresa
Control y seguimiento de los procesos organizativos
Como hemos señalado, nosotros nos centraremos en los flujos de negocio, técnica que permite
acercar el analista al programador mejorando la comprensión y la comunicación mediante diseños
gráficos de secuencias de tareas que conjuntamente realizan una función de alto nivel e importancia
para los objetivos de una empresa.
Representan una formalización de la ordenación requerida de este tipo de procesos, que
mediante las herramientas o software adecuado puede ser explotado para mejorar desde varias
perspectivas la secuenciación de tareas de negocio.
Mediante un workflow se estudian los aspectos operacionales de una actividad de trabajo: cómo
se estructuran las tareas, cómo se realizan, cual es su orden, cómo se sincronizan o la manera en que
se relacionan unas con otras.
Existen numerosas implementaciones para establecer un workflow, algunas privadas como W4
y otras públicas como OpenSymphony o JBPM.
Algunos estándares han surgido en los últimos años para la definición de flujos de trabajo. Dos
de los más importantes son:
• XPDL: Para definición de flujos de trabajo en formato XML
• BPEL: Proporciona facilidades para la orquestación de servicios, combinación de servicios
web para conseguir un flujo de negocio.

Figura 1. Ejemplo básico de un proceso de negocio con nodo de decisión
Implementación de BPM con JBPM
BPM es una idea, un paradigma o un concepto. Existen numerosas implementaciones de este
modelo tanto libres como privadas. Una de ellas es JBPM, solución de JBOSS para java
actualmente en su versión 3.2.
Breve descripción del framework
JBPM es una implementación en Java de BPM que facilita la creación de flujos de procesos de
negocio permitiendo la integración de procesos para la unión de personas y aplicaciones
Soporta dos lenguajes de proceso:
- JPDL: Enfocado a la definición de flujos de procesos en Java.
- BPEL: Proporciona facilidades para la orquestación de servicios, combinación de servicios
web para conseguir un flujo de negocio. El soporte BPEL se encuentra de momento en fase
Beta, pero se añadirá en un futuro a JBPM.
Las dos características más potentes o útiles de BPM y en concreto de JBPM son su orientación
gráfica y la persistencia en la BD.
JBPM enfoca su filosofía hacia GOA. Mediante un gráfico se diseña el flujo y posteriormente se
le dota de la lógica necesaria mediante mapeos con clases de Java. De este modo se crea un nexo
entre el analista o diseñador y el programador. Existen herramientas para diseñar estos flujos.
Utilizaremos GPD, un plugin para Eclipse de fácil manejo e instalación.

JBPM tiene la capacidad de persistir los flujos. En los lenguajes tradicionales no existen
situaciones de parada y espera de notificación de modo que ese thread pueda ser guardado en la
base de datos. De modo que no hay soporte para situaciones de asincronía sin que el thread continúe
corriendo.
JBPM modela flujos de negocio que básicamente son maquinas de estados, aunque los flujos
son algo más que eso. De este modo cualquier cosa que sea susceptible de ser una maquina de
estados finitos puede ser modelada con un BPM: navegación web, procesos de backup, sistemas
empotrados de control, autómatas totales en general. Realmente la mayor parte de sistemas
informáticos pueden ser modelados así, la cuestión es si es viable o conveniente
JBPM es básicamente una librería de clases Java y viene distribuida en un JAR, de este modo
puede quedar embebida en cualquier tipo de aplicación: web, swing, en servidor, en cliente, etc.
Desde la página de JBOSS podemos descargarnos el paquete entero del framework. Este incluye
los siguientes elementos distribuidos en carpetas:
• config: ficheros de configuración para un entorno java estándar
• db: Scripts SQL para la creación de la base de datos en los SGDB más comunes
• designer: Plugin de eclipse para diseñar gráficamente los flujos de negocio
• doc: Guía de usuario y javadoc del API
• examples: Ejemplos de implementación de flujos.
• lib: Binarios de la distribución
• server: Un servidor de aplicaciones JBOSS que contiene una implementación JBPM para
una aplicación de consola vía Web
• src: Fuentes de la distribución y componente de identidad de JBPM
Perspectivas de JBPM
Existen numerosas formas de analizar un framework. JBPM como hemos explicado con
anterioridad tiene como principales virtudes su orientación a ejecución de flujos de procesos
diseñados gráficamente y la persistencia en la base de datos que soporta su estabilidad en la gestión
de procesos.
Comportamiento de JBPM a nivel de base de datos
JBPM utiliza hibernate para gestionar la persistencia de sus datos. Mediante ficheros de
mapeo HBM preestablecidos en la configuración del marco es capaz de almacenar todo lo
relacionado a un flujo de negocio definido y ejecutado de modo transparente al programador al
margen de una situación especial en la que se desee intervenir en esa persistencia.
El framework proporciona scripts de creación de base de datos para las más comunes:
Oracle, PostgreSQL o SQLServer.

De este modo el modelo de datos original de JBPM contiene 33 tablas que gestionan datos
estáticos de definición de flujos y datos dinámicos de instancias de esos flujos.
Comportamiento de JBPM a nivel de procesos
JBPM está implementado en Java, de modo que corre sobre una JVM.
Mediante un fichero XML en JPDL se define el flujo de negocio que representa lo diseñado
gráficamente, el plugin de eclipse u otra herramienta de diseño se encarga de actualizar el fichero
conforme modificamos el gráfico aunque también podemos editarlo manualmente.
Una vez definido el flujo, las clases del framework con DOM4J parsean el XML. Se puede
definir mediante un String en formato XML, empaquetado en un fichero .par o en un fichero XML
libre.
Una vez parseado se busca esta definición por id en su base de datos en la tabla , si no la
encuentra realiza el deploy de toda la información referente al flujo, después se ejecuta el flujo,
conforme a lo definido en el grafico y a las clases java.
Si el flujo se encuentra definido ya, simplemente inicia la instancia ya que la información de
éste ya se encuentra desplegada. En caso de que se desee iniciar una instancia anterior, se buscará
su id_ en la tabla “jbpm_process_instance” y se reiniciará o reanudará el flujo.
Cuando se ejecuta el flujo, se dan facilidades para efectuar paradas asíncronas, abortar el
proceso, controlar el runtime de ejecución, etc.
Existe un elemento Token, una clase del framework. Cada instancia de token representa un
hilo de ejecucion en el flujo, de modo que virtualmente se va desplazando por los nodos conforme
se avanza en la ejecución. Si se bifurca un nodo se creará un nuevo hilo de ejecución y un nuevo
token.
Los elementos son los que se pueden esperar en un grafo de este tipo: Nodos que ejecutan
acciones, transacciones que conectan unos nodos con otros, estados de inicio y fin, bifurcaciones,
decisiones, uniones, ...
La ejecución del flujo en sí no difiere de la de cualquier aplicación en Java que persista
valores en la base de datos durante su ejecución.
Para poder ejecutar un flujo en nuestros proyectos nosotros utilizaremos el servicio Spring
BPMService, en la capa Business Process de neoplatform. Este elemento nos da en un principio
facilidades para implementar y manejar nuestros flujos de negocio. En la versión 2.8.1 del
framework envuelve dos implementaciones BPM: JBPM y Oracle Workflow.

Pasos para la creación y ejecución de un flujo
*Este paso no es necesario pues ya ha sido realizado en la implementación del servicio de neo.
Instalación
Los pasos a realizar para utilizar JBPM son los siguientes:
• Descargar la suite completa de JBPM de la web de JBOSS *(Sólo GPD)
• Ejecutar script para crear las tablas en la base de datos requerida.
• Instalar el plugin GPD para Eclipse bien por el update site o copiando directamente
las librerías descargadas correspondientes en las carpetas feature y plugin de Eclipse
• Añadir el jar de jbpm al classpath del proyecto *
Creación
Una vez tengamos instalado todo lo necesario comenzaremos a diseñar el flujo. Para ello
debemos seguir los siguientes pasos(una forma de hacerlo):
• Mediante el plugin GPD, diseñar el flujo con los tipos de nodo necesarios para las
necesidades del negocio.
• En los nodos que tengamos que realizar algún trabajo de negocio definir los actions
con la clase que los implementa. Si se establecen tareas definir swimlanes o roles de
ejecución.
• Inyectar en un fichero de configuración de Spring las clases definidas en los actions
• Configurar en un fichero de Spring el datasource para la base de datos y la
configuración general y de mapeos de hibernate *** (Comprobar parámetros del
datasource)
• Crear un testcase de JUnit que realice una prueba del comportamiento deseado del
flujo. En caso de existir varios caminos de ejecución o posibles comportamientos
distintos, parametrizar el test o crear tantos métodos de test como caminos a
explorar. Este modo de realización sigue la metodología TDD, de modo que
podamos pensar en el diseño anterior antes de codificar las acciones que ejecutarán
la lógica de negocio
• Crear las clases de los actions en los paths definidos implementando las acciones a
realizar y las decisiones de propagación de flujo
Ejecución
• Una vez definido e implementado el flujo, ejecutar el testcase comprobando que todos
nuestros assert dan positivo (barrita verde). Puede ser útil colocar trazas simples por
consola o de log4java en algunos puntos.
• Una vez hemos asegurado que el testcase responde como esperamos, integrar el flujo
con la aplicación y realizar de nuevo las pruebas de su funcionamiento.
• Subir el flujo y las clases de acción a nuestro sistema de control de versiones

Consideraciones y posibles errores
- La intención de BPM con su filosofía GOA no es la misma que la de un diagrama de
secuencias o de colaboración de UML: Este modela la interacción de una parte de la
aplicación a nivel de negocio interno, especificando al detalle las llamadas a los métodos
incluso con su signatura y los objetos involucrados de modo que teóricamente un
programador no debe necesitar tomar decisiones arquitectónicas ni prácticamente de diseño
y se limitara a la implementación ya que están pensados en principio para llegar a un nivel
de detalle suficiente para evitarlo. BPM sin embargo está pensado para una comprensión del
negocio a alto nivel, diseñando tareas de alto nivel y flujos de alto nivel. Un nodo bien
podría desembocar mensajes a cientos de objetos. Implementar un flujo a este nivel de
detalle no es el objetivo y además provocaría un exceso. El control de la lógica se volvería
más complicado, la persistencia continua en base de datos ralentizaría la ejecución y
aumentaría drásticamente el número de registros en la base de datos y la virtud de acercar el
técnico al responsable de negocio o al diseñador desaparecería.
- BPM no soluciona los problemas del negocio. Puede simplificar el desarrollo o facilitar la
trazabilidad, la comprensión o la integración pero se construye sobre lógica de negocio ya
definida. Es un elemento de construcción superior que utiliza la lógica creada para mejorar
la solución o para diseñarla a muy alto nivel, no para decidirla.
- BPM no es algo mágico ni ninguna panacea. Realmente es una aproximación para mejorar a
muchos niveles los procesos de negocio y pueden ser útiles, sin embargo no aportan algo
realmente innovador y espectacular. Las revoluciones o innovaciones informáticas llegan a
cuenta gotas y al cabo de muchos años, las revoluciones de marketing llegan cada vez que
abres el explorador o el oído.
- BPM no es maleable como la plastilina. Aunque da ciertas facilidades para manejar de un
modo interesante y en ocasiones más sencillo los flujos de negocio, la implementación y
modificación de éste no difiere mucho de un modelo clásico. Incluso con el soporte de una
herramienta CASE, características como evolución dinámica o mantenimientos correctivos
al vuelo (al menos en mi conocimiento y a nivel comercial) todavía no están logradas.
Referencias de interes
• Guía de usuario de JBPM en la Web de JBOSS disponible en formato PDF y HTML
online: http://docs.jboss.com/jbpm/v3/userguide/
• Página web del framework neo: web neoplatform
• Descarga de JBPM 3.2(JBOSS JBPM jPDL Suite) starter kit suite JBPM