Reglas en tiempo de ejecución (runtime) en aplicaciones GeneXus (2da. Parte)
En el post anterior, escribí sobre la posibilidad de tener reglas que puedan ser ejecutadas en runtime y modificadas por los usuarios y las ventajas de las mismas.
En los comentarios Gustavo Proto pedía ejemplos para facilitar el entendimiento del problema, que es el primer paso para poder resolverlo.
Algunas características deseables de las reglas (para la primera version):
1) Asociado a una transacción.
Las reglas/formulas que puedo escribir, son las que puedo escribir con los atributos de una transacción. Si en runtime tengo que utilizar un atributo de la extendida en las reglas, que no esta en la transacción no se puede utilizar.
2) Las reglas no acceden a la base de datos.
En una primera etapa no es necesario que la regla acceda a la base de datos. Por ahora alcanzaría que accedan a un XML que pueda generarse desde los datos de la transacción. Si por ejemplo se necesita condiciones del tipo si Cliente in TablaClientesImportantes, se debera definir una formula del que se llame ClienteImportante (True o False) y esto habria que resolverlo en el codigo previo de la transacción.
3) Las reglas no modifican la base de datos.
Por cuestiones de seguridad, no se permiten que las reglas modifiquen la base de datos.
4) Funciones simples.
Solo tienen operaciones lógicas, aritméticas y manejo de cadenas de caracteres.
A mi se me habían ocurrido los siguientes casos para la aplicación de reglas:
a) El sistema aduanero, recibe mensajes en formato XML para declaraciones aduaneras (importacion, exportación, etc). Estos mensajes estan compuestos por bloques (Cabezal, Lineas, Facturas, Contenedores, Medio de transporte, Documentos, etc). Estos bloques, son obilgatorios para unas operativas, o para algunos productos y no para otros. Esto tambien incluye que campos son obligatorios o no dependiendo si es un mensaje de alta o un mensaje de modificación.
b) Calculo de Regimen Precedente. Hay declaraciones que solamente son permitidas si hay una operación anterior que las hagan viable. Por ejemplo, se puede hacer una Exportación , tiene que existir una Admision Temporaria previa. Esto cambia mucho de pais a pais y tambien con el tiempo.
c) Calculo de Comisiones por Ventas. Dada una Venta, calcular cual es la comision que se le va a pagar al vendedor. Entran las ventas pasadas, las condiciones de la venta actual.
d) Calculo de Descuentos a Clientes. Al realizar un pedido, calcularle que descuento va a tener esa venta, respetando los acuerdos comerciales que tenga ese cliente con la empresa.
e) Documentos obligatorios. Dada una operacion aduanera de importacion, dar una lista de todos la documentacion que se necesita exigir, en los diferentes momentos del tramite. Si voy a importar armas, necesito un certificado de las FFAA. Si voy a importar combustibles, tengo que presentar documentos de Ancap. Si son alimentos, son documentos bromatologicos. Algunos son al momento de hacer la declaracion, otros al retirar la mercaderia.
Se les ocurre alguno mas?
En los comentarios Gustavo Proto pedía ejemplos para facilitar el entendimiento del problema, que es el primer paso para poder resolverlo.
Algunas características deseables de las reglas (para la primera version):
1) Asociado a una transacción.
Las reglas/formulas que puedo escribir, son las que puedo escribir con los atributos de una transacción. Si en runtime tengo que utilizar un atributo de la extendida en las reglas, que no esta en la transacción no se puede utilizar.
2) Las reglas no acceden a la base de datos.
En una primera etapa no es necesario que la regla acceda a la base de datos. Por ahora alcanzaría que accedan a un XML que pueda generarse desde los datos de la transacción. Si por ejemplo se necesita condiciones del tipo si Cliente in TablaClientesImportantes, se debera definir una formula del que se llame ClienteImportante (True o False) y esto habria que resolverlo en el codigo previo de la transacción.
3) Las reglas no modifican la base de datos.
Por cuestiones de seguridad, no se permiten que las reglas modifiquen la base de datos.
4) Funciones simples.
Solo tienen operaciones lógicas, aritméticas y manejo de cadenas de caracteres.
A mi se me habían ocurrido los siguientes casos para la aplicación de reglas:
a) El sistema aduanero, recibe mensajes en formato XML para declaraciones aduaneras (importacion, exportación, etc). Estos mensajes estan compuestos por bloques (Cabezal, Lineas, Facturas, Contenedores, Medio de transporte, Documentos, etc). Estos bloques, son obilgatorios para unas operativas, o para algunos productos y no para otros. Esto tambien incluye que campos son obligatorios o no dependiendo si es un mensaje de alta o un mensaje de modificación.
b) Calculo de Regimen Precedente. Hay declaraciones que solamente son permitidas si hay una operación anterior que las hagan viable. Por ejemplo, se puede hacer una Exportación , tiene que existir una Admision Temporaria previa. Esto cambia mucho de pais a pais y tambien con el tiempo.
c) Calculo de Comisiones por Ventas. Dada una Venta, calcular cual es la comision que se le va a pagar al vendedor. Entran las ventas pasadas, las condiciones de la venta actual.
d) Calculo de Descuentos a Clientes. Al realizar un pedido, calcularle que descuento va a tener esa venta, respetando los acuerdos comerciales que tenga ese cliente con la empresa.
e) Documentos obligatorios. Dada una operacion aduanera de importacion, dar una lista de todos la documentacion que se necesita exigir, en los diferentes momentos del tramite. Si voy a importar armas, necesito un certificado de las FFAA. Si voy a importar combustibles, tengo que presentar documentos de Ancap. Si son alimentos, son documentos bromatologicos. Algunos son al momento de hacer la declaracion, otros al retirar la mercaderia.
Se les ocurre alguno mas?
Hola,
ResponderBorrarLeyendo tu post de las reglas, pregunto ? (sin conocer mucho de GX).
Si en GX se pudiera poner métodos asociados a cada transacción, donde los métodos pueden acceder a los atributos y llamar a otros métodos, se estaría haciendo algo parecido a las OODMS. Habría un "paralelismo" entre Transacción = Clase, Registro = Objeto, Método = Método. Los "Métodos" operarían sobre estructura de la transacción y modificando/creando más registros. Se que tu pregunta esta orientada a algo bien practico, y no se que tan viable es esto en GX, este es solamente un planteamiento teórico.
Si este fuera el caso las reglas serían métodos asociados a una transacción.
Saludos,
Bruno
pd: perdón por este "delirio" teórico.
Enrique, tu planteo parte del supuesto que el usuario quiere definir las reglas, será así? me parece que los usuarios con vagos, prefieren todo listo.
ResponderBorrarPor otro lado... cómo se controlaría que un error por una regla equivocada no sea atribuida al software y cómo se auditarian los cambios de
las reglas?
Creo que esta idea demandaría mucho soporte
Javier:
ResponderBorrarEl uso de reglas en runtime, no es para todas las aplicaciones, ni para todos los usuarios.
Si los usuarios de una aplicacion, no estan capacitados o no quieren cambiar las reglas, se puede seguir teniendo aplicaciones como hoy, o tambien pueden ser los desarrolladores los que realicen la creacion o adaptacion de las reglas en runtime.
Segun mi experiencia, lleva mucho menos tiempo cambiar reglas en runtime (si todo esta bien definido) que cambiar los programas/ generarlos/ testearlos / instalarlos.
Gracias por el comentario
Yo tengo otro ejemplo.
ResponderBorrarSería para un sistema de encuestas. En el sistema me defino una serie de preguntas que pueden ser x ej. opcion simple, múltiple y abierta. Las ordeno secuencialmente entonces se responden en ese orden. Ahora, si tengo este tipo de reglas, un usuario podría definir otra logica de ejecución, (o varias) y sería totalmente flexible. Podría programar los saltos de preguntas con condiciones lógicas sobre respuestas anteriores tan complejas como yo quiera. Espero haberme explicado bien, creo que esto enriquecería mucho a gx y por ende a nosotros...
Saludos y espero que siga esta iniciativa!!!
Bruno