Los procesos de negocio pueden tener varios caminos de ejecución distintos. En algunos casos la decisión que determina el camino de ejecución del proceso de negocio puede estar determinado por una decisión de negocio. Por ejemplo, si se determina que un cliente es VIP se puede querer dirigir el flujo del proceso de negocio por un camino alternativo para tratarle de forma especial por su condición de cliente VIP, esta decisión se puede realizar mediante una regla de negocio («business rule»). También, el propio hecho de determinar si el cliente es VIP puede ser realizado por otra regla de negocio. Con lo que podemos aplicar las reglas de negocio al menos a dos escenarios:
- Para dirigir el flujo de un proceso de negocio. A este tipo de reglas de negocio se les denomina reglas con lógica de decisión («Decision logic rules»).
- Para tratar información en base a definiciones, operaciones y restricciones. A este tipo de reglas se les denomina reglas con lógica de negocio («Business logic rules»).
Una regla de negocio con lógica de decisión que podría dirigir el flujo de un proceso de negocio podría ser:
- Si el cliente es VIP enviar paquete por transporte urgente.
La regla de negocio que determina si el cliente es VIP y una regla con lógica de negocio podrían ser:
- Si el cliente ha realizado una compra por importe superior a 100€ el cliente es VIP.
- Si el cliente es VIP aplicar un descuento de 10€.
Estos son unas pocas reglas de negocio y bastante sencillas, en un sistema real podría haber muchas más y más complicadas. Por ejemplo, se podría querer aplicar descuentos a ciertos tipos de productos como libros o DVDs o descuentos cuando se compren varios productos relacionados a la vez. Esto se puede complicar suficientemente para que si se realizan las reglas de negocio mediante código de un lenguaje de programación tradicional como Java o C#, el código se convierta en poco mantenible y que pondría dificultades para adaptar una aplicación suficientemente rápido a los cambios que se producen en negocio.
Algunas ventajas de las reglas de negocio son:
- Están documentadas y puede ser gestionadas, no es un conocimiento que posean las personas en sus cabezas.
- Las reglas de negocio puede estar escritas en un lenguaje entendible por las personas de negocio. La gente de negocio puede verificar la lógica y cambiarla.
- No se utiliza código de programa en algún lenguaje de programación que probablemente con el tiempo se convierta en código spaghetti y que no es entendible por las personas de negocio.
- Es más fácil, flexible y rápido modificar las reglas de negocio que el código de programa equivalente en Java o C#. Se pueden modificar independientemente del código ya que las reglas no se encuentran en la aplicación.
En el siguiente enlace puedes encontrar otros motivos y ventajas,
¿Por qué usar reaglas de negocio?. Las reglas en definitiva contienen parte del conocimiento del negocio, los sistemas que se encargan de aplicarlas son denominados BRMS («Business Rule Management Systems»). Un ejemplo de BRMS es
Drools y este puede ser usado en combinación con Activiti encargándose de esta forma cada unos de ellos del área especifica para el que están destinados, Drools para las reglas y Activiti para los procesos.
Veamos ahora un ejemplo similar al realizado en
Usar variables en un proceso de negocio con Activiti pero usando reglas de negocio. El diagrama del proceso de negocio es el siguiente:
Mediante la tarea «Determinar Tipo Cliente» se determina el tipo de cliente en función del importe de la compra de un cliente valor que se toma de una variable del proceso de negocio del mismo nombre. En la tarea «Determinar Descuento» se determina el descuento a aplicar en función del tipo de cliente asignado en la tarea anterior. Estas dos tareas son ejemplos de reglas con lógica de negocio. Finalmente, el envío se realiza también en función del tipo de cliente dirigiendo el flujo del proceso mediante un gateway exclusivo, «Envío Normal» si el cliente es normal o «Envío Urgente» si el cliente es VIP. Este es un ejemplo de regla de negocio con lógica de decisión.
Veamos ahora el proceso de negocio en notación BPMN:
En esta definición la etiqueta «businessRuleTask» se encarga de ejecutar las reglas de negocio indicadas en el atributo «activiti:rules» con los siguientes hechos (denominados facts en la jerga de los sistemas de reglas) o variables «${cliente},${importe}» indicados en «activiti:ruleVariablesInput». Tambien se ve como es un gateway exclusivo en el xml, de él parten dos «sequenceFlow», se tomará el camino para el que se cumpla su «conditionExpression».
Ahora el código de las reglas de negocio para determinar el tipo de cliente, las reglas para determinar el descuento y el tipo de envío son muy parecidas y pueden verse en el
código fuente del ejemplo:
Una regla de negocio es básicamente una condición que se evalúa para los hechos insertados en la base de conocimiento y en caso de cumplirse se ejecuta su parte then. Veamos ahora los teses unitarios para probar este proceso de negocio.
Las reglas de negocio para los teses se añaden a activiti como deployments de la misma forma que se hace para los procesos de negocio. Para que los deployments de las reglas de negocio de drools sean detectados correctamente hay que asignar un «customPostDeployer» al bean «processEngineConfiguration». También hay que añadir las siguientes dependencias al proyecto «org.drools:drools-core:5.4.0.Final», «org.drools:drools-compiler:5.4.0.Final» tal y como se puede ver en el archivo build.gradle del código fuente del proyecto.
Finalmente, el programa para ejecutar este proceso de negocio y su salida:
Referencia:
Conceptos sobre procesos de negocio (BP, BPM, BPMS, ...)
Procesos de negocio con Activiti
Usar variables en un proceso de negocio con Activiti
Tratamiento de errores en procesos de negocio con Activiti
Código fuente del ejemplo Reglas de Negocio con Activiti
