WSO2 BRS: Uso de tablas de decisión en reglas de negocio.

La herramienta WSO2 BRS usa Drool como motor de reglas, lo que nos permite usar las funcionalidades de tablas de decisión basadas en documentos Excel en aquellos casos en que esta sea la mejor variante para implementar un servicio de reglas.

En una entrada de Chathurika Erandi aborda este escenario a partir de un documento excel que usa las mismas reglas descritas en la documentación de la herramienta. La entrada se puede consultar aquí.

Para probar el ejemplo de la entrada cree un documento excel a partir de la imagen plasmada en la entrada y que muestro a continuación.

En este excel se definieron las siguientes reglas:

• Una orden de la compañía A es aceptada si la cantidad es mayor que 10.
• Una orden de la compañía B es aceptada si la cantidad es mayor que 200 y el precio es mayor que 50.
• Una orden de la compañía C es aceptada si el precio es mayor que 100.
• Una orden de la compañía A no es aceptada si la cantidad es menor o igual que 10.
• Una orden de la compañía B no es aceptada si la cantidad es menor o igual que 200 y el precio es igual o menor que 50.
• Una orden de la compañía C no es aceptada si el precio es menor o igual que 100.

El siguiente paso fue crear un proyecto en el WSO2 Developer Studio, muestro a continuación como se hace:

Se abre el WSO2 Dashboard y se selecciona la opción Business Rules Service Project.

Se selecciona la opción de crear un nuevo proyecto:




Y se llenan los datos solicitados del proyecto:

Al dar clic en Finish se crea un proyecto con la siguiente estructura. Tengan en cuenta que ya he creado un paquete y agregado las clases necesarias para representar los datos a manejar y las posibles respuestas a devolver por el servicio.

Cuando el proyecto es creado se abre automáticamente el fichero service.rsl tal como se muestra a continuación:




A continuación debemos proceder al llenado de la sección de Reglas, dando clic en el botón Add. Aquí debemos tener en cuenta que usaremos un fichero excel para definir las reglas, en forma de una tabla de decisión.



En la pestaña file damos clic en Browse y cargamos el excel que previamente debió haberse guardado en <Project>/src/main/ruleservice/conf, quedando como sigue:




Luego procedemos a crear la operación dando clic en el botón Add. Debe quedar como sigue:

Y eso es todo. De esa manera podemos tener ya listo nuestro servicio.

Para terminar esta parte solo resta ir a la raíz del proyecto y ejecutar el siguiente comando maven:

mvn clean install y con eso en la carpeta target tendremos creado el fichero .aar que se debe desplegar en el WSO2 BRS.

Una vez realizado el proyecto procedí a desplegarlo en el WSO2 BRS y me encontré con varios errores:

Error 1:

org.wso2.carbon.rule.common.exception.RuleConfigurationException: Error during creating rule set: [8,34]: [ERR 101] Line 8:34 no viable alternative at input '")
  
        quantity > 10

  
    then

  
        OrderAccept orderAccept = new OrderAccept(); orderAccept.setMessage("Accepted order for: " + placeOrder.getQuantity() + "stock of " + placeOrder.getSymbol() + " at$ " + placeOrder.getPrice()); insertLogical(orderAccept);

  
end 



// rule values at C11, header at C5

Error 2:

[18,11]: [ERR 102] Line 18:11 mismatched input '>' in rule "'AcceptRules' dialect 'mvel'_11"
  
[28,8]: [ERR 102] Line 28:8 mismatched input '>' in rule "'AcceptRules' dialect 'mvel'_12"

  
[37,11]: [ERR 102] Line 37:11 mismatched input '<=' in rule "'Rejectrules'_19"

  
[46,11]: [ERR 102] Line 46:11 mismatched input '<=' in rule "'Rejectrules'_20"

  
[56,8]: [ERR 102] Line 56:8 mismatched input '<=' in rule "'Rejectrules'_21"

  
[0,0]: Parser returned a null Package

Los problemas encontrados se pueden detallar como sigue:

1. No hace falta que los símbolos estén entre comillas simples. Al inicio pensé que ese era el error y probé sin las comillas o con las comillas dobles y no fue la solución.
   
   
2. Falta la definición del objeto que contiene a los atributos quantity y price.
   
   
3. En el action de la tabla que contiene las reglas de rechazo se muestra una línea de codigo con el siguiente texto: “retract($placeOrder);” Fue necesario removerla para que se mostrada el mensaje de respuesta.
   
   

En el excel que muestro a continuación, solo una imagen parcial, ya estos problemas fueron resueltos. Pueden comparar el excel de la imagen del blog contra esta imagen o el excel que les comparto en el proyecto para que vean los ajustes a realizar.

 Para terminar les comparto el proyecto en la siguiente ubicación para que ustedes mismo creen el .aar y lo desplieguen en el WSO2 BRS.


En las pruebas que realicé luego de desplegar el proyecto pude apreciar que cuando se cumplía solo una de las condiciones de la regla para la compañía B no se devolvía un resultado y esto se debía a que en las reglas para devolver un resultado de no cumplimiento no se contemplaba esta posibilidad, solo devolvía resultado cuando se cumplían ambas reglas.


Para resolver este problema agregué 2 reglas y 2 condiciones nuevas como se puede apreciar a continuación.

De esta manera se puede de manera muy fácil manejar tablas de decisión usando en excel y la suite de WSO2.

Quisiera comentar que me fue de mucha utilidad durante el desarrollo modificar el excel en caliente con los cambios necesarios, esto llevaba a un redespliegue del servicio automáticamente y podía seguir probando.

Espero les sea de utilidad.

Read More [...]

Posted in BRS, decision, Drools, Excel, reglas de negocio, tabla de decision, table, WSO2, WSO2 Developer Studio

WSO2 BRS y WSO2 Developer Studio para el desarrollo de servicios de reglas de negocio

Los desarrolladores de software siempre estamos buscando como volver más ágiles nuestras aplicaciones, ya sea bien por un deseo propio o por los constantes cambios en el negocio. Tener la facilidad de modificar las reglas del negocio sin tener que sacar la aplicación de producción es el deseo de todo arquitecto.

Lo mismo pasa con los desarrolladores BPM que desean que sus procesos utilicen servicios de reglas, en vez de tener que implementarlas dentro del proceso.

Existe una necesidad de externalizar ese desarrollo de las reglas de negocio en sistemas que sean capaces de desplegarlas y ejecutarlas, y es ahí donde interviene WSO2 y su herramienta Business Rule Services o BRS, como la llamaremos a partir de ahora.

Esta herramienta permite desde su UI la implementación de servicios de reglas de negocio pero en esta ocasión quiero mostrarles las potencialidades del Developer Studio de WSO2 para la creación de reglas de negocio.

Precondiciones:

• Tener eclipse JUNO instalado. Si tiene la versión más actual del STS mejor.

• Tener el plugin Developer Studio 3.2.0 instalado en el IDE.

Paso 1:

Crear un proyecto “Business Rules Servic Project” usando el Developer Studio Dashboard.

Aquí los pasos son muy sencillos:

• Le dan a la primera opción para crea un servicio de reglas.

• Luego definen un nombre para el proyecto y un nombre para el servicio.

• Y luego Next  y Finish.

En mi caso tengo el siguiente proyecto creado:

Por defecto se les abre el fichero Service.rsl y bueno ya le he puesto algunas cosas así que me luce así. Veremos cada una ahora.

Paso 2:

He añadido una regla que se ve de la siguiente manera:

O sea le he puesto una descripción a la regla y en la opción inline he copiado el siguiente texto:

import aplicacion.rrhh.Empleado; 

      

    rule "Programador" salience 11 dialect "mvel" no-loop true 

        when 

            $empleado : Empleado (promedioConocimientos >= 8 ) 

        then 

               $empleado.setCargo("Programador"); 

               $empleado.setSalario(500); 

    end 

      

    rule "Lider de Proyecto" salience 10 dialect "mvel" no-loop true 

        when 

            $empleado : Empleado (promedioConocimientos >= 6, promedioConocimientos <= 7) 

        then 

               $empleado.setCargo("Lider de Proyecto"); 

               $empleado.setSalario(1000); 

    end 

      

    rule "Analista" salience 9 dialect "mvel" no-loop true 

        when 

            $empleado : Empleado (promedioConocimientos >= 3, promedioConocimientos <= 5) 

        then 

              $empleado.setCargo("Analista"); 

              $empleado.setSalario(2000); 

    end  

      

    rule "Gerente" salience 8 dialect "mvel" no-loop true 

        when 

            $empleado : Empleado (promedioConocimientos >= 0, promedioConocimientos <= 2) 

        then 

            $empleado.setCargo("Gerente"); 

            $empleado.setSalario(3000); 

    end

Veamos la traducción de este texto para aquellos que no dominan el leguaje de Drools:

Supongamos que tenemos una empresa X que quiere automatizar la forma en que le asigna el salario y el cargo a sus trabajadores en dependencia de su nivel de conocimientos. Esta es la forma en que lo hace:

El nivel de conocimientos va desde 0 y hasta más de 8. Mientras más conocimiento más alto el valor.

• Si el trabajador tiene 8 o más de conocimientos entonces es programador y su salario es de 500.
• Si el trabajador tiene 6 o 7 de conocimientos entonces es Líder de proyecto y su salario es de 1000.
• Si el trabajador tiene 3 o hasta 5 de conocimientos entonces es Analista y su salario es de 2000.
• Si el trabajador tiene 0 o hasta 2 de conocimientos entonces es Gerente y su salario es de 3000.

El servicio debe automatizarnos la asignación del rol y el salario al trabajador cuando le especificamos su nivel de conocimiento. Y eso es lo que aparece en el texto anterior, que se puede leer bastante fácil una vez que se tiene una comprensión de estas reglas para asignar rol y salario.

Ej.:  Esta regla:

    rule "Gerente" salience 8 dialect "mvel" no-loop true 

        when 

            $empleado : Empleado (promedioConocimientos >= 0, promedioConocimientos <= 2) 

        then 

            $empleado.setCargo("Gerente"); 

            $empleado.setSalario(3000); 

    end

Me dice que cuando un empleado tenga el nivel de conocimientos mayor o igual que cero y menos o igual que 2 tendrá el cargo de gerente y su salario será de  3000. Lo mismo se aplica para el resto de las reglas.

Seguimos.!!!!

Paso 3:

Vamos a crear ahora la clase que nos representa a un empleado. Para eso vamos a src/main/java dentro del proyecto, clic derecho y creamos una clase nueva:

Como ven es una clase muy sencilla, con los métodos get/set para cada uno de sus atributos.

Paso 4:

Volvemos al fichero  Service.rsl, a su pestaña de diseño y agregamos una operación nueva:

Para eso dan clic en el botón Add y luego la dejan de esta manera:

En mi caso la entrada es un objeto Empleado y la salida es el mismo objeto actualizado, por eso es que tanto la entrada como la salida se representan con la misma clase.

Y hasta aquí la implementación del servicio, porque ya está implementado. :-D

Ahora debemos desplegarlo en un BRS. En mi caso estaré usando uno local así que me aprovecharé de otras de las funcionalidades del WSO2 Developer Studio y crearé un servidor de WSO2 que me apunte al BRS que tengo.

Paso 5:

Para eso buscan la pestaña de Servers en el Eclipse y crear uno nuevo de la  siguiente manera:

En mi caso ya tenía  uno creado, si ustedes no lo tienen le dan a “Add”

Y ahí deben seleccionar usando el botón Browser la carpeta raíz de su BRS y listo.

El problema ahora es que el proyecto como lo tenemos no se puede desplegar en el BRS, para hacerlo debemos crear una Aplicación CARBON que nos empaquete este proyecto, y lo que desplegamos en el BRS es esta aplicación CARBON, que se encarga a su vez de desplegar el servicio de reglas.

Paso 6:

Para hacer esto volvemos al dashboard del Developer Studio y seleccionamos Carbon Application  Project.

Cuando lo hagan verán como nos lista todos los proyecto de WSO2 que tenemos en el workspace, y debemos seleccionar el de reglas de negocio. en mi caso luce así.

Le asignan un nombre y listo.

Luego es cosa de como cualquier aplicación web en java adicionarla al servidor CARBON que creamos antes y ejecutar el servidor.

Paso 7:

Cuando el servidor se inicie verán unos logs similares a estos:

[2013-07-02 23:33:19,741]  INFO - ApplicationManager Deploying Carbon Application : DespliegueReglaNegocio_1.0.0.car...

[2013-07-02 23:33:20,807]  INFO - ApplicationManager Successfully Deployed Carbon Application : DespliegueReglaNegocio {super-tenant}

[2013-07-02 23:33:36,890]  INFO - DeploymentInterceptor Deploying Axis2 service: SalaryRuleService {super-tenant}

[2013-07-02 23:33:36,949]  INFO - DeploymentEngine Deploying Web service: SalaryRuleService-1.0.0.aar -

[2013-07-02 23:33:42,927]  INFO - CarbonAuthenticationUtil 'admin@carbon.super [-1234]' logged in at [2013-07-02 23:33:42,927-0400]

Como ven nos ha desplegado la aplicación DespliegueReglaNegocio y esta a su vez nos ha desplegado el servicio SalaryRuleService-1.0.0.aar

Paso 8:

Abrimos la consola de administración, buscamos el servicio creado.

Y le damos “Try this Service”

Aquí tienen un pantallazo de la ejecución:

Y así en pocos pasos podemos tener creado un servicio web de reglas de negocio usando Drool y al cual podemos incorporarle todas las potencialidades de la suite de wso2 como son:

• Múltiples niveles de seguridad para la autenticación y autorización.

• Cacheo de la información.

• Filtrado por IP.

• Clusterización.

• Transparencia de ubicación.

• ……

Espero les resulte de utilidad y dejen su comentario.

Read More [...]

Posted in BRS, developer studio, Drools, reglas de negocio, WSO2

Las reglas de negocio automatizadas en el Business Rules Server de WSO2. I

En cualquier empresa u organización existen sistemas encargados de automatizar parte del trabajo. La implementación de estos sistemas software conlleva una fase de análisis y diseño donde los desarrolladores modelan el funcionamiento del mismo en diferentes escenarios, utilizando técnicas como los casos de uso, que se pueden presentar cuando los usuarios interactúan con el sistema.


Este modelado generalmente muestra determinadas decisiones que pueden ejecutar los usuarios y que se toman a partir de condiciones y bajo ciertos criterios. Estas decisiones, condiciones y criterios son codificadas en un lenguaje de programación y así es como nace el programa informático, el sistema software en cuestión.


Es muy común ver tanto en el modelado como en la implementación cosas como estas:
SI [ se cumplen condiciones/criterios] THEN [acción/decisión] ELSE [acción/decisión] esto no es otra cosa que una regla de negocio cuando implica decisiones de negocio, y son encapsuladas dentro de las aplicaciones y codificadas, lo que las hace muy difícil de cambiar.


Pero hay un problema, las empresas y organizaciones, cuyas decisiones, condiciones y criterios son codificadas dentro de un sistema software son entes cambiantes, y lo que hoy era una cosa mañana puede ser otra completamente distinta. Entonces: ¿qué pasa cuando las decisiones, condiciones y criterios cambian en el negocio? Pues las aplicaciones dejan de ser útiles y hay que modificarlas o cambiarlas. O seguirlas usando y obligar al negocio a no cambiar. Ese es uno de las causas del llamado GAP o distanciamiento entre el Negocio y los departamentos de TI que tanto afecta a las empresas.

Las decisiones, condiciones y criterios se conocen en el argot informático como reglas de negocio y pueden ser extraídas de los sistemas software para evitar que este tipo de problemas ocurran y se pueden usar herramientas que las automaticen y las pongan a disposición de cualquier aplicación que las necesite.
Si tomamos por ejemplo los sistemas de gestión de las universidades nos podríamos encontrar con reglas de negocio como estas.

Ej de reglas de negocio:

• SI el usuario es de tipo VIP ENTONCES  procesar su petición inmediatamente, SI NO si el monto de la petición supera los 200USD enviar la petición al director de área para su aprobación.
• SI la cantidad de peticiones durante 1 minuto es mayor de 200 ENTONCES adicionar un impuesto del 0.5%
• SI el estudiante tiene suspendidas 2 pruebas en la asignatura X ENTONCES no tiene derecho a presentarse a la prueba final de la asignatura X y se debe notificar al jefe de la asignatura correspondiente.
• SI el estudiante tiene 5 puntos en más de 10 preguntas escritas de la asignatura X ENTONCES convalidarle el próximo examen de dicha asignatura.
• SI existen más del 50 % de desaprobados en un grupo de clase ENTONCES notificar al jefe de asignatura correspondiente.
• SI el real de consumo eléctrico en la universidad sobrepasa el 100 % de lo planificado ENTONCES notificar al rector.
• SI el espacio de consumo en la bandeja de entrada de la cuenta de correos llega al 95 % ENTONCES enviar una notificación al usuario.

La empresa WSO2 ha desarrollado una herramienta que consiste en un Sistema para la Administración/Gestión de Reglas de Negocio o BRMS por sus siglas en inglés.
Esta herramienta conocida como Bussiness Rules Server o BRS, permite la gestión de la codificación, ejecución y mantenimiento del conjunto de reglas de negocio de una empresa u organización. Para lograr esto usa Drools, un framework desarrollado por la Empresa REDHAT para JBOSS facilitando la implementación de reglas de negocio.
BRS permite que estas reglas sean expuestas como servicios web, brindando todas las potencialidades de la plataforma Carbon, para que sean accesibles a cualquier sistema software que necesite consultar las reglas. Esto hace sumamente sencillo su consumo.
Aquellas organizaciones que apuestan por soluciones BPM deben apostar además por sistemas que permitan la gestión de las reglas de negocio. De esta manera las reglas están fuera del proceso pero son usadas por este y consumidas a través de llamadas a servicios web.
Lo que se podría hacer entonces con las aplicaciones propias que ya tenemos si quisiéramos irlas evolucionando y adecuarlas a las tecnologías actuales pasaría por los siguientes pasos.

• Extraer de todas las aplicaciones que ya tenemos desarrolladas las reglas de negocio.

• Codificar todas las reglas de negocio en un formato estándar usando Drools.

• Exponer las reglas de negocio como servicios web, usando los estándares ws-* para proveer seguridad, rendimiento, confidencialidad, etc. usando la suite de WSO2 y el BRS.

• Reimplementar los procesos de negocio eliminado la reglas implementadas en los mismos y consumiéndolas desde el BRS de WSO2.

Ventajas:

• Se hace evidente que todas las reglas implementadas con Drools y expuestas como servicios podrían ser reutilizadas fácilmente por múltiples aplicaciones.

• Además su mantenimiento y gestión en el tiempo se facilitaría de igual manera ya que al no estar codificada dentro de las aplicaciones, en cuyo caso requeriría una modificación de las mismas.

• El personal del negocio puede modificar las reglas de negocio, dárselas al personal técnico y este realizar los cambios. En caso de que se posea un sistema o componente que no requiera de habilidades técnicas o de programación entonces el mismo personal del negocio puede actualizar las reglas a ser expuestas a través de servicios web.

En otra entrada veremos cómo se pueden crear reglas de negocio usando esta herramienta y exponerla como servicios web.

Read More [...]

Posted in Arquitectura Orientada a Servicios, bpm, BRS, Drools, reglas de negocio, WSO2