Capítulo 4. Conceptos de BRMS


4.1. Las reglas son activos

Un "activo" es cualquier cosa que se pueda almacenar como una versión en el repositorio. Esto incluye reglas, tablas de decisión, modelos, pruebas y DSLs.

Nota

El término "regla" con frecuencia se utiliza muy vagamente. A veces se utiliza incorrectamente para referirse a activos que de hecho no son reglas.

4.2. Categorización

Figura 4.1. Categorias

Las categorias permiten etiquetar las reglas (activos) con cualquier número de agrupamientos que usted defina. Esto significa que luego puede ver una lista de reglas que coinciden con una categoría específica. Las reglas pueden pertenecer a cualquier número de categorias. En el diagrama anterior puede ver que se presenta como una carpeta/explorador como una vista de activos. Los nombres pueden ser como los quiera y los definen el administrador BRMS (también puede borrar /agregar nuevas categorias; solo puede borrarlas si actualmente no se encuentran en uso).
Generalmente las categorias se crean con nombres significativos que coinciden con el área empresarial a la cual aplica la regla (por lo tanto si la regla aplica a múltiples áreas se pueden adjuntar múltiples categorias). Las categorias también se pueden utilizar para "etiquetar" reglas como parte de su ciclo de vida, por ejemplo para marcar algo como "borrador" o "por revisar".

Figura 4.2. Los activos pueden tener múltiples categorías

La vista anterior muestra la categoría Editor/Vista que se puede ver cuando abre un activo. En este ejemplo puede ver que el activo pertenece a dos categorías. Esto significa que cuando cualquiera de las categorías se utiliza para mostrar una lista de activos entonces verá ese activo (el botón The view above shows the Category Editor/Viewer that is seen when you open an asset. In this example, you can see the asset belongs to two categories. This means that when either category is used to show a list of assets, you will see that asset. (The "+" y el ícnono de la basura se utiliza para agregar y borrar cosas adicionales respectivamente).
En el ejemplo anterior, la primera categoría ("Home") se encuentra en el nivel "superior". La segunda, "Mortage/Eligibility" todavía es una sola categoría, pero está anidada ya que las categorias son jerárquicas. En otras palabras, hay una categoría llamada "Mortage", la cual contiene una categoría llamada "Eligibility". La pantalla lo muestra como "Mortage/Eligibility." Como lo puede ver es análogo a la estructura del directorio que tiene en el sistema de archivos de su disco duro aunque las reglas pueden aparecer en múltiples lugares.
Cuando abre un activo con el fin de verlo o editarlo verá una lista de categorías a las cuales pertenece.Si realiza un cambio (borrar o agregar una categoría) será necesario que guarde el activo y esta acción creará un nuevo objeto en le historial de versiones. El cambio de categorías de una regla no afecta su ejecución.

Figura 4.3. Creación de categorías

La vista anterior muestra la pantalla de administración para la creación de categorías. No hay categorías por defecto en el sistema. Ya que las categorías pueden ser jerárquicas debe seleccionar la categoría "padre" para la cual quiere crear una sub-categoría. Desde aquí también se pueden borrar las categorías (pero solo si no están en uso por parte de cualquiera de los activos actuales).

Nota

Como regla general, un activo solo debe pertenecer a una o dos categorías a la vez. Las categorías son críticas en casos en donde tiene números grandes de reglas. Las jerarquías no necesitan ser muy profundas. Red Hat las diseñó para ayudarle a descomponer reglas/activos en partes administrables.

4.3. Autoría de reglas

La plataforma BRMS soporta varios formatos de activos (regla). Aquí se describen las que son clave. Algunas de estas se cubren en otras partes del manual así que no vamos a repetir esos detalles.

4.3.1. El editor de activos

Las opciones disponibles en el editor de activos dependerán del tipo de activo que se está editando. El editor de activos se utilizar para modificar reglas y se puede utilizar para agregar, borrar y re-ordenar condiciones, restricciones, acciones, campos y opciones. El editor de activos también le permite al usuario el trabajar con grupos, validay y verificar reglas así como ver la fuente de reglas.
Vea los tips sobre las herramientas en el editor de activos para obtener mayores detalles.

Figura 4.4. Vista del editor de activos

4.3.2. Reglas empresariales con el editor dirigido

Al modificar reglas el editor de activos también se conoce como el editor dirigido. El editor dirigido se utiliza para modificar reglas en el formato del lenguaje de reglas empresariales (BRL del inglés Business Rules Language). El editor dirigido le pide a los usuarios entradas con base en el modelo de objetos de la regla que se está modificando.
El acceso al paquete se debe configurar antes de poder utilizar el editor dirigido BRL.

Nota

Yambién hay un editor dirigido que se encuentra en el plug-in de Eclipse. La mayoría de los detalles en esta sección también aplican.

Ejemplo 4.1. El editor dirigido

4.3.3. Anatomía de una regla

Una regla tiene múltiples partes:
  • When
    La parte When de la regla es la condición con la que se debe cumplir. Por ejemplo en Ejemplo 4.1, “El editor dirigido”, la sección del when de la reglas es: When the applicant is under 21 years old.
  • Then
    La parte Then de la regla es la acción que se va a realizar cuando se ha cumplido con la parte condicional de la regla. Por ejemplo, en Ejemplo 4.1, “El editor dirigido”, la parte del then de la regla es: Then decline the loan because the applicant is under age.
Con el editor dirigido es posible agregar más condiciones al When (o la parte condicional) de la regla y se pueden añadir más acciones al Then (o acción) de la regla. Por ejemplo, si un candidato menor de 21 años tuviera un fiador para una aplicación de préstamo es posible que el banco decida aprobar la aplicación de préstamo. Para modelar esto en Ejemplo 4.1, “El editor dirigido” sería necesario el modificar el When para incluir la condición del fiador.

Ejemplo 4.2. Modificación de reglas

Para agregar un fiador a la condición primero es necesario el agregar el campo guarantor (fiador) al tipo de hecho de la aplicación para el modelo de crédito hipotecario.

Procedimiento 4.1. Agregar un campo a un tipo de hecho

  1. Seleccionar el modelo

    Seleccione Knowledge Bases del panel de navegación en el lado izquierdo de la pantalla. Expanda el paquete que contiene el modelo y seleccione model.
    Abra el modelo de la lista haciendo clic en open.
  2. Agregue el campo

    Despliegue el tipo de hecho haciendo clic en el signo más justo al lado y seleccione Add Field.
  3. Introduzca los detalles del campo

    Agregue los detalles en la ventana que aparece. En este caso introduzca fiador en el campo Field name y seleccione True or False del menú desplegable Type.
    Guarde los cambios realizados al modelo seleccionando File y Save changes.
Ya que se agregó el campo del fiador al tipo de hecho del aplicante es posible modificar la regla para incluir un fiador.

Procedimiento 4.2. Agregar restricciones a las reglas

  1. Borrar la restricción actual

    Al modificar una regla existente puede ser necesafrio el borrar la restricción actual. Esto asegura que se seleccione el operador lógico correcto (And u Or) al tratar con múltiples restricciones.
    En este caso haga clic en el símbolo de menos al lado de la condición de la edad.
  2. Modificación de restricciones

    Abra Modify Constraints Dialogue haciendo clic en el texto There is an Applicant.
    Seleccione la restricción del menú desplegable Add a restriction on a field. En este caso seleccione Age.
    Del menú deplegable Multiple field constraints seleccione All of (and).
  3. Especifique la primera restricción

    Haga clic en el texto all of the following para abrir la ventana Add fields to this constraint y agregue la restricción. En este caso seleccione Age.
    Del menú desplegable seleccione less than y modifique el valor literal haciendo clic en el ícono del lápiz, seleccione literal y luego haga clic en Value para introducir el valor apropiado, en este caso 21.
  4. Especifique la segunda restricción

    Haga clic en el texto all of the following para abrir la ventana Add fields to this constraint y agregue la restricción. Esta vez seleccione guarantor.
    Del nuevo menú desplegable seleccione equal to y modifique el valor literal haciendo clic sobre el ícono del lápiz, seleccione literal y luego haga clic en true para modificar el valor y seleccione falso.

4.3.4. Relevancia

La relevancia de una regla también se puede modificar desde el editor dirigido bajo opciones. La relevancia es un valor numérico que representa la prioridad de la regla.

4.3.5. Listas desplegables dirigidas por el usuario

Note que es posible el limitar los valores ce campos con solo cosas en una lista pre-configurada. Esta lista se configura como parte del paquete (se utiliza una enumeración de datos para poblarlo con valores). Estos valores pueden ser una lista fija o por ejemplo, se pueden cargar desde una base de datos. Esto es útil para los códigos y otros campos en donde hay valores establecidos. También es posible el tener lo que se puede ver en la pantalla en una lista desplegable y que sea diferente al valor (o código) utilizado en una regla. Consulte la sección sobre "Enumeración de datos" para obtener mayor información sobre la manera en que se configuran.

4.3.6. Incremento con declaraciones DSL

Si el paquete al cual pertenece la regla tiene una configuración DSL, cuando agrega condiciones o acciones, proporcionará una lista de "declaraciones DSL" de donde puede escoger (cuando escoja una agregará una fila a la regla), por medio de la cual los valores especificados por DSL provienen de un usuario y luego se presentará una casilla de modificación (se parece a una forma). Observe que esto es opcional y hay otro editor DSL.

Importante

El editor dirigido actualmente no soporta el grupo completo de funcionalidades DSL. Solo se soportan las secciones [when] y [then] de la configuración DSL.
El siguiente diagrama muestra las declaraciones DSL en acción en el editor dirigido:

Figura 4.5. DSL en el editor dirigido

4.3.7. Reglas DSL

Las reglas DSL son reglas textuales que utilizan un activo de configuración del lenguaje para controlar su apariencia.

Figura 4.6. Regla DSL

Una regla DSL es una sola regla. En la imagen anterior puede ver un editor de texto. Puede utilizar los íconos a la derecha para proporcionar listas de condiciones y acciones de las cuales escoger (de otra manera presione las teclas control y espacio al mismo tiempo para que la lista aparezca).

4.3.8. Hoja de cálculo de las tablas de decisión

Se pueden almacenar múltiples reglas en una hoja de cálculo de Microsoft Excel (con formato de archivo .xls), por medio del cual cada fila representa una regla. Los detalles de la hoja de cálculo no los abordamos en este capítulo.

Figura 4.7. Tabla de decisiones en la hoja de cálculo

Para utilizar una hoja de cálculo cargue un archivo .xls como se puede ver en Figura 4.7, “Tabla de decisiones en la hoja de cálculo”. También puede descargar la versión actual de la hoja de cálculo de la misma ventana. Con el fin de crear una nueva tabla de decisiones debe iniciar el "Rule Wizard" - el asistente de reglas-, el cual contiene una opción para este procedimiento y luego puede cargar el archivo .xls.

4.3.9. tablas de decisión dirigidas (basadas en la web)

La funcionalidad de las tablas de decisiones dirigidas permite modificar las tablas de decisiones en la web. Esto funciona de manera similar al editor dirigido realizando una introspección de los hechos y campos disponibles para dirigir la creación de una tabla de decisiones. Se pueden definir atributos de reglas, meta-datos, condiciones y acciones en una formato tabular, lo cual facilita la entrada rápida de grupos grandes de reglas relacionadas. Las reglas de las tablas de decisiones basadas en la web se compilan en DRL como todos los otros activos de reglas.
Las celdas se pueden seleccionar de varias maneras:
  • Se puede hacer doble clic en celdas individuales y aparece un editor correspondiente la tipo de datos subyacente. Se pueden seleccionar grupos de celdas en la misma columna haciendo clic en la primera y arrastrando el cursos o haciendo clic en la primera y haciendo clic sobre la extención del rango requerido presionando la tecla shift.
  • Opcionalmente se pueden utilizar las teclas para manejar el cursor y navegar en la tabla. El presionar la tecla enter hará que aparezca el editor correspondiente. El rango se puede seleccionar presionando la tecla shift y extendiendo el rango con las teclas que mueven el cursor.
Se puede modificar el tamaño de las columnas colocándose sobre el divisor correspondiente en el encabezado de la tabla. El curso del ratón cambiará y luego se puede modificar el ancho de la columna para hacerla más grande o más pequeña.

Figura 4.8. Tabla de decisiones

4.3.9.1. Componentes principales

La tabla de decisiones se divide en dos secciones principales:
  • La sección superior permite definir columnas de la tabla representando atributos de reglas, meta-datos, condiciones y acciones.
  • La sección inferior contiene la tabla en sí en donde filas individuales definen reglas separadas.

Figura 4.9. Componentes principales

4.3.9.2. Configuración de columnas

Las columnas pueden tener los siguientes tipos de restricción:
  • Literal
    El valor en la celda se comparará con el campo utilizando el operador.
  • Formula
    La expresioó en la celda se evaluará y luego se comparará con el campo.
  • Predicado
    No se necesita ningún campo, la expresión se evaluará como verdadera o falsa.
Puede establecer un valor predeterminado pero normalmente si no hay un valor en la celda entonces esa restricción no aplica.

Figura 4.10. Configuración de columnas

4.3.9.2.1. Columnas de funcionalidades
Por defecto se proporcionan dos columnas que contienen el número de la regla y la descripción.
4.3.9.2.2. Columnas de atributos
Se pueden agregar cero o más columnas de atributos que representan cualquiera de los atributos de reglas DRL. Se brinda un pseudo-atributo adicional en el editor de la tabla dirigida de decisiones para "negar" una regla. Este atributo permite negar reglas completas. Por ejemplo como se puede ver la siguiente regla simple se puede negar.
when
  $c : Cheese( name == "Cheddar" )
then
  ...
end
Copy to Clipboard Toggle word wrap
when
  not Cheese( name == "Cheddar" )
then
  ...
end
Copy to Clipboard Toggle word wrap
4.3.9.2.3. Columnas de meta-datos
Se pueden definir cero o más columnas de meta-datos, cada una representa la anotación de meta-datos normal en las reglas DRL.
4.3.9.2.4. Columnas de condiciones
Las condiciones representan patrones de hechos definidos en el lado izquierdo o en la parte "when" de una regla. Para definir una columna de condición debe definir un enlace a una clase modelo o debe seleccionar una que se haya definido previamente. Puede escoger el negar el patrón. Una vez que se haya completado esto puede definir restricciones de campos. Si dos o más columnas se definen utilizando el mismo enlace de patrón de hechos, las restricciones de campos se convierten en restricciones de campo compuestas en el mismo patrón. Si define múltiples enlaces para una sola clase modelo cada enlace se vuelve un modelo separado en el lado derecho de la regla.
4.3.9.2.5. Columnas de acción
Las columnas de acción se pueden definir para realizar operaciones simples en hechos enlazados dentro de la memoria de trabajo de la máquina de reglas o para crear hechos completamente nuevos. Los nuevos hechos se pueden incluir lógicamente en la memoria de trabajo de la máquina de reglas y por lo tanto está sujeta a un mantenimiento de verdad como siempre. Consulte JBoss Rules Reference Guide para obtener mayor información sombre el mantenimiento de verdades e inserciones lógicas.

4.3.9.3. Definición de reglas

Esta sección permite definir reglas individuales utilizando las columnas definidas anteriormente.

Figura 4.11. Definición de reglas

4.3.9.4. Fusión de celdas

El ícono en la parte superior izquierda de la tabla de decisiones prende y apaga la fusión de celdas. Cuando las celdas se fusionan, las que se encuentran en la misma columna con valores idénticos se fusionan en una sola celda. Esto simplifica el cambio de valor de múltiples celdas que compartían el nismo valor original. Cuando las celdas se fusionan también obtienen un ícono en la parte superior izquierda de la celda que permite agrupar las filas que abarcan la celda fusionada.

Figura 4.12. Fusión de celdas

4.3.9.5. Agrupamiento de celdas

Las celdas que se han fusionado se pueden plegar en una sola fila. El hacer clic en el ícono [+\-] en la parte superior izquierda de una celda fusionada pliega las filas correspondientes en una sola entrada. Las celdas en otras columnas que abarcan las filas plegadas que tienen valores idénticos se muestran sin ningún cambio. Las celdas en otras columnas que abarcan las filas plegadas que tienen valores diferentes se resaltan y presentan el primer valor.

Figura 4.13. Agrupamiento de celdas

Cuando se altera el valor de una celda agrupada entonces también se actualizan los valores de las celdas que se han plegado.

4.3.9.6. Operaciones Otherwise

Las columnas de condiciones definidas con valores literales que usan los operadores de igualdad == o desigualdad != pueden tomar ventaja del valor especial de la celda de la tabla de decisiones otherwise. Este valor especial permite definir una regla que coincida con todos los valores no definidos explícitamente en todas las otras reglas definidas en la tabla. Esto se ilustra mejor con un ejemplo:
when
  Cheese( name not in ("Cheddar", "Edam", "Brie") )
  ...
then
  ...
end
Copy to Clipboard Toggle word wrap
when
  Cheese( name in ("Cheddar", "Edam", "Brie") )
  ...
then
  ...
end
Copy to Clipboard Toggle word wrap

4.3.10. Plantillas de reglas

Las plantillas de reglas le permiten al usuario el definir una estructura de reglas con reservas de espacio para loa valores que se interpolan desde una tabla de datos. También se puede seguir utilizando valores literales, formulas y expresiones.
Las plantillas de reglas con frecuencia se pueden utilizar como una opción para las tablas de decisiones.

Procedimiento 4.3. Creación de plantillas de reglas

  1. Creación del activo de plantilllas de reglas

    Del menú Knowledge Bases seleccione Create New y luego seleccione New Rule Template.
  2. Definición del activo

    Introduzca un nombre, una categoría y una descripción para la plantilla.
  3. Definición de la plantilla

    Use el editor dirigido para construir la regla. Template keys son reservas de espacio dentro de la restricción del campo y las secciones de acción. Se pueden seguir utilizando los valores literales, las fórmulas y expresiones tal como en el editor dirigido estándar.
Ejemplo 4.3, “Plantilla de ejemplo” ilustra una regla simple que se ha definido con una llave de plantilla para la edad máxima del aplicante, su edad mínima y su calificación de crédito. Las llaves de la plantilla se han definido como "$max_age", "$min_age" y "$cr" respectivamente.

Ejemplo 4.3. Plantilla de ejemplo

4.3.10.1. Definición de datos de la plantilla

Cuando complete la definición de su plantilla de reglas necesita introducir los datos que se utilizarán para interpolar las reservas de espacio de la "llave de la plantilla". BRMS brinda la funcionalidad para introducir datos en una cuadrícula flexible dentro de la pantalla del editor dirigido. El editor dirigido se puede iniciar presionando el botón Load Template Data en la pantalla del editor dirigido.
La cuadrícula de datos de la plantilla de reglas es muy flexible con diferentes editores emergentes para los tipos de datos de los campos subyacentes, Se puede modificar el tamaño de las columnas y también se pueden organizar y las celdas se pueden fusiinar y agrupar para facilitar la entrada rápida de datos.
Una fila de datos interpola las reservas de espacio Template Key para una sola regla de tal manera que una fila se convierte en una regla.

Nota

Si se dejan celdas en blanco entonces no se genera la regla para la fila aplicable.

Figura 4.14. Plantilla de la cuadrícula de datos

4.3.10.1.1. Fusión de celdas
El ícono en la parte superior izquierda de la cuadrícula prende y apaga la fusión de celdas. Cuando las celdas se fusionan, las que se encuentran en la misma columna con valores idénticos se fusionan en una sola celda. Esto simplifica el cambio de valor de múltiples celdas que compartían el mismo valor original. Cuando las celdas se fusionan también obtienen un ícono en la parte superior izquierda de la celda que permite agrupar las filas que abarcan la celda fusionada.

Figura 4.15. Fusión de celdas

4.3.10.1.2. Agrupamiento de celdas
Las celdas que se han fusionado se pueden plegar en una sola fila. El hacer clic en el ícono [+\-] en la parte superior izquierda de una celda fusionada pliega las filas correspondientes en una sola entrada. Las celdas en otras columnas que abarcan las filas plegadas que tienen valores idénticos se muestran sin ningún cambio. Las celdas en otras columnas que abarcan las filas plegadas que tienen valores diferentes se resaltan y presentan el primer valor.

Figura 4.16. Agrupamiento de celdas

Cuando se altera el valor de una celda agrupada entonces también se actualizan los valores de las celdas que se han plegado.

4.3.10.2. DRL generado

Aunque no es necesario los autores de reglas pueden ver el DRL que se generará para una plantilla de reglas y los datos asociados. Esta funcionalidad y su operación no es diferente a la de otros activos. Seleccione la Source y luego View Source de la pantalla del editor de activos. Se puede ver el DRL ara todas las reglas.

Figura 4.17. DRL generado

4.3.11. Flujo de reglas

Flujo de reglas: el flujo de reglas le permite describir visualmente los pasos a tomar así que no todas las reglas se evalúan al mismo tiempo sino que hay un flujo de la lógica. En este capítulo no abordamos los flujos de reglas pero puede utilizar el IDE para dibujar gráficos de flujos de reglas y cargar el archivo .rfm en el BRMS.
De manera similar que las hojas de cálculo puede cargar/descargar archivos de flujos de reglas (el IDE de eclipse tiene un editor gráfico para estos). Los detalles de los flujos de reglas no se discuten aquí.

4.3.12. Reglas técnicas (DRL)

Las reglas técnicas (DRL) se almacenan como texto y se pueden administrar en el BRMS. Un archivo DRL puede contener una o más reglas. Si el archivo contiene solo una regla entonces el paquete importa y no se requieren las declaraciones de reglas. Simplemente puede utilizar "when" y "then" para marcar las secciones de "Condición" y "Acción" respectivamente.
Normalmente utilizaría el entorno de desarrollo integrado para modificar archivos "raw" DRL ya que tiene todas las herramientas avanzadas, ayuda de contenido y funcionalidad de depuración. Sin embargo, hay ocasiones en las que una regla tenga que tratar con algo más bien técnico en un paquete en BRMS. En cualquier paquete típico de reglas generalmente necesita algunas "reglas técnicas". Puede mezclar todos los tipos de reglas claro está.

Figura 4.18. Regla técnica DRL

4.3.13. Funciones

Las funciones son otro tipo de activo. No son reglas y solo se deben utilizar cuando sea necesario. El "Editor de funciones" es un editor textual.

Figura 4.19. Función

Las enumeraciones de datos son un tipo opcional de activo que se puede configurar para proporcionar listas desplegables para el editor dirigido. Se almacenan y se modifican como cualquier otro activo y solo se aplican al paquete al cual pertenecen.
El contenido de una configuración de enumeración es el mapeo de un "Fact.field" a una lista de valores. Estos valores se utilizan para poblar una lista desplegable. La lista puede ser literal o puede utilizar una clase de funcionalidad (la cual pone en la ruta de clase) para cargar las cadenas. Las cadenas contienen un valor que se puede ver en un menú desplegable o un mapeo desde el valor del código (lo cual es lo que se termina utilizando en la regla) y un valor de presentación (vea el ejemplo a continuación que usa el '=').
'Board.type' : [ 'Short', 'Long', 'M=Mini', 'Boogie']
'Person.age' : [ '20', '25', '30', '35' ]
Copy to Clipboard Toggle word wrap
En la configuración de enumeración anterior la "M" indica un valor que se utilizará en la regla pero "Mini" es lo que se presenta en la interfaz gráfica del usuario.
Obtención de listas de datos de fuentes externas
Es posible tener el código de llamada BRMS, el cual cargará una lista de cadenas. Para lograr esto, necesitará un pedazo de código que retorne un java.util.List (de cadenas) que esté en la ruta de clase del BRMS. En lugar de especificar una lista de valores en el BRMS mismo, el códeigo puede retornar la lista de cadenas, (como siempre puede utilizar el signo "=" dentro de las cadenas si quiere utilizar una valore de presentación diferente al valor de la regla). Por ejemplo puede cambiar la línea Person.age así:
'Person.age' : (new com.yourco.DataHelper()).getListOfAges()
Copy to Clipboard Toggle word wrap
Esto asume que tiene una clase llamada DataHelper, la cual tiene un método getListOfAges(), el cual retorna una lista de cadenas (y se encuentra en la ruta de clase). Por supuesto que puede mezclar estas enumeraciones "dinámicas" con listas fijas. Por ejemplo, podría cargarlas desde una base de datos usando JDBC. Las enumeraciones de datos se cargan la primera vez que utilice el editor dirigido en una sesión. Si tiene alguna sesión abierta del editor dirigido será necesario que la cierre y vuelva a abrir la regla para poder ver el cambio. Para verificar que la enumeración se ha cargado, vaya a la pantalla de configuración del paquete. Puede "guardar y validar" el paquete; esto lo chequeará y brindará cualquier comentario sobre los errores.

4.3.15. Conceptos avanzados de enumeración

Hay otras pocas tareas avanzadas que puede llevar acabo con enumeraciones de datos.
Listas desplegables dependientes de valores de campos
Imagínese un modelo simple de hechos, en el cual tiene una clase llamada Vehicle -vehículo que tiene dos campos: "engineType" y "fuelType." Quiere tener opciones para "engineType" de "Petrol" o "Diesel." Obviamente la opción del combustible debe ser dependiente del tipo de máquina (para gasolina tenemos ULP y PULP y para Diesel tenemos BIO y NORMAL). Podemos expresar esta dependencia en una enumeración así:
 'Vehicle.engineType' : ['Petrol', 'Diesel']
 'Vehicle.fuelType[engineType=Petrol]' : ['ULP', 'PULP' ]
 'Vehicle.fuelType[engineType=Diesel]' : ['BIO', 'NORMAL' ]
Copy to Clipboard Toggle word wrap
Esto muestra como es posible realizar selecciones dependientes en otros valores de campos. Note que una vez seleccione el engineType se determina la "lista seleccionada" para el fuelType.
Carfa de enumeraciones programáticamente
En algunos casos se querrá cargar los datos de enumeración desde una fuente de datos externa (como una base de datos relacional). Para lograr esto, puede implementar una clase que retorne un mapa. La clave del mapa es una cadena (la cual es el nombre Fact.field que vimos anteriormente). El valor es una java.util.List de cadenas.
public class SampleDataSource2 {

  public Map<String>, List<String>> loadData() {
    Map data = new HashMap();

    List d = new ArrayList();
    d.add("value1");
    d.add("value2");
    data.put("Fact.field", d);

    return data;
 }

}
Copy to Clipboard Toggle word wrap
En la enumeración en el BRMS ponga lo siguiente:
=(new SampleDataSource2()).loadData()
Copy to Clipboard Toggle word wrap
El signo "=" le dice que cargue los datos ejecutando su código.
Enumeraciones avanzadas
En los casos que vimos anteriormente los valores en las listas se calculan "por adelantado". Esto es muy adecuado para cantidades de datos relativamente estáticos o pequeños. Sin embargo, imagínese un escenario en donde tiene listas de países y cada país tiene una lista de estados, cada estado tiene una lista de localidades, cada localidad tiene una lista de calles, etc. Podrá ver que esto puede llegar a una gran cantidad de datos. Dicha cantidad no se podría cargar. En lugar, las listas se podrían cargar dependiendo del país que se selecciona.
Esta situación se puede abordar de la siguiente manera:
'Fact.field[dependentField1, dependentField2]' : '(new com.yourco.DataHelper()).getListOfAges("@{dependentField1}", "@{dependentField2}")'
Copy to Clipboard Toggle word wrap
Observe que solo se han especificado los campos que se necesitan. También a la derecha del signo ":" hay comillas alrededor de la expresión. Esta expresión se evaluará solo cuando se necesite. Cuando lo hace substituirá los valores de los campos especificados. Esto significa que puede utilizar los valores de los campos de la interfaz gráfica del usuario para dirigir una petición a la base de datos y profundizar en los datos, etc. Cuando se carga la lista desplegable de reglas, la lista se refrescará con base en esos campos. "depenentField1" y "dependentField2" son nombres de campos en el tipo "Fact". Se utilizan para calcular la lista de valores que se van a ver en una lista desplegable como valores para el "campo".

4.4. Administración del estatus

Cada activo y paquete en el BRMS tiene una etiqueta de estatus establecida. Los valores para la configuración de etiquetas de estatus se encuentran en la sección "Administración" del BRMS. Aquí puede agregar sus propios nombres de estatus. De manera similar a las categorías, los estatus NO afectan la ejecución de ninguna manera. Sólo proporcionan información.

Nota

De manera opuesta a las categorías, los activos solo pueden tener un estatus a la vez.
El uso de los estatus es completamente opcional. Puede utilizar los estatus o las categorías para administrar el ciclo de vida de los activos.

Figura 4.20. Estatus de los activos

El diagrama anterior presenta un cambio en el estatus de un activo individual. El cambio tiene efecto de manera inmediata y no se necesitar guardar por separado.
También puede cambiar el estatus de un paquete completo. Esto establece la etiqueta del estatus en el paquete mismo y en todos los activos que pertenecen al mismo valor.

4.5. Administración de paquetes

En el BRMS tiene una "base de conocimiento," la cual contendrá uno o más "paquetes de conocimiento." En la interfaz del usuario, los paquetes de conocimeinto con frecuencia se conocen simplemente como "paquetes."

Aviso

El configurar paquetes de conocimeinto usualmente es una tarea que sólamente se lleva a cabo una sola vez y que la realiza alguien con experiencia en desarrollo de reglas y modelos. Muy pocas personas necesitarán configurar los paquetes de conocimiento y una vez que estén listos se pueden copiar sucesivamente si es necesario. La configuración de paquetes es definitivamente una tarea técnica que requiere experiencia con el desarrollo de reglas.
Todos los activos viven en "paquetes" en el BRMS. Un paquete es como un sub-directorio (y también sirve como un "espacio de nombre"). Es el equivalente a una carpeta de inicio, en la cual viven los activos de reglas. Las reglas en particular necesitan saber la naturaleza del modelo de hechos y el espacio de nombres.

Figura 4.21. El explorador de paquetes

La figura anterior muestra el explorador de paquetes. Al hacer clic en un tipo de activos mostrará una lista de coincidencias (para los paquetes con miles de reglas y puede que tome varios segundos para que se presente la lista, de ahí viene la importancia del uso de categorías para una navegación rápida).
Para resumir, aunque las reglas (y activos en general) peuden aparecer en cualquier número de categorías, sólo viven en un paquete. Si considera el BRMS como un sistema de archivos entonces cada paquete es un directorio y los activos viven en ese directorio como una lista de archivos. Cuando crea una toma de pantalla de una implementación de un paquete, está efectivamente copiando todos los activos de ese "directorio" en otro "directorio" especial.
La funcionalidad de administración de paquetes le permite ver una lista de paquetes de conocimiento y puede "expandirlos" para ver listas de cada "tipo" de activo, (hay muchos activos así que algunos de ellos se agrupan juntos):
Los tipos de activos:
  • Activos empresariales: este muestra una lista de todos los tipos de "reglas empresariales", incluyendo tablas de decisiones, reglas empresariales, etc.
  • Activos técnicos: esta es una lista de cosas que se consideran como técnicas (tal como reglas DRL, enumeraciones de datos y flujos de reglas).
  • Funciones: en BRMS también puede tener funciones definidas, (estos es opcional).
  • DSL: del inglés Domain Specific Languages - lenguajes específicos de dominios - también se pueden almacenar como activos. Si existen (generalmente solo habrá uno) entonces se utilizarán junto con los GUIs del editor apropiado.
  • Modelo: un paquete requiere por lo menos un modelo. Este es para las reglas.

Figura 4.22. Creación de nuevos activos

Puede crear nuevas reglas o nuevos activos usando el explorador de paquetes. Algunos activos sólo se pueden crear por medio del explorador de paquetes. Figura 4.22, “Creación de nuevos activos” muestra los íconos que inicial los "asistentes" para este propósito.

Figura 4.23. Configuración de paquetes

Una de las cosas más importantes que tiene que hacer es configurar paquetes. Esta tarea implica dos aspectos de la importación de clases que las reglas utilizan y luego definir variables globales. Una vez que realiza un cambio es necesario guardarlo. En ese momento, el paquete está configurado y está listo para construir. Por ejemplo, puede agregar un modelo, el cual tiene una clase llamada com.something.Hello. Luego agregaría import com.something.Hello en su configuración de paquete y guardaría el cambio.

Figura 4.24. Construcción de paquetes

Después de importar las clases del paquete y de definir sus variables globales, se construye el paquete. Entre más activos tenga un paquete entonces tomará más tiempo en construírse. Si la construcción tiene éxito entonces tendrá la opción de crear una "toma de pantalla" para la implementación. En ese punto también puede ver el "drl" que se genera cuando se construye el paquete.

4.5.1. Importación de paquetes drl

También es posible crear un paquete importando un archivo "drl" ya existente. Cuando decide crear un nuevo paquete tiene la opción de cargar un archivo .drl. BRMS tratará de comprender ese drl y creará automáticamente un paquete por usted. Las reglas en este se almacenarán como activos individuales (aunque todavía serán contenido de texto drl). Note que para contruir el paquete necesitará cargar un modelo apropiado (como un .jar) frente al cual validar. Este es un paso separado.

4.6. Administración de versiones

Tanto paquetes de conocimiento como activos individuales tienen versiones en el BRMS pero el mecanismo es un poco diferente para cada uno. Los activos individuales se guardan como una versión de un archivo en un sistema de control de fuentes tal como Subversion. Sin embargo, los paquetes de activos tienen versiones "a demanda" realizando una toma de pantalla. Esta toma de pantalla es la que se utiliza para la implementación. La siguiente sección aborda la administración de la implementación y las tomas de pantalla con más detalles.

Figura 4.25. Versiones de activos

Cada vez que realiza un cambio a un activo se crea un nuevo objeto en el historial de versiones. Esto le brinda una función ilimitada para "deshacer". Puede mirar la historia de un activo individual, (como se puede ver en la lista anterior) y luego verlo y reestablecerlo desde ese momento.

4.7. Administración de implementación

Las URLs son una parte central del proceso que rodea la manera en que se proporcionan los paquetes de conocimiento. BRMS proporciona paquetes de conocimiento por medio de URLs para que el agente de conocimiento los utilice y los descargue. Estas URLs tienen la forma: http://localhost:8080/jboss-brms/org.drools.guvnor.Guvnor/package/<packageName>/<packageVersion>
<packageName> es el nombre que le dio al paquete. <packageVersion> es el nombre o una toma de pantalla o "LATEST" (si es "LATEST," entonces será la última versión construída del paquete principal y no una toma de pantalla). Puede utilizarlas en el agente o puede pegarlas en su navegador y las descargará como archivos.
Consulte Sección 8.1, “El agente de conocimiento” para obtener mayores detalles sobre cómo utilizar estas URLs y las descargas binarias en su aplicación y la manera en que se pueden actualizar las reglas "sobre la marcha".

Figura 4.26. Tomas de pantallas de implementaciones

La imagen anterior muestra la vista Deployment Snapshots. En la izquierda hay una lista de paquetes de conocimiento. Al hacer clic en un paquete en especifico en esa lista podrá ver todas las tomas de pantalla para este (si hay alguna). Desde allí puede copiar, borrar o ver una toma de pantalla. Cada toma de pantalla está disponible para descargarse o para accederla por medio de una URL. Una vez descargada se pueden implementar.

4.8. Navegación del repositorio y ubicación de reglas

Las dos maneras principales de ver el repositorio es utilizar la categorización dirigida por el usuario (también conocida como etiquetación) y la vista Package Explorer.
La vista de categorías le brinda una manera de navigar sus reglas que tengan sentido para su organización.

Figura 4.27. Vista de categoría

El diagrama anterior muestra la funcionalidad de categoría en acción. Si es posible limite el número de reglas en cada categoría a máximo unas pocas docenas.
La vista opcional usa el explorador de paquetes. Esta vista muestra los activos de una manera que refleja cómo están de hecho almacenados en la base de datos. También separa reglas en paquetes de conocimiento y su tipo o formato.

Figura 4.28. Vista de paquete

Volver arriba
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2025 Red Hat