Reglas en tiempo de ejecución (runtime) en aplicaciones GeneXus.

En Concepto desarrollamos aplicaciones con GeneXus, para varios clientes. En las mismas aparecen muchas veces situaciones donde la aplicación debe tomar decisiones basadas en los datos de la misma.
Algunos ejemplos de estos problemas:

• Documentos que hay que exigir para una determinada operación.
• A que oficina debe pasar el tramite dependiendo su contenido (monto, producto, etc.).
• Controles a aplicar a una determinada operativa
• Descuentos a realizar a una venta (depende del cliente, de la cantidad vendida en el año, la cantidad del pedido actual, etc.)

Esto se puede resolver de varias formas.
Opción 1)
Una fácil, es hacer un programa de la forma (para el último ejemplo)

do case
case TipoCliente='IMPORTANTE'
   &Descuento=20
case FacturaImporte>1000 and TipoCliente='CHICO'
   &Descuento=10
case TipoCliente='CHICO'
   &Descuento=5
otherwise
   &Descuento=0
enddo

Que problemas tiene este enfoque? Cada vez que el departamento comercial de la empresa define una nueva política comercial hay que modificar el código, generando esto una aplicación que no es fácil de adaptar a las necesidades comerciales de la empresa.


Opción 2)
La segunda opción es tener la lógica de los descuentos en tablas

Orden	TipoCliente	Importe	Descuento
1	GRANDE		20
2	CHICO	1000	10
3	CHICO		5
4			0

Este enfoque, mejora la situación mientras los criterios que se manejen en la aplicación para la aplicación de descuentos no cambien. El mantenimiento es realizada por los clientes, posibilitando esto que adapten el sistema a su forma de trabajar.


En este ejemplo solo tenemos 2 atributos a tomar en cuenta, pero si hay muchos atributos los que influyen en el descuento  la complejidad de la evaluación también se complica.En mi experiencia, estos programas pueden tener problemas de performance complicados si hay muchos atributos a evaluar y también muchas reglas.


Un día, llega el gerente comercial, diciendo que lanzó un campaña en la prensa, donde  a todos los clientes que cumplen años en Octubre, reciben un descuento de un 25%. Al agregarse un nuevo criterio (FechaCumpleaños) a la forma de calcular el descuento, se necesitan cambiar la estructura de la tabla y además los programas que lo utilizan. Si bien se mejoró con la opción 1) todavía es mejorable. **


Opción 3)
Utilización de reglas para determinar el descuento. La idea es utilizar reglas, editadas por los usuarios de la aplicación para darle mas flexibilidad a la misma.


La idea es que ellos puedan ingresar reglas del tipo:

Descuento=0
REGLA1:
SI TipoClient='GRANDE'  ENTONCES
   Descuento=20
FINSI
REGLA2
SI TipoCliente='CHICO' Y IMPORTE>1000 ENTONCES
   Descuento=10
FINSI
REGLA3:
SI TipoCliente='CHICO' ENTONCES
   Descuento=5
FINSI

Durante un tiempo estuvimos analizando diferentes BRMS (business rule manager system) como Drools, Drools.NET, InRule, NxBRE, OpenRules, ILog. Todos tiene sus pros y contras. El mas profesional y barato de todos es Drools que tiene mucho respaldo y esta bien documentado. En el Encuentro GeneXus del año pasado Luciano dio una charla sobre el tema, de como usar reglas dinámicas en aplicaciones Genexus. El problema es que usaba Drools que está en Java y nosotros necesitábamos una solución para .NET pues es la plataforma que domina el cliente donde iba a ser instalado. No queríamos complicar el deployment. Alejandro Rinaldi hizo un muy buen trabajo evaluando diferentes manejadores de reglas, logrando prototipos interesantes con InRule, NxBre y varios otros. Había uno que era muy caro, otros exigían editar las reglas con Microsoft Visio.


Alejandro Rivoir tuvo una buena idea e hizo una implementación de prueba que funcionó bien. La idea era codificar las reglas en XSLT. Este es un lenguaje completo que se escribe en un archivo XML y permite aplicar transformaciones a archivos XML.


Para el ejemplo, la factura de entrada quedaría así:

<Parametros>
<Factura>100</Factura>
<Importe>1567</Importe>
<ClienteId>CONCEPTO</ClienteId>
<ClienteTipo>GRANDE</ClienteTipo>
<Fecha>2010-01-01</Fecha>
</Parametros>

Como quedarían estas reglas codificadas en XSLT?

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml"/>

<xsl:template match="/">

<Resultados>

<xsl:apply-templates/>

</Resultados>

</xsl:template>

<xsl:template match="PARAMETROS[TipoCliente = 'GRANDE'">

<Descuento>20</Descuento>

</xsl:template>

<xsl:template match="PARAMETROS[TipoCliente = 'CHICO']">

<xsl:if test="Importe > 1000">

<Descuento>10</Descuento>

</xsl:if>

</xsl:template>

<xsl:template match="PARAMETROS[TipoCliente='CHICO']">

<xsl:if test="Importe > 100">

<Descuento>5</Descuento>

</xsl:if>

</xsl:template>

<xsl:template match="PARAMETROS">

<Descuento>0</Descuento>

</xsl:template>

<xsl:template match="text()|@*"/>

</xsl:stylesheet>

En GeneXus se aplicaría la función XSLTApply() para aplicar al xml de entrada el xslt que lo transformaría en un xml de salida, que quedaría así:

<Resultados>
<Descuento>20</Descuento>
</Resultados>

Que ventajas tiene esta solución frente a las anteriores?

• Todas las plataformas que usamos (.net,java, ruby) tienen manejo de xml y xslt, por lo que la solución es multiplataforma. También es una tecnología  muy probada y standard, por lo que no deberíamos tener sorpresas grandes.
• Da muy poco trabajo para programar.
• Permite con un costo bastante bajo la ejecución de reglas en el momento en runtime.

Que nos falta para mejorar esta implementacion?


Es mas lenta. Estaría bueno que se pudieran compilar los archivos XSLT y hacerlos mas rápidos.


Hay que hacer un editor de reglas amigable para el usuario que genere el xslt. Hacer un editor genérico de reglas de usuario es un lindo proyecto. La generación del XSLT es la parte fácil.


Hay un problema en el generador .NET que hace que cuando se abre por segunda vez un xml con OpenFromString() mantiene el contenido viejo, duplicando todo. Esto deberia poder solucionarse, lo cual posibilitaría hacer mas rápida esta implementación.


Tenemos un problema con el XSLTApply() para XML con namespaces, que hay que resolver. No analice aun si el problema es que la funcion no toma en cuenta el namespace o si falta derfinir algo en el xslt. 


Conclusión


A mi me tiene muy entusiasmado la solución encontrada. Posibilita que a las transacciones tengan un conjunto de reglas dinámicas. Si mezclamos los Business Component de GeneXus (pasándolos a xml con la función ToXml() ) y un editor de reglas que tomo como entrada los atributos de la transacción que permita generar XSLT con reglas, se pueden hacer cosas realmente interesantes. Hay que seguir investigando.


Se les ocurre algo para mejorarlo o hacerlo mas facil?







** se pueden almacenar los datos como metadatos, facilitando el utilizar nuevos campos, lo cual perjudica la performance, pero da mas flexibilidad.


UPDATE: Links que pueden servir para los que están interesados en el tema
EditArea UserControl
UfProject