Afirmar

La aserción es el proceso de agregar instancias de objeto a la memoria de trabajo del motor de reglas de negocios. El motor procesa cada instancia según las condiciones y acciones escritas en el tipo de la instancia, utilizando las fases de coincidencia, resolución de conflictos y acción.

En los temas siguientes se describen los comportamientos resultantes del uso de la función Assert para distintos tipos de hechos.

Objetos de .NET

Cada objeto se afirma en la memoria de trabajo como una instancia independiente. Esto significa que cada predicado analiza la instancia que hace referencia al tipo del objeto (por ejemplo, IF Object.Property = 1). También se pone a disposición de las acciones de regla que hacen referencia al tipo, en función de los resultados de las condiciones de la regla.

Considere el ejemplo siguiente.

Regla 1

IF A.Value = 1  
THEN A.Status = "good"  

Regla 2

IF B.Value = 1  
THEN A.Status = "good"  

En la regla 1, solo las instancias de A que tengan un valor de 1 tendrán actualizada su propiedad Status . Sin embargo, en la regla 2, si la condición se evalúa como true, todas las instancias de A tendrán su estado actualizado. De hecho, si hay varias instancias de B, las instancias A se actualizarán cada vez que la condición se evalúe como true para una instancia B.

Para declarar un objeto .NET desde dentro de una regla, puede agregar la función Assert integrada como una acción de regla. Tenga en cuenta que el motor de reglas tiene una función CreateObject , pero no se muestra como una función independiente en Business Rule Composer. Su invocación se crea arrastrando el método constructor del objeto que desea crear desde la vista Clase de .NET del Explorador de hechos al panel de acciones. A continuación, El compositor de reglas de negocios traduce el método constructor en una llamada CreateObject en la definición de regla.

TypedXmlDocument

Cuando se afirma un TypedXmlDocument, el motor de reglas de negocios crea instancias secundarias de TypedXmlDocument basadas en los selectores definidos en la regla.

Los selectores y campos son expresiones XPath. Puede considerar selectores como una manera de aislar nodos de un documento XML y campos como identificar elementos específicos dentro del selector. Todos los campos dentro de un selector se agrupan como un objeto por el motor. Al seleccionar un nodo en la pestaña Esquemas XML del Explorador de hechos, Business Rule Composer rellena automáticamente la propiedad Selector XPath para todos los nodos y la propiedad Campo XPath para cualquier nodo que no contenga nodos secundarios. También puede especificar expresiones XPath propias en Selector XPath y Campo XPath, si fuera necesario.

Si el selector coincide con varias partes del documento XML, se declaran varios objetos de este tipo en la memoria de trabajo del motor de reglas o se retiran de él. Supongamos que tiene el siguiente XML.

<root>  
   <order customer="Joe">  
      <item name="router" quantity="10" cost="550" />  
      <item name="switch" quantity="3" cost="300" />  
   </order>  
   <order customer="Jane">  
      <item name="switch" quantity="1" cost="300" />  
      <item name="cable" quantity="23" cost="9.99" />  
   </order>  
</root>  

Si usa el selector /root/order (o //order), se agregan dos objetos a la memoria de trabajo.

1)

<order customer="Joe">  
   <item name="router" quantity="10" cost="550" />  
   <item name="switch" quantity="3" cost="300" />  
</order>  

2)

<order customer="Jane">  
   <item name="switch" quantity="1" cost="300" />  
   <item name="cable" quantity="23" cost="9.99" />  
</order>  

Dentro de cada selector, XPaths hace referencia a los campos individuales.

Si usa el selector /root/order/item (o //order/item o //item), se agregan cuatro objetos a la memoria de trabajo del motor de reglas, los dos elementos para Joe y los dos elementos de Jane.

<root>  
   <order customer="Joe">  
  
   </order>  
   <order customer="Jane">  
  
   </order>  
</root>  

Cada objeto tiene acceso a tres campos: @name, @quantityy @cost. Dado que el objeto es una referencia al documento original, puede hacer referencia a campos primarios (por ejemplo, ".. /@customer").

Puede usar varios selectores en el mismo documento. Esto le permite ver diferentes partes del documento (por ejemplo, si una sección es el pedido y otra sección contiene la dirección de envío). Sin embargo, tenga en cuenta que los objetos creados se definen mediante la cadena XPath que las creó. El uso de una expresión XPath diferente, incluso si se resuelve en el mismo nodo, da como resultado un typedXmlDocument único.

El motor de reglas admite tipos escalares de .NET básicos de forma nativa, así como objetos para tipos de referencia. Los documentos XML son básicamente texto, pero en función del tipo que se especificó cuando se creó la regla, el valor de campo puede ser de cualquier tipo. Además, dado que los campos son expresiones XPath, pueden devolver un conjunto de nodos, en cuyo caso se usa el primer elemento del conjunto como valor.

En segundo plano, el motor de reglas puede convertir un valor de campo de texto en cualquiera de los tipos admitidos a través de la función XmlConvert . Puede especificarlo estableciendo el tipo en Business Rule Composer. Se produce una excepción si no es posible realizar una conversión. Los tipos bool y double solo se pueden recuperar como su tipo, cadenas o objetos respectivos.

TypedDataTable

Cuando se afirma una TypedDataTable , todos los DataRows contenidos en DataTable se declaran automáticamente en el motor como TypedDataRows. Cada vez que se usa una tabla o una columna de tabla como argumento de regla, la expresión se evalúa con el typedDataRows individual y no con TypedDataTable.

Por ejemplo, supongamos que tiene la siguiente regla aplicada a una tabla "Clientes":

IF Northwind.Customers.CustomerID = 001  
THEN Northwind.Customers.ContactTitle = "Purchasing Manager"  

Supongamos que aserte la siguiente DataTable con tres DataRows en el motor (como TypedDataTable).

El motor inserta tres TypedDataRows: 001, 002 y 003.

Cada TypedDataRow se evalúa de forma independiente con respecto a la regla. El primer TypedDataRow cumple la condición de regla y los dos segundos producen un error. Los resultados aparecen como se indica a continuación.

DataSetName.DataTableName se considera un identificador único. Por lo tanto, si se afirma una segunda TypedDataTable con el mismo nombre de DataSet y DataTable, reemplaza a la primera TypedDataTable. Todos los TypedDataRow asociados con la primera TypedDataTable se retiran, y la segunda TypedDataTable se establece.

DataConnection

Al igual que con TypedDataTable, arrastrar una tabla o columna como argumento de regla en el Business Rule Composer resulta en reglas construidas contra los TypedDataRow devueltos, en lugar de contra la DataConnection en sí.

Supongamos que se crea la siguiente regla y se afirma un DataConnection que contiene un SqlConnection hacia Northwind.Customers.

IF Northwind.Customers.CustomerID = 001  
THEN Northwind.Customers.ContactTitle = "Purchasing Manager"  

Cuando el motor evalúa la regla usada en la sección TypedDataTable , compila dinámicamente una consulta similar a la siguiente:

SELECT *  
FROM Northwind.Customers  
WHERE CustomerID = 1  

Dado que solo una fila de la base de datos cumple este criterio, solo se crea un TypedDataRow y se afirma en el motor para su posterior procesamiento.

Resumen de entidades aseridas y tipos de instancia

En la tabla siguiente se resume el comportamiento de aserción de los distintos tipos, que muestra el número de instancias resultantes creadas en el motor para cada entidad aserda, así como el tipo que se aplica a cada una de esas instancias para identificarlas.

Véase también

Funciones de control del motor