Optimización para la ejecución del motor de reglas de Azure Logic Apps (versión preliminar)

Se aplica a: Azure Logic Apps (estándar)

Importante

Esta funcionalidad está en versión preliminar y está sujeta a las Condiciones de uso complementarias para las versiones preliminares de Microsoft Azure.

El motor de reglas de Azure Logic Apps proporciona el contexto de ejecución de un conjunto de reglas, que puede crear con Microsoft Rules Composer. En esta guía se explican los conceptos básicos sobre cómo funciona el motor de reglas y se proporcionan recomendaciones de optimización para las operaciones y la ejecución.

Componentes principales

• Ejecutor del conjunto de reglas

  Este componente implementa el algoritmo responsable de la evaluación de las condiciones de regla y la ejecución de las acciones. El ejecutor predeterminado de conjuntos de reglas es un motor de inferencia de encadenamiento inverso basado en una red de discriminación que está diseñado para optimizar las operaciones en memoria.

• Traductor del conjunto de reglas

  Este componente toma un objeto RuleSet como entrada y genera una representación ejecutable del conjunto de reglas. El traductor en memoria predeterminado crea una red de discriminación compilada a partir de la definición del conjunto de reglas.

• Interceptor de seguimiento del conjunto de reglas

  Este componente recibe la salida del ejecutor del conjunto de reglas y reenvía esa salida a las herramientas de seguimiento y supervisión del conjunto de reglas.

Evaluación de condiciones y ejecución de acciones

El motor de reglas de Azure Logic Apps es un motor de inferencia muy eficaz que puede vincular reglas a objetos .NET o documentos XML. El motor de reglas usa un algoritmo de tres fases para la ejecución del conjunto de reglas con las siguientes fases:

• Coincidencia

  En la fase de coincidencia, el motor de reglas hace coincidir los hechos con los predicados que usan el tipo de hecho, que son referencias de objeto mantenidas en la memoria de trabajo del motor de reglas, mediante los predicados definidos en las condiciones de regla. Para mejorar la eficacia, la coincidencia de patrones se produce en todas las reglas del conjunto de reglas y las condiciones que se comparten entre reglas solo se hacen coincidir una vez. El motor de reglas puede almacenar coincidencias de condición parciales en la memoria de trabajo para acelerar las operaciones posteriores de coincidencia de patrones. La salida de la fase de coincidencia de patrones contiene actualizaciones de la agenda del motor de reglas.

• Resolución de conflictos

  En la fase de resolución de conflictos, el motor de reglas analiza las reglas que son candidatas para la ejecución para determinar el conjunto siguiente de acciones de reglas que se va a ejecutar en función de un esquema de resolución predeterminado. El motor de reglas agrega todas las reglas candidatas encontradas durante la fase de coincidencia a la agenda del motor de reglas.

  El esquema de resolución de conflictos predeterminado está basado en las prioridades de reglas de un conjunto de reglas. La prioridad es una propiedad de regla que puede configurar en Microsoft Rules Composer. Cuanto mayor es el número, mayor es la prioridad. Si se desencadenan varias reglas, el motor de reglas ejecuta primero las acciones de mayor prioridad.

• Action

  En la fase de acción, el motor de reglas ejecuta las acciones en la regla resuelta. Las acciones de regla pueden afirmar hechos nuevos en el motor de reglas, lo que hace que el ciclo continúe y también se conoce como encadenamiento hacia adelante.

  Importante

  El algoritmo nunca adelanta la regla que se está ejecutando actualmente. El motor de reglas ejecuta todas las acciones de la regla que se está ejecutando actualmente antes de que se repita la fase de coincidencia. Sin embargo, otras reglas de la agenda del motor de reglas no se ejecutarán antes de que se vuelva a iniciar la fase de coincidencia. La fase de coincidencia puede hacer que el motor de reglas quite esas reglas de la agenda antes de que se ejecuten.

Ejemplo

En el siguiente ejemplo se muestra cómo funciona el algoritmo en tres fases de coincidencia, resolución de conflictos y acción:

Regla 1: Evaluación de los ingresos

• Representación declarativa

  Obtenga la calificación de solvencia crediticia de un solicitante únicamente si la proporción ingresos/préstamo del solicitante es inferior a 0,2.

• Representación IF—THEN mediante objetos de negocios

  IF Application.Income / Property.Price < 0.2
  THEN Assert new CreditRating( Application)
  

Regla 2: Evaluación de la calificación de solvencia crediticia

• Representación declarativa

  Apruebe un solicitante solo si la calificación de solvencia crediticia del solicitante es superior a 725.

• Representación IF—THEN mediante objetos de negocios:

  IF Application.SSN = CreditRating.SSN AND CreditRating.Value > 725
  THEN SendApprovalLetter(Application)
  

En la tabla siguiente se resumen los hechos:

Fact	Descripción	Fields
Aplicación	Documento XML que representa una solicitud de préstamo hipotecario.	- Ingresos: 65 000 USD - SSN: XXX-XX-XXXX
Propiedad	Documento XML que representa la propiedad que se va a comprar.	- Precio: 225 000 USD
CreditRating	Documento XML que contiene la calificación de solvencia crediticia del solicitante del préstamo.	- Valor: 0-800 - SSN: XXX-XX-XXXX

Actualizaciones de la memoria de trabajo y la agenda

En un principio, la agenda y la memoria de trabajo del motor de reglas están vacías. Una vez que la aplicación agrega los hechos de Application y Property, el motor de reglas actualiza su memoria de trabajo y su agenda, como se muestra:

Memoria de trabajo	Programa
- Application - Property	Regla 1

• El motor de reglas agrega la Regla 1 a su agenda porque la condición Application.Income / Property.Price < 0.2, se evalúa como true durante la fase de coincidencia.

• No existe ningún hecho CreditRating en la memoria de trabajo, por lo que no se evalúa la condición de la Regla 2.

• La Regla 1 es la única regla en la agenda, por lo que la regla se ejecuta y, a continuación, desaparece de la agenda.

• La Regla 1 define una única acción que da lugar a un nuevo hecho, que es el documento CreditRating del solicitante que se agrega a la memoria de trabajo.

• Una vez completada la ejecución de la Regla 1, el control vuelve a la fase de coincidencia.

  El único objeto nuevo que se va a comparar es el hecho CreditRating, por lo que los resultados de la fase de coincidencia son los siguientes:

  Memoria de trabajo	Programa
  - Application - Property - CreditRating	Regla 2

• Ahora se ejecuta la Regla 2, que llama a una función que envía una carta de aprobación al solicitante.

• Una vez completada la Regla 2, el control vuelve a la fase de coincidencia. Sin embargo, no hay más hechos nuevos disponibles para hacer coincidir y la agenda está vacía, por lo que el encadenamiento hacia adelante finaliza y se completa la ejecución del conjunto de reglas.

Agenda y prioridad

Para comprender cómo el motor de reglas de Azure Logic Apps evalúa las reglas y ejecuta acciones, también debe obtener información sobre los conceptos de agenda y prioridad.

Programa

La agenda del motor de reglas es una programación que pone en cola las reglas de ejecución. La agenda existe para una instancia de motor y actúa en un único conjunto de reglas, no en una serie de conjuntos de reglas. Cuando se afirma un hecho en la memoria de trabajo y se cumplen las condiciones de una regla, el motor coloca la regla en la agenda y ejecuta esa regla en función de la prioridad. El motor ejecuta las acciones de una regla de la prioridad superior a la inferior y, a continuación, ejecuta las acciones de la siguiente regla en la agenda.

El motor de reglas trata las acciones de una regla como un bloque, por lo que todas las acciones se ejecutan antes de que el motor pase a la siguiente regla. Todas las acciones de un bloque de reglas se ejecutan con independencia de las demás acciones del bloque. Para obtener más información sobre la aserción, consulte Optimización del motor de reglas con funciones de control.

En el ejemplo siguiente se muestra cómo funciona la agenda:

Regla 1

IF
Fact1 == 1
THEN
Action1
Action2

Regla 2

IF
Fact1 > 0
THEN
Action3
Action4

Cuando el hecho Fact1, que tiene un valor de 1, se afirma en el motor, se cumplen las condiciones tanto de la Regla 1 como de la Regla 2. Por lo tanto, el motor mueve ambas reglas a la agenda para ejecutar sus acciones.

Memoria de trabajo	Programa
Hecho 1 (valor=1)	Regla 1: - Action1 - Action2 Regla 2: - Action3 - Action4

Prioridad

De manera predeterminada, todas las reglas se establecen en 0 como prioridad para la ejecución. Sin embargo, puede cambiar esta prioridad en cada regla individual. El valor de la prioridad puede oscilar a ambos lados del 0, donde los números más grandes significan una mayor prioridad. El motor ejecuta acciones de la prioridad más alta a la prioridad más baja.

En el ejemplo siguiente se muestra cómo afecta la prioridad al orden de ejecución de las reglas:

Regla 1 (prioridad = 0)

IF
Fact1 == 1
THEN
Discount = 10%

Regla 2 (prioridad = 10)

IF
Fact1 > 0
THEN
Discount = 15%

Aunque se cumplen las condiciones de ambas reglas, la Regla 2 se ejecuta primero debido a su prioridad más alta. El descuento final es del 10 % debido al resultado de la acción ejecutada para la Regla 1, como se muestra en la tabla siguiente:

Memoria de trabajo	Programa
Fact1 (valor=1)	Regla 2: Descuento: 15 % Regla 1: Descuento: 10 %

Efectos secundarios de las acciones

Si la ejecución de una acción afecta al estado de un objeto o a un término usado en las condiciones, se dice que esta acción tiene un "efecto secundario" en ese objeto o término. Esta frase no significa que la acción tenga efectos secundarios, sino que el objeto o el término pueden verse afectados por una o varias acciones.

Por ejemplo, supongamos que tiene las siguientes reglas:

Regla 1

IF OrderForm.ItemCount > 100
THEN OrderForm.Status = "Important"

Regla 2

IF OrderList.IsFromMember = true
THEN OrderForm.UpdateStatus("Important")

En este ejemplo, OrderForm.UpdateStatus tiene un "efecto secundario" en OrderForm.Status, lo que significa que OrderForm.Status puede verse afectado por una o varias acciones.

La propiedad SideEffects para los miembros de la clase .NET se establece en true como valor predeterminado, lo que impide que el motor de reglas almacena en caché un miembro con efectos secundarios. En este ejemplo, el motor de reglas no almacena en caché OrderForm.Status en la memoria de trabajo. En su lugar, el motor obtiene el valor más reciente de OrderForm.Status cada vez que el motor evalúa la Regla 1. Si el valor de la propiedad SideEffects es false, el motor de reglas almacena en caché el valor cuando el motor evalúa OrderForm.Status por primera vez. Sin embargo, para las evaluaciones posteriores en escenarios de encadenamiento hacia adelante, el motor usa el valor almacenado en caché.

Microsoft Rules Composer no proporciona actualmente una manera de modificar el valor de la propiedad SideEffects. Sin embargo, puede establecer mediante programación el valor de la propiedad SideEffects a través del marco de Business Rules, que es una biblioteca de clases compatible con Microsoft .NET. Este valor se establece en el enlace mediante la clase ClassMemberBinding para especificar métodos de objeto, propiedades y campos usados en las condiciones y acciones de regla. La clase ClassMemberBinding tiene una propiedad denominada SideEffects, que contiene un valor booleano que indica si acceder al miembro cambia su valor.

Consideraciones de rendimiento

En esta sección se describe cómo funciona el motor de reglas de Azure Logic Apps en varios escenarios y con valores diferentes para los parámetros de configuración y optimización.

Tipos de hechos

El motor de reglas tarda menos tiempo en obtener acceso a los hechos .NET que a los hechos XML. Si tiene la opción entre usar hechos .NET o hechos XML en un conjunto de reglas, considere la posibilidad de usar hechos .NET para mejorar el rendimiento.

Prioridad de las reglas

El valor de prioridad de una regla puede oscilar a ambos lados del 0, donde los números más grandes significan una mayor prioridad. Las acciones se ejecutan en orden a partir de la prioridad más alta a la prioridad más baja. Cuando el conjunto de reglas implementa el comportamiento de encadenamiento hacia adelante mediante llamadas Assert o Update, puede optimizar el encadenamiento mediante la propiedad Priority.

Por ejemplo, suponga que la Regla 2 depende de un valor que ha establecido la Regla 1. Si la Regla 1 tiene mayor prioridad, la Regla 2 solo se ejecuta después de que la Regla 1 se active y actualice el valor. Por el contrario, si la Regla 2 tiene una prioridad más alta, la regla puede activarse una vez y, a continuación, volver a activarse después de que la Regla 1 se active y actualice el hecho en la condición de la Regla 2. Este escenario podría producir o no los resultados correctos, pero claramente la activación dos veces tiene un impacto en el rendimiento frente a la activación solo una vez.

Para obtener más información, consulte Crear reglas mediante Microsoft Rules Composer.

Operadores OR lógicos

El motor de reglas está optimizado para ejecutar operadores AND lógicos y reconstruye la regla que el motor analiza en una forma normal disyuntiva para que el operador OR lógico solo se use en el nivel superior.

Si usa más operadores OR lógicos en las condiciones, el aumento crea más permutaciones que expanden la red de análisis del motor de reglas. Como resultado, el motor de reglas puede tardar mucho tiempo en normalizar la regla.

En la lista siguiente se proporcionan posibles soluciones alternativas para este problema:

• Cambie la regla para que tenga una forma normal disyuntiva y que el operador OR solo se encuentre en el nivel superior.

  Considere la posibilidad de crear la regla mediante programación, ya que es posible que la creación de una regla en forma normal disyuntiva en Microsoft Rules Composer pueda resultar complicada.

• Desarrolle un componente de asistente que realice las operaciones OR y devuelva un valor booleano y, a continuación, use el componente en la regla.

• Divida la regla en varias reglas y haga que las reglas comprueben si hay una marca establecida por una regla ejecutada anteriormente, o si se usa un objeto que una regla ejecutada anteriormente haya asertado, por ejemplo:

  • Regla 1: IF (a == 1 OR a == 3) THEN b = true

    Regla 2: IF (b == true) THEN …

  • Regla 1: IF (a == 1 OR a == 3) THEN Assert(new c())

    Regla 2: IF (c.flag == true) THEN …

Llamadas a Update

La función Update actualiza un hecho que existe en la memoria de trabajo del motor de reglas, lo que provoca la reevaluación de todas las reglas que usan el hecho actualizado en las condiciones. Este comportamiento significa que las llamadas a funciones Update pueden ser costosas, especialmente si muchas reglas requieren una reevaluación debido a hechos actualizados. En algunas situaciones, puede evitar tener que reevaluar las reglas.

Por ejemplo, imagine las siguientes reglas:

Regla 1

IF PurchaseOrder.Amount > 5
THEN StatusObj.Flag = true; Update(StatusObj)

Regla 2

IF PurchaseOrder.Amount <= 5
THEN StatusObj.Flag = false; Update(StatusObj)

Todas las reglas restantes del conjunto de reglas usan StatusObj.Flag en sus condiciones. Cuando se llama a la función Update en el objeto StatusObj, se vuelven a evaluar todas las reglas. Independientemente de cuál sea el valor del campo Amount, todas las reglas excepto la Regla 1 y la Regla 2 se evalúan dos veces, una antes de la llamada a Update y otra después de la llamada a Update.

En su lugar, puede establecer el valor Flag en false antes de invocar el conjunto de reglas y, a continuación, usar solo la Regla 1 del conjunto de reglas para establecer la marca. En este caso, solo se llama a la función Update si el valor de Amount es mayor que 5. No se llama a la función Update si el valor es menor o igual que 5. De este modo, todas las reglas excepto la Regla 1 y la Regla 2 se evalúan dos veces únicamente si el valor de Amount es mayor que 5.

Comportamiento de la propiedad SideEffects

En las clases XmlDocumentFieldBinding y ClassMemberBinding, la propiedad SideEffects determina si se va a almacenar en caché el valor del campo, miembro o columna enlazada.

En la clase XmlDocumentFieldBinding, el valor predeterminado de la propiedad SideEffects es false. Sin embargo, en la clase ClassMemberBinding, el valor predeterminado de la propiedad SideEffects es true.

Por lo tanto, si el motor accede a un campo de un documento XML por segunda vez o más tarde dentro del conjunto de reglas, el motor obtiene el valor del campo de la memoria caché. Sin embargo, si el motor accede a un miembro de un objeto .NET por segunda vez o más tarde dentro del conjunto de reglas, el motor obtiene el valor del objeto .NET, no de la memoria caché.

Este comportamiento significa que si establece la propiedad SideEffects en una clase ClassMemberBinding de .NET en false, puede mejorar el rendimiento porque el motor obtiene el valor del miembro de la memoria caché a partir de la segunda vez y en adelante. Sin embargo, solo puede establecer mediante programación el valor de la propiedad porque Microsoft Rules Composer no expone la propiedad SideEffects.

Instancias y selectividad

Las clases XmlDocumentBinding y ClassBinding tienen las siguientes propiedades, y el motor de reglas usa sus valores para optimizar la evaluación de la condición. Estos valores de propiedad permiten al motor usar la menor cantidad de instancias posibles en primer lugar en las evaluaciones de condiciones y, a continuación, usar las instancias restantes.

• Instancias: el número esperado de instancias de clase en la memoria de trabajo.

  Si conoce el número de instancias de objeto de antemano, puede establecer la propiedad Instances en este número para mejorar el rendimiento.

• Selectividad: el porcentaje de instancias de clase que pasan correctamente las condiciones de la regla.

  Si conoce el porcentaje de instancias de objeto que pasan las condiciones de antemano, puede establecer la propiedad Selectivity en este porcentaje para mejorar el rendimiento.

Solo puede establecer estos valores de propiedad mediante programación porque Microsoft Rules Composer no los expone.

Compatibilidad con la herencia de clases

La herencia es la capacidad de usar toda la funcionalidad de una clase existente y ampliar esas funcionalidades sin volver a escribir la clase original, que es una característica clave en lenguajes de programación orientados a objetos (OOP).

El motor de reglas de Azure Logic Apps admite los siguientes tipos de herencia de clases:

• Herencia de implementación: la capacidad de usar las propiedades y los métodos de una clase base sin ninguna otra codificación.

• Herencia de interfaz: la capacidad de usar solo nombres de propiedad y nombres de método, pero la clase secundaria debe proporcionar la implementación.

Con el motor de reglas, puede escribir reglas en términos de una clase base común, pero los objetos declarados en el motor de reglas pueden provenir de clases derivadas.

En el ejemplo siguiente se tiene una clase base denominada Employee, mientras que las clases derivadas se denominan RegularEmployee y ContractEmployee:

class Employee
{
    public string Status()
    {
        // member definition
    }
    public string TimeInMonths()
    {
        // member definition
    }
}

class ContractEmployee : Employee
{
   // class definition
}
class RegularEmployee : Employee
{
   // class definition
}

En este ejemplo, supongamos que tiene las siguientes reglas:

Regla 1

IF Employee.TimeInMonths < 12
THEN Employee.Status = "New"

At run time, if you assert two objects, a **ContractEmployee** instance and a **RegularEmployee** instance, the engine evaluates both objects against the Rule 1.

You can also assert derived class objects in actions by using an **Assert** function. This function causes the engine to reevaluate rules that contain the derived object and the base type in their conditions as shown in the following example, which demonstrates implementation inheritance:

**Rule 2**

```text
IF Employee.Status = "Contract"
THEN Employee.Bonus = false
Assert(new ContractEmployee())

Después de la aserción, el motor vuelve a evaluar todas las reglas que contienen el tipo Employee o el tipo ContractEmployee en sus condiciones. Incluso si solo se afirma la clase derivada, la clase base se afirma también si las reglas se escriben con los métodos de la clase base, en lugar de la clase derivada.

Contenido relacionado

• ¿Qué es el motor de reglas de Azure Logic Apps?
• Crear reglas con Microsoft Rules Composer
• Creación de un proyecto del motor de reglas de Azure Logic Apps