Algoritmo secuencial

Tuplas

Selección de reglas en modalidad secuencial

Las reglas de una tarea de regla que se establecen con la propiedad algorithm igual a sequential se convierten dinámicamente en código de bytes Java. El código de bytes es capaz de realizar un proceso secuencial cuando se ejecuta la tarea.

La propiedad body de una tarea de regla es obligatoria. Selecciona las reglas del conjunto de reglas que la tarea de reglas tiene en cuenta.

Consulte también Selección de reglas de tiempo de ejecución.

Propiedades de control en modalidad secuencial

Las propiedades de control afectan a la ejecución en modalidad secuencial y a la estructura de tupla. Consulte Propiedades de control para tareas de reglas en modalidades de ejecución para obtener más información general.

El número de reglas que se deben ejecutar por tupla y el orden en el que se ejecutan se pueden especificar con las propiedades de control: orden, activacióny firinglimit.

La propiedad de ordenación

La propiedad ordering es obligatoria para el proceso secuencial. Describe el orden en el que se ejecutarán las reglas de la tarea de regla.

Hay dos valores disponibles:

• literal: las reglas se mantienen en el orden en el que se establecen en el cuerpo de la tarea (utilizando flechas arriba/abajo).

• sorted: las reglas se ordenan según sus prioridades estáticas.

Tenga en cuenta que otro valor, dynamic, sólo está disponible para las tareas de regla que utilizan la modalidad de ejecución RetePlus .

La propiedad de activación

La propiedad firing especifica si, para cada tupla, se deben ejecutar todas las reglas o sólo la primera regla que se aplica. Esta propiedad es opcional.

Tiene dos valores posibles:

• allrules

  Este valor significa que todas las reglas que se aplican deben ejecutarse antes de saltarse a la siguiente tupla. Este es el valor predeterminado.

• rule

  Este valor significa que sólo se debe ejecutar la primera regla que se aplica en la primera tupla.

La propiedad firinglimit

La propiedad firinglimit proporciona otro nivel de control cuando la propiedad firing se establece en allrules. Se utiliza para especificar un número que representa el número máximo de reglas que se deben ejecutar antes de saltar a la siguiente tupla. Este número debe ser mayor que cero.

Limitaciones conocidas del algoritmo secuencial

En casi todos los casos no hay limitación en el número de reglas manejadas por una sola tarea que tiene una propiedad de algoritmo igual a secuencial. La única excepción es con tablas de decisiones extremadamente grandes con un otherwise. El proceso es el siguiente: todas las condiciones de todas las líneas se niegan en una sola expresión. Esta expresión única se convierte en el cuerpo de un único método una vez traducido al código de bytes. Esto es un problema porque el verificador Java rechaza los métodos con un cuerpo demasiado grande. El algoritmo de escalabilidad utilizado para las reglas no se reduce al cuerpo del método. Se notifica al usuario de esta limitación cuando el cargador de clases rechaza las reglas. El límite en el número de reglas no es claro, pero es probable que el número sea de varios miles.

La tabla siguiente describe las limitaciones del proceso secuencial, en particular su uso combinado con determinadas construcciones de ILOG ® Rule Language (IRL).

IlrContext mycontext="....";
IlrExceptionHandler myhandler="....";
mycontext.setExceptionHandler(myhandler);

ruletask main {
   algorithm = sequential;
   ordering = literal;
   body = {Person,PersonProduct}
}

(Person,Product)

void matchObjects(Object[] tuple) {
   rule_Person((Person)tuple[0]);
   rule_PersonProduct((Person)tuple[0],(Product)tuple[1]);
}

Los ejemplos siguientes muestran casos que causan errores de compilación JIT (Just-In-Time), es decir, un error en tiempo de ejecución en lugar de un error de análisis.

Ejemplo 1: Limitación de IRL que provoca un error de compilación

Este ejemplo da como resultado errores de compilación JIT debido a que faltan enumeradores.

ruletask T {
  algorithm = sequential;
  body = { R1, R2, R3, R4, R5, R6, R7, R8, R9 }
}

rule R1 {
  when {
    not MyObject();  // No enumerator, an error will occur
  }
  then {
  }
}

rule R2 {
  when {
    exists MyObject();  // No enumerator, an error will occur
  }
  then {
  }
}

rule R3 {
  when {
    collect MyObject() where (size() == 1);  // No enumerator, an error
                                                will occur
  }
  then {
  }
}

function Object getObject() {
  return new MyObject();
}

function Object[] getObjects() {
  Object objs = new Object[1];
  objs[0] = getObject();
  return objs;
}

rule R4 {
  when {
    not MyObject() from getObject();  // An enumerator, no error
  }
  then {
  }
} 

rule R5 {
  when {
    not MyObject() in getObjects();  // An enumerator, no error
  }
  then {
  }
} 

rule R6 {
  when {
    exists MyObject() from getObject();  // An enumerator, no error
  }
  then {
  }
} 

rule R7 {
  when {
    exists MyObject() in getObjects();  // An enumerator, no error
  }
  then {
  }
} 

rule R8 {
  when {
    collect MyObject() from getObject() where (size() == 1); 
    // An enumerator, no error
  }
  then {
  }
} 

rule R9 {
  when {
    collect MyObject() in getObjects() where (size() == 1);  
    // An enumerator, no error
  }
  then {
  }
}

Ejemplo 2: IRL que muestra limitaciones de construcción

A continuación se muestra un ejemplo con una construcción collect para mostrar el ámbito de los enlaces. Esto también se mantiene para not y exists . Este ejemplo también genera errores de compilación JIT debido al uso de construcciones no soportadas.

rule R10 {
  when {
    r:MyRootObject();
    c:collect MyObject(n:name; n.startsWith("ilog")) in r.getObjects(); 
    where (s:size(); s > 1);
  }
  then {
    out.println(r);  // correct
    out.println(c);  // correct
    out.println(s);  // correct
    out.println(n);  // error
  }
}