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.

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