Un motor de reglas de negocio es un sistema de software que ejecuta una o más reglas de negocio en un entorno de producción en tiempo de ejecución . Las reglas pueden provenir de una regulación legal ("Un empleado puede ser despedido por cualquier motivo o sin motivo alguno, pero no por un motivo ilegal"), de una política de la empresa ("Todos los clientes que gasten más de 100 $ a la vez recibirán un descuento del 10 %") u otras fuentes. Un sistema de reglas de negocio permite definir, probar, ejecutar y mantener estas políticas de la empresa y otras decisiones operativas por separado del código de la aplicación .
Los motores de reglas generalmente admiten reglas, hechos, prioridad (puntaje), exclusión mutua, condiciones previas y otras funciones.
El software de motor de reglas se proporciona comúnmente como un componente de un sistema de gestión de reglas de negocios que, entre otras funciones, proporciona la capacidad de: registrar, definir, clasificar y gestionar todas las reglas, verificar la consistencia de las definiciones de reglas (“Los clientes de nivel Gold son elegibles para envío gratuito cuando la cantidad de pedido > 10” y “cantidad máxima de pedido para clientes de nivel Silver = 15”), definir las relaciones entre diferentes reglas y relacionar algunas de estas reglas con aplicaciones de TI que se ven afectadas o necesitan aplicar una o más de las reglas.
En cualquier aplicación de TI , las reglas de negocio pueden cambiar con más frecuencia que otras partes del código de la aplicación. Los motores de reglas o motores de inferencia sirven como componentes de software conectables que ejecutan reglas de negocio que un enfoque de reglas de negocio ha externalizado o separado del código de la aplicación. Esta externalización o separación permite a los usuarios de negocio modificar las reglas sin necesidad de intervención de TI. El sistema en su conjunto se vuelve más fácilmente adaptable con dichas reglas de negocio externas, pero esto no excluye los requisitos habituales de control de calidad y otras pruebas.
Un artículo en Computerworld rastrea los motores de reglas hasta principios de la década de 1990 y hasta productos de empresas como Pegasystems , Fair Isaac Corp, ILOG [1] y eMerge [2] de Sapiens .
Los esfuerzos de muchas organizaciones en materia de reglas combinan aspectos de lo que generalmente se considera diseño de flujo de trabajo con el diseño de reglas tradicional. Esta falta de separación de los dos enfoques puede generar problemas con la capacidad de reutilizar y controlar tanto las reglas de negocio como los flujos de trabajo. Los enfoques de diseño que evitan este dilema separan el papel de las reglas de negocio y los flujos de trabajo de la siguiente manera: [3]
En concreto, esto significa que una regla de negocio puede hacer cosas como detectar que se ha producido una situación de negocio y generar un evento de negocio (normalmente transmitido a través de una infraestructura de mensajería) o crear conocimiento de negocio de nivel superior (por ejemplo, evaluar la serie de reglas organizativas, de productos y normativas sobre si un préstamo cumple o no con los criterios de suscripción). Por otro lado, un flujo de trabajo respondería a un evento que indicara algo como la sobrecarga de un punto de enrutamiento iniciando una serie de actividades.
Esta separación es importante porque el mismo juicio empresarial (la hipoteca cumple con los criterios de evaluación) o evento empresarial (el enrutador está sobrecargado) puede ser objeto de reacción por parte de muchos flujos de trabajo diferentes. Incorporar el trabajo realizado en respuesta a la creación de conocimiento basada en reglas en la propia regla reduce en gran medida la capacidad de las reglas empresariales para reutilizarse en toda la organización, ya que las hace específicas del flujo de trabajo.
Para crear una arquitectura que emplee un motor de reglas de negocio es esencial establecer la integración entre una plataforma BPM (Business Process Management) y una BRM (Business Rules Management) que se base en procesos que respondan a eventos o examinen juicios de negocio definidos por reglas de negocio. Existen algunos productos en el mercado que proporcionan esta integración de forma nativa. En otras situaciones, este tipo de abstracción e integración deberá desarrollarse dentro de un proyecto u organización en particular.
La mayoría de los motores de reglas basados en Java proporcionan una interfaz técnica a nivel de llamada, basada en el estándar de interfaz de programación de aplicaciones (API) JSR-94, para permitir la integración con diferentes aplicaciones, y muchos motores de reglas permiten integraciones orientadas a servicios a través de estándares basados en la Web como WSDL y SOAP .
La mayoría de los motores de reglas ofrecen la posibilidad de desarrollar una abstracción de datos que representa las entidades y relaciones comerciales en función de las cuales se deben escribir las reglas. Este modelo de entidad comercial normalmente se puede completar a partir de una variedad de fuentes, incluidos XML , POJO , archivos planos , etc. No existe un lenguaje estándar para escribir las reglas en sí. Muchos motores utilizan una sintaxis similar a Java , mientras que algunos permiten la definición de lenguajes personalizados y compatibles con las empresas.
La mayoría de los motores de reglas funcionan como una biblioteca invocable. Sin embargo, cada vez es más común que se ejecuten como un proceso genérico similar a la forma en que se comportan los RDBMS . La mayoría de los motores tratan las reglas como una configuración que se carga en su instancia de proceso, aunque algunos son en realidad generadores de código para toda la instancia de ejecución de reglas y otros permiten que el usuario elija.
Existen distintos tipos de motores de reglas. Estos tipos (por lo general) difieren en cómo se programan las reglas para su ejecución.
La mayoría de los motores de reglas utilizados por las empresas son de encadenamiento hacia adelante , que se pueden dividir en dos clases:
La mayor diferencia entre estos tipos es que los motores de reglas de producción se ejecutan cuando un usuario o una aplicación los invoca, generalmente de manera sin estado. Un motor de reglas reactivo reacciona automáticamente cuando ocurren eventos, generalmente de manera con estado. Muchos motores de reglas comerciales populares (y de hecho la mayoría) tienen capacidades de reglas de producción y de reacción, aunque pueden enfatizar una clase sobre otra. Por ejemplo, la mayoría de los motores de reglas comerciales son principalmente motores de reglas de producción, mientras que los motores de reglas de procesamiento de eventos complejos enfatizan las reglas de reacción.
Además, algunos motores de reglas admiten el encadenamiento hacia atrás . En este caso, un motor de reglas busca resolver los hechos para que se ajusten a un objetivo en particular. A menudo se dice que está orientado a objetivos porque intenta determinar si algo existe en función de la información existente.
Otro tipo de motor de reglas cambia automáticamente entre encadenamiento hacia atrás y hacia adelante varias veces durante una ejecución de razonamiento, por ejemplo, el sistema de lógica empresarial de Internet, que se puede encontrar buscando en la web.
Una cuarta clase de motor de reglas podría denominarse motor determinista. Estos motores de reglas pueden prescindir tanto del encadenamiento hacia adelante como del encadenamiento hacia atrás y, en su lugar, utilizar enfoques de lenguaje específicos del dominio para describir mejor la política. Este enfoque suele ser más fácil de implementar y mantener, y ofrece ventajas de rendimiento sobre los sistemas de encadenamiento hacia adelante o hacia atrás.
Existen algunas circunstancias en las que la inferencia basada en lógica difusa puede ser más apropiada, cuando se utilizan heurísticas en el procesamiento de reglas, en lugar de reglas booleanas. Algunos ejemplos pueden incluir la clasificación de clientes, la inferencia de datos faltantes, los cálculos de valor del cliente, etc. El lenguaje DARL [4] y el motor de inferencia y los editores asociados son un ejemplo de este enfoque.
Un caso de uso común para los motores de reglas es el control de acceso estandarizado a las aplicaciones. OASIS define una arquitectura de motor de reglas y un estándar dedicado al control de acceso llamado XACML (lenguaje de marcado de control de acceso extensible). Una diferencia clave entre un motor de reglas XACML y un motor de reglas de negocios es el hecho de que un motor de reglas XACML no tiene estado y no puede cambiar el estado de ningún dato. El motor de reglas XACML, llamado Punto de decisión de política (PDP), espera una pregunta binaria de Sí/No, por ejemplo, "¿Puede Alice ver el documento D?" y devuelve una decisión, por ejemplo, Permitir/Denegar.
Los motores de reglas existen desde principios de los años 90, cuando empresas como Pegasystems Inc. en Cambridge, Massachusetts, Fair Isaac Corp. en Minneapolis e ILOG en Mountain View, California, los vendían. Se utilizaban normalmente en industrias con un uso intensivo de reglas, como las finanzas y los seguros. Sin embargo, en los últimos años, muchos proveedores han entrado en el mercado y cada vez más empresas están considerando los motores de reglas como una forma de obtener una mayor flexibilidad en las operaciones comerciales.