Introducción

En los 2 POST anteriores he tratado el tema del motor de reglas de Windows Workflow Foundation. El primero es una introducción que permite entender el concepto de RuleSet y cómo usarlo en un Workflow. El segundo explica cómo funciona el tema de las dependencias de las reglas y la manera de administrar las re evaluaciones por cambios de las condiciones de validación.

Ahora voy a mostrar algo que es muy potente. Hasta ahora, las reglas de negocio se encuentran compiladas dentro del Assembly del Workflow. La consecuencia de esto es que es necesario para cambiar las reglas volver a compilar. Esto es un contra sentido, porque la idea de desacoplar las reglas de código de programación es poder tener una separación clara de el código del Wrokflow de las reglas.

En este Post voy a tratar de explicar cómo usar una pieza de software de terceros que permite poner el RuleSet de negocio en una base de datos y así cambiar las reglas sin volver a compilar.

Separar las Reglas de Negocio del Assembly

Lo primero que debo presisar es que voy a utilizar un software de terceros llamado “External RuleSet Toolkit”[1]. Este código es de ejemplo y demuestra como almacenar en SQL el RuleSet. Además trae una interfaz Windows Forms para modificar las reglas en la DB y así los Workflow no son alterados por cambios en las reglas de negocio.

Lo primero que hay que entender es la arquitectura de esta solución. El siguiente diagrama muestra un WorkflowRuntime que tiene 3 instancias de Workflow corriendo. Cada una de esas instancias tiene una Custom Activity llamada “Custom Policy Activity”, que se encarga de obtener el RuleSet desde la base de datos a través del servicio “RuleSet Services”. Este Servicio debe ser agregado al WorkflowRuntime para que esta actividad de Políticas cutomizada pueda comunicarse con el RuleSet Repository que esta en la base de datos.

Imagen 1.

Además de los componentes para el Workflow este ejemplo de código trae el RuleSet Designer que es una interfaz gráfica para administrar los elementos del RuleSet Repository. Esta interfaz se muestra en la imagen 2.

Imagen 2.

¿Cómo se Instala?

Para poder usar el componente se deben cumplir con el proceso de instalación. Estos no los voy a explicar porque están perfectamente detallados en el manual de instalación de este ejemplo de código.

Ejemplo de Uso 1

Para usar este componente vamos a importar el RuleSet que usamos en el primer ejemplo del primer post de esta serie. Como sabemos las reglas de guardan en un archivo de extensión .rule. Usando la aplicación RuleSet Designer vamos a importar el archivo wfReglasEjemplo_1.rule que está en este ejemplo de código [2]. Una vez importado grabamos el RuleSet para que así quede persistente en la base de datos.

Ahora, creamos un Workflow secuencial y le agregamos la actividad customizada PolicyFromService que es la que enlaza con las reglas de la base de datos a través del Servicio. El workflow se ve como la siguiente imagen.

Imagen 3.

Las propiedades de la actividad PolicyFromService  son:

1.- RuleSet Name: nombre del juego de reglas a usar.

2.- Major Version: numero de verison.

3.- Menor Version: número de sub versión.

EL RuleSet de nuestro ejemplo se llama Rule Set1. LA versión es la por defecto 1.0.

Ahora para que esto funcione debemos incluir el servicio de comunicaciones con el repositorio de la reglas en la base de datos. Para eso al runtime del Workflow agregamos el Servicio RuleSet Services. Para esto agregamos el siguiente código.

Código 1.

Con esto tenemos listo nuestro ejemplo. Si lo ejecutamos obtenemos el resultado A=15, B=5, C=5, D=2 y E=7.  Las reglas para hacer los cambios de los valores los leyó desde la base de datos!!!!!.

Ejemplo de Uso 2

Ahora, vamos a cambiar los valores para comprobar que descaplamos las reglas del Assembly. Para ello usamos la herramienta RuleSet Designer. Lo que haremos es mantener dos versiones de las reglas, así dependiendo de un valor usaremos una u otra regla.

Primero creamos una copia de las reglas, para eso usamos la función copy. Al hacer eso, nos aparece una nueva versión que por defecto es la versión 2.0. Usando la opción de Edit Rule, nos aparece el mismo formulario usamos antes para cambiar las reglas de Rule Set.

Si cambiamos las reglas y las grabamos en la base de datos el workflow inmediatamente comenzará a evaluar con el nuevo set de Reglas. Los valores de las reglas del segundo ejemplo son:

Código 3: Reglas Ejemplo II                      

Las Reglas versión 2.0 se muestran en la siguiente imagen.

Imagen: Reglas Versión 2.0

Los resultados obtenidos al usar las reglas 2.0 son A=15, B=5, C=5, D=2 y E=7000, y para esto no tuvimos que compilar.

Buenos eso es, espero lo encuentren de tanta utilidad como yo!.

El ejemplo de este POST pueden descargarlo desde aquí.

Salu2

Referencias

[1] External RuleSet Toolkit, http://wf.netfx3.com/files/folders/rules_samples/entry309.aspx

[2] Ejemplo de código de Reglas, http://desarrollo.datco.cl/materialpublico/Test2_Reglas.zip

Introducción

Siguiendo con esta secuencia de POST orientados a tratar de explicar cómo funciona el motor de Reglas de Windows Workflow Foundation. En el primer POST tenemos se explica cómo funcionan la evaluación de reglas de un RulesSet y cómo se re evalúan por defecto.

En este pequeño POST trataré de explicar cómo se puede controlar la ejecución de reglas atómicas del RuleSet sin dependencia entre ellas. La idea es que en algunos escenarios complejos, quien escribe las reglas necesita tener mayor control sobre el comportamiento de las re evaluaciones, específicamente limitar la cantidad de reevaluaciones. Con esto se busca evitar loops infinitos, resultados erróneos por iteraciones de las reglas y algo no menor, mejorar el desempeño.

Control de dependencias de Reglas (Forward Chaining Control)

En nivel de control que permite Windows Workflow Foundation se puede configurar en dos puntos:

• Conjunto de Reglas (RuleSet): con la propiedad Chaining Behavior.
• En cada Regla (Rule): con la propiedad Reevaluation Behaivor.

Chaining Behavior

Esta propiedad actua a nivel de RuleSet, y tiene las siguientes tres posibilidades:

1. Full Chaining: este es el comportamiento por defecto que está descrito en el primero post de esta serie. Pueden verlo aquí.

2. Explicit Update Only: está opción deshabilita las dependencias implícitas y por atributos, dejando la posibilidad solo a las explicitas declaradas usando Update.

Un ejemplo sería con el RuleSet del código 1 y los métodos del código 2 utilizando Chaining Behavior con el valor por defecto Full Chaining el valor de salida de las variables A, B, C, D y E son 15, 5, 5, 2 y 7 respectivamente.

Ahora si se cambia la propiedad Chaining Behavior a Explicit Update Only, el resultado cambia a 15, 0, 5, 2, 0. Esto ocurre porque en este modo de se ignoran las dependencias declaradas como atributos.

Código 1

Código 2

Para poder obtener el mismo comportamiento que en la primera prueba tenemos que cambiar el RueSet a lo mostrado en el código 3.

Código 3

Al poner la dependencia de forma explícita entonces el motor de reglas cuando evalúa la regla 2, re evalúa a regla 4. El resultado obtenido es 15, 5, 5, 2 y 7 respectivamente.

3. Sequiencial: esta es la opción final y lo que hace es forzar a que el motor realice las evaluaciones en un orden línea estricto, es decir no re evalúa las dependencias.

Si al ejemplo anterior, le cambiamos el valor a Secuencial, entonces obtenemos el resultado 15, 0 ,5, 2 y 0 porque no hay re evaluación de la Regla 4

Reevaluation Behavior Property

Está propiedad se aplica a  nivel de Reglas y permite la re evaluación o no de la regla. Los valore posibles son:

• ·         Always: es el  comportamiento descrito hasta ahora y el que viene por defecto.
• ·         Never: al marcar una regla con Never está ejecutará las acciones THEN o ELSE sólo una vez según corresponda.

En el ejemplo anterior, si la Regla 4 es marcada con Never entonces los valores de salida con 15, 0, 5, 2 y 0 porque la Regla 4 no se re evaluó.

Función Halt

Está función es muy interesante porque permite controlar la ejecución de dependencias entre reglas relacionadas. Al incluir Halt en la acción THEN o ELSE, entonces el RuleSet retorna de manera inmediata el control al código que lo invocó.

Con lo expuesto en este POST más el primer POST de RULE ENGINE ya se puede echar a volar la imaginación y buscar las aplicaciones prácticas de está tecnología. Yo ya la uso en proyectos Reales.

Espero seguir con otro Post (esto solo es una expresión de deseo) que muestra otros aspectos de Rules Engine de Windows Workflow Foundation.

EL código fuente del ejemplo mostrado se puede descargar desde aquí.

Salu2

Introducción

La tecnología DotNet Framework 3.0 tiene un componente para implementar Workflow’s[0] llamado Windows Workflow Foundation [1]. Este no es un producto de Workflow sino un motor de workflow más herramientas para los desarrolladores para que construyan sus propias soluciones de Workflow.

Dentro de las cosas más interesantes que veo en WF se encuentra su motor de Reglas de negocio (Rule Engine)[2].

Rules Engine permite hacer desde evaluación de condiciones lógicas hasta la definición y evaluación de complejas reglas que conforman políticas. En este post voy a tratar de explicar cómo se implementan esas políticas y cómo podemos usarlas en nuestros Worklows.

Lo primero que hay que entender es que las políticas son definidas por un conjunto de reglas semánticas llamado RuleSet. Estas reglas son del estilo If/Then/Else. Para poder invocar desde un Workflow la evaluación de un RuleSet se usa la actividad Policy[3].

Procedimiento de evaluación de las Reglas

Las Reglas que componen un RuleSet tienen una propiedad llamada Priority, que permite asignarle una prioridad a cada regla. El procedimiento de Evaluación del RuleSet es el siguiente:

1. La regla de mayor prioridad se evalúa y ejecuta la acción del Then o Else.
2. Si la acción (Then o Else) cambia el valor de un campo o propiedad que es usado por una regla anterior en la lista de reglas, esa regla afectada por el cambio se re evalúa.
3. La siguiente regla de la lista se evalúa y ejecuta la acción del Then o Else.

Veamos el siguiente ejemplo. Tenemos un Workflow sencillo de 3 Actividades, el que se muestra en la imagen 1. La primera actividad muestra los valores de las variables A, B, C, D, E en la consola. La segunda actividad es una Política que tiene 4 reglas que están priorizadas y la última muestra los valores después de aplicar el RuleSet de reglas.

Imagen 1: Workflow de Ejemplo y RuleSet.

El RuleSet se ve en la imagen 1. Las reglas se ejecutan desde la mayor prioridad (4) hasta la menor (1). El proceso en que se ejecutan las reglas es el siguiente:

1. Regla_4: Falso
2. Regla_3: Verdadero entonces B = 10.
3. Regla_2: Verdadero entonces A=15.
   1. Como cambio A la Regla_4 se re evalua. Regla_4: Verdadero entonces B=5.
4. Regla_1: Verdadero entonces E=7.

Quedando cuando se ejecutan los valores mostrados en la imagen 2 en color Rojo.

Imagen 2: resultados.

Las dependencias entre las reglas son identificadas de tres maneras por el Rules Engine:

1. Dependencia implícita.

   Este tipo de dependencia es la que vimos en el ejemplo 1, donde las acciones cambian valores que se usan en otras reglas.  

2. Dependencia por atributos.

   La dependencia por atributos es usado en reglas que llaman a métodos en el Workflow. Como llama a un método no tiene como deducir implícitamente que reglas debe ReEvaluar. Para usar este tipo de dependencia se debe usar uno de estos tres atributos en el método:

• RuleRead: Este quiere decir que el método lee un valor usado en el RuleSet
• RuleWrite: Este atributo indica que en ese método el valor indicado es modificado.
• RuleInvoke: Este atributo le indica al motor que el método llama a otro método.

Veamos un ejemplo para que sea más simple de entender. Tenemos un Workflow igual al anterior pero con el RuleSet mostrado en la imagen 3. Las reglas son las mismas que antes, pero en vez de cambiar los valores de las propiedades A,B, C, D y E directamente en la acción de la regla se invoca a un método.

El código de cada uno de los métodos invocados desde el RuleSet se muestra en el código 1.

Pueden ver en la imagen 4 que el resultado de la evaluación es el mismo que en ejemplo de reglas implícitas porque se hacen los mismos cambios de valores pero en métodos decorados con los atributos que le dan al motor de regla la información necesaria para actuar.

Imagen 3

Código 1.

1. Dependencia Explicita

   La dependencia explicita se basa e declarar uno mismo los cambios que ocurren al ejecutar una acción. Para ello se usa la instrucción Update de esta forma Update("this/A") por ejemplo para indicarle al motor que el valor de la propiedad A cambio.

   La única ventaja que he encontrado en la dependencia explicita es que se puede hacer por ejemplo esto Update("this/OrdenCompra/*") que le indica al motor que todos los atributos de la orden de compra cambian con esa acción. Esto es notable!!.

   El próximo ejemplo se muestra en la imagen 4. Las reglas contienen ahora en la acción la directiva Update. El código de los métodos ya no tiene la directiva RuleWrite, por lo que el motor se entera del cambio de manera explícita. El código de los métodos de cambio, sin el atributo, se muestra en el código 2.

   Por último el resultado sigue siendo el mismo!!! Y se muestra en la imagen 4.

   

   Imagen 4.

Código 2.

Imagen 4

El motor de reglas es mucho más potente de lo que se muestra en este POST, espero seguir explicando cómo funciona en una serie de post que quiero hacer sobre Windows Forkflow Foundation Rules Engine.

El código fuente de los ejemplos pueden descargarlos dese este Link

Salu2

Referencias

[0] Sistemas de Workflow, http://es.wikipedia.org/wiki/Sistemas_de_workflow

[1] Windows Workflow Foundation, http://msdn2.microsoft.com/en-us/netframework/aa663328.aspx

[2] Introduction to the Windows Workflow Foundation Rules Engine, http://msdn2.microsoft.com/en-us/library/aa480193.aspx

[3] Introducing Microsoft Windows Workflow Foundation: An Early Look , http://msdn2.microsoft.com/en-us/library/aa480215.aspx