.jpg)
En los artículos anteriores, hemos descrito el modelo de comisiones, dado una visión general de su estructura y ejemplos de varias reglas de comisiones para cada una de las clases propuestas (comisiones de Ventas, Méritos e Ingresos). En el último artículo de la serie, nos centraremos en mostrar la implementación práctica de las reglas utilizando el entorno DecisionRules, su orquestación y la configuración de una llamada API externa utilizada para integrar el modelo en sus propias aplicaciones.
En primer lugar, presentaremos varios ejemplos de cómo se implementan las reglas con nuestra herramienta. Disponemos de 3 opciones para elegir a la hora de crear una nueva regla, Decision Table, Decision Tree y una regla de Scripting. La mayoría de las reglas de nuestro modelo se diseñan en forma de árboles de decisión que adoptan la forma de una estructura lógica SI(condición) ENTONCES (resultado si se cumple la condición) u OTRO (resultado si no se cumple la condición).
Anteriormente, hemos descrito el aspecto y el funcionamiento de una regla de comisión típica (como ejemplo hemos utilizado las reglas de Venta de Préstamo y Nuevo Cliente). Ahora vamos a profundizar un poco más en algunas partes de la implementación, para mostrar cómo se pueden configurar las condiciones para hacer salidas personalizadas.
La mayoría de las reglas que hemos creado para este ejemplo tienen forma de árbol de decisión que evalúa las condiciones de entrada y establece la salida en consecuencia.
Estas reglas utilizan un conjunto sencillo de operadores y funciones predefinidos. Utilizar un simple conjunto de operadores significa que podemos crear reglas fáciles de entender, mantener y cambiar si es necesario.
Todos los operadores y funciones disponibles se describen en la documentación con explicaciones y ejemplos de uso.
Tanto los operadores como las funciones pueden combinarse en una regla en función de sus necesidades. Un ejemplo puede verse en la regla de comisión de Préstamo de Rendimiento.
Aquí utilizamos operadores básicos para comprobar los valores de las variables productType y daysDelinquentCount, y una función para comprobar si openDate es al menos un año anterior. Puedes ver que también hacemos uso del bloque O (OR), para permitir dos posibles valores para el estado de la variable de entrada. Para la implementación de esta condición en particular también se podría utilizar el operador básico DENTRO (IN) que daría como resultado la misma salida.
El estilo de implementación depende de sus preferencias y, sobre todo, del enfoque que le parezca más legible y manejable.
La mayoría de las reglas que creamos en DecisionRules pueden expresarse utilizando los operadores proporcionados en tablas o árboles de decisión. Sin embargo, es posible que te encuentres en una situación en la que estas funciones proporcionadas no sean suficientes o den lugar a una regla difícil de leer.
Para estos casos particulares hay un tipo de regla más disponible llamada Regla de Scripting. Éstas te permiten utilizar código Javascript para implementar reglas complejas con cálculos avanzados. Puedes ver un ejemplo de este tipo de script en la implementación de la comisión de ingresos por Préstamos Vendidos. Esta comisión comprueba todos los préstamos que el corredor ha firmado y si el total supera un umbral, entonces se otorga una comisión.
En el script se pueden utilizar las variables de entrada y salida accediendo a los objetos input y output y luego hacer los cálculos que se necesiten. La regla siempre termina con un comando return output, que envía la salida «have set up to the caller.
Si tienes alguna duda sobre este script puedes consultar nuestra documentación.
En el artículo anterior, hemos descrito la estructura de nuestro modelo de comisiones dividiéndolo en 3 capas. Las capas 2 y 3 son donde harías la mayoría de tus modificaciones para crear un modelo de comisiones para tu propio caso de uso (estas capas contienen las listas de reglas en cada clase y las propias reglas de comisiones). La capa 1 contiene la regla orquestadora de todo el modelo, y no necesitará ninguna modificación a menos que desees cambiar en gran medida la funcionalidad del modelo.
La regla principal de orquestación Calcular Comisiones maneja la integración en ambas direcciones ENTRADA y SALIDA y se implementa como una regla de Scripting. En nuestro caso, la regla se utiliza para manejar la entrada, evaluar todas las reglas de comisiones requeridas y luego compilar la salida en la forma deseada. A menos que quieras añadir una clase completamente nueva de comisiones al modelo, no necesitas cambiar este script en absoluto.
El script tiene una parte separada para cada una de las clases de comisiones y en cada caso primero llama a la tabla de Lista de Comisiones correspondiente para obtener todas las comisiones activas que van a ser evaluadas. A continuación, recorre todas las operaciones de la entrada y comprueba el resultado de cada regla de comisión en la clase seleccionada. Cuando todas las reglas han sido evaluadas para todas las operaciones, entonces todos los resultados son enviados a la salida en un array con información adicional sobre la fecha de la evaluación y el corredor.
El código completo está disponible en el modelo en la regla de scripting Calcular Comisiones.
La mayoría de los cálculos de esta regla de orquestación se realizan con JavaScript normal; las únicas excepciones son las evaluaciones de otras reglas de tu espacio. Para ello, puedes utilizar un paquete DR que proporciona una función «solve» para evaluar reglas. El código puede tener esta forma:
Primero tenemos que especificar el alias de la regla que queremos evaluar (alternativamente siempre se puede utilizar el ruleID, pero el uso del alias hace que el código sea mucho más legible; ambos están disponibles en los «Ajustes» de cualquier regla) y luego pasar algunos datos a su entrada. Luego tenemos la opción de utilizar varios parámetros opcionales, que nos permiten, por ejemplo, especificar qué versión de la regla queremos utilizar, qué estrategia queremos usar para evaluarla o qué partes de la salida queremos extraer. Para más información sobre estos parámetros, consulta nuestra documentación.
En el ejemplo anterior, puedes ver cómo utilizamos esta función “Solve" para obtener una lista de IDs de reglas de comisiones. Evaluamos una tabla de lista de Comisiones de Ventas que contiene una lista de todas las comisiones activas, por lo tanto no necesitamos utilizar ningún dato de entrada. El parámetro «latest» es uno de los opcionales, y si siempre usas la última versión de la regla, entonces se puede omitir.
Veamos ahora algunas cosas que facilitarán el uso del modelo y te permitirán modificarlo para adaptarlo a tus necesidades:
Cuando pruebes o afines las reglas, puedes utilizar la función Banco de Pruebas para visualizar cómo procede la evaluación de la regla y para probarla y depurarla. En la parte izquierda del Banco de Pruebas puedes definir valores para tus variables de entrada y después de pulsar el botón Ejecutar, deberías ver la salida calculada en la parte derecha. Cuando se conceda la comisión, los resultados de la prueba tendrán este aspecto (con la opción Debug activada, los bloques activos se resaltarán en verde)
Otro ejemplo muestra lo que ocurre cuando no se concede la comisión ( puedes ver la condición fallida resaltada en rojo y el mensaje de salida contiene una lista de los valores de la entrada para que quede claro qué condiciones fallaron).
Toda la gestión de las comisiones se realiza a través de la interfaz de usuario. Cuando se configura una nueva regla, hay plantillas preparadas en la carpeta de plantillas del proyecto que ya tienen la salida común; los siguientes pasos que se dan para configurar la regla son
Tal y como describimos en el artículo anterior, la integración de DecisionRules en tu propia aplicación puede realizarse utilizando REST API. Utilizaremos la aplicación Postman para mostrar cómo se crearía y estructuraría una llamada a la API.
Para configurar correctamente la llamada a la API vamos a necesitar varias cosas:
En nuestro caso, queremos llamar a la regla principal Calcular Comisiones, para la que hemos establecido un alias para facilitar su uso
Ahora que tenemos todo lo que necesitamos podemos empezar a crear la llamada en Postman.
Para evaluar cualquier regla creada en DecisionRules utilizamos la API Rule Solver (como se explica en la documentación). Describiremos dos formas de configurar la llamada. La primera es dejar que DecisionRules cree la llamada por ti, la segunda es configurar la llamada manualmente.
Si abres cualquier regla en DecisionRules, verás en el menú inferior una opción llamada vista previa de la solicitud
Esto abre la siguiente ventana, que contiene una llamada a la API preparada, con varios lenguajes de programación para elegir.
En nuestro caso, puedes copiar el código cURL y pegarlo directamente en una nueva llamada en postman. Todo lo que necesitas cambiar para tener una llamada funcional es proporcionar tus datos de entrada en el cuerpo.
Ahora echemos un vistazo a lo que tendrías que hacer para configurar la llamada manualmente desde cero. Este tutorial detallará cómo configurar todo lo que se proporciona en la llamada creada a través de la vista previa de solicitud, permitiendo una mayor variedad de opciones (por ejemplo, utilizando el alias de regla más legible en lugar de ruleId).
El punto final al que tenemos que llamar para "solve" una regla es https://api.decisionrules.io/rule/solve/:ruleId/:version
La primera página de la llamada a la API debe tener este aspecto:
Hemos copiado el endpoint en la línea de dirección y rellenado la clave ruleId con el alias de nuestra regla. Observa que hemos eliminado el parámetro :version, ya que es opcional y si sólo queremos evaluar la última versión de la regla, no es necesario.
Ahora tenemos que configurar las cabeceras, que es donde ponemos nuestra clave API solver, que luego actúa como nuestro «nombre de usuario y contraseña». Todo lo que necesitas hacer es ir a la pestaña Headers y añadir una clave de tipo Autenticación con el valor « Bearer <tu clave API aquí>». Podría ser algo como esto:
Por último, pero no menos importante, tenemos que dar algunos datos de entrada a nuestra llamada para que tengamos algo que evaluar. Esto se hace en la pestaña Body, donde marcas la opción «raw», y en el desplegable seleccionas «JSON» y luego puedes copiar tus datos de entrada en el espacio proporcionado.
Ten en cuenta que los datos de entrada deben estar dentro de una propiedad predefinida llamada «data».
Una vez hecho esto, la página debería tener este aspecto:
¡Ahora ya puede evaluar tus reglas mediante llamadas a la API!
Postman mostrará la salida de tu llamada en una ventana debajo del cuerpo de tu llamada.
Cualquier llamada a la API DecisionRules devolverá su respuesta en forma de array. Incluso si sólo envías un objeto para su evaluación, la respuesta será en forma de matriz con una entrada, como puedes ver a continuación:
Si quieres experimentar o leer más sobre las opciones que te ofrece la API, consulta la documentación.
Veamos cómo procesar los registros de auditoría de DecisionRules en Power BI para preparar los datos para los tableros de comisiones
Nota: Por favor, asegúrate de que tienes los registros de auditoría activados y encendidos para tu regla de Cálculo de Comisiones. La configuración se describe aquí: https://docs.decisionrules.io/doc/business-intelligence/audit-logs
Se puede acceder a los registros de auditoría utilizando la API de Business Intelligence, esta API utiliza una clave de API diferente a la que utilizamos para evaluar las reglas en Postman; puedes encontrar esta clave en el mismo menú de Claves de API bajo Business Intelligence Clave de API (si no ves ninguna clave, puedes añadir alguna utilizando el botón Añadir clave de API de Business Intelligence).
Aparte de esto, necesitarás el ID de regla de tu regla de Cálculo de Comisiones (¡si no se utiliza el ID de regla, el alias no funcionará!).
Al cargar los datos a través de la API de Business Intelligence, accederemos a los registros de auditoría en varios pasos cargando una página con un número limitado de registros cada vez. Necesitamos adoptar este enfoque para no saturar el servidor si necesitamos cargar un gran número de registros de una sola vez.
Ahora podemos abrir PowerBI y crear una consulta para importar los datos. Después de abrir un nuevo proyecto, debes navegar en el menú desplegable Get Data y seleccionar «Blank query» (esto abrirá el editor PowerQuery).
Deberás crear dos parámetros utilizando la opción Manage Parameters de Home, denominar estos parámetros BI_API_KEY y RULE_ID y establecer sus valores actuales a los valores de la clave API y el ID de Regla que recibiste de DecisionRules.
Nuestra query PowerBI puede dividirse en las siguientes 5 partes:
En primer lugar, consultamos la API de DecisionRules Business intelligence y extraemos un parámetro matchedCount de la llamada (la propia llamada utiliza una configuración limit=1 porque aún no necesitamos ningún dato). Este parámetro nos indica cuántos registros tenemos para cargar; lo almacenamos en la variable iteraciones.
Aquí preparamos una función que lee una página de registros.
Ahora tenemos un loop llamando a la función para todas las páginas de registros (que contienen el número de registros a cargar) y para cada iteración, llamamos a la función FnGetOnePage de la parte anterior, y conectamos todos los registros juntos en una única tabla.
En estas partes finales, transformamos los datos desde el formato del registro de auditoría, que puede contener muchos datos que no te resulten útiles en este momento, a una tabla con sólo los datos de salida que nos interesan. La parte 4 se encarga de obtener los datos de salida de la regla desde el registro y debería permanecer igual incluso si decides cambiar la estructura de salida. Sin embargo, si decides hacerlo, necesitarás cambiar el código de la última parte, ya que estamos tratando con nombres de columnas que obtenemos de la salida de DecisionRules y si añades o eliminas algo, estos nombres necesitarán ser cambiados/modificados.
Puedes ver el código completo a continuación; por favor, cópialo y pégalo en tu query de PowerBI.
Ahora puedes Invocar la función, y deberías tener todos los datos de salida de tus Registros de Auditoría disponibles en PowerBI y puedes empezar a configurar tus informes.
Por supuesto, puedes crear los informes de acuerdo a tus propias necesidades y especificaciones, pero para los propósitos de este ejemplo hemos configurado un simple panel de control como se puede ver aquí:
En este artículo, hemos demostrado cómo configurar un modelo de comisión en la herramienta PowerBI. Las reglas están diseñadas para ser simples, para ilustrar la lógica y proporcionar una dirección a seguir. La lógica de las comisiones puede ser intrincada, y éste es sólo el primer paso.
Si deseas saber más sobre las posibilidades de DecisionRules, la documentación está aquí para ti. Aventúrate con confianza y explora más a fondo.
%20(1).svg){kind=logo}
