2.4. Descriptores de implementación
Los procesos y reglas dentro de Red Hat JBoss BPM Suite 6 y posterior son almacenados en Apache Maven con base en paquetes y se conocen como los archivos de conocimiento o kjar. Las reglas, los procesos y activos, hacen parte del archivo jar y son administrados por Maven. A fin de definir las bases de conocimientos y las sesiones, se puede utilizar un archivo dentro del directorio
META-INF del kjar denominado kmodule.xml. Este archivo kmodule.xml está vacío por defecto.
Siempre que un componente como Central empresarial esté a punto de procesar el kjar, buscará
kmodule.xml para construir la representación del tiempo de ejecución.
Descriptores de implementaciones, una nueva funcionalidad introducida en 6.1 de Red Hat JBoss BPM Suite, la cual le permite un control detallado sobre su implementación y complementa el archivo
kmodule.xml. La presencia de estos descriptores es opcional y su implementación proseguirá sin ellos. Las propiedades que pueden establecerse mediante estos descriptores son únicamente de naturaleza técnica e incluyen metavalores de estrategia de tiempo de ejecución, la auditoría y la persistencia.
Estos descriptores le permiten configurar el servidor de ejecución en múltiples niveles (nivel de servidor predeterminado, descriptor de implementación diferente por kjar y así sucesivamente). Esta acción le permite hacer ajustes sencillos a la configuración lista para utilizar del servidor de ejecución (en lo posible por kjar).
Defina los descriptores en un archivo llamado
kie-deployment-descriptor.xml y colóquelo cerca de su archivo kmodule.xml en su carpeta META-INF. Puede cambiar esta ubicación predeterminada (y el nombre de archivo) al especificarlo como un parámetro de sistema:
-Dorg.kie.deployment.desc.location=file:/path/to/file/company-deployment-descriptor.xml
2.4.1. Configuración del descriptor de implementación
Los descriptores de implementación permiten al usuario configurar el servidor de ejecución en múltiples niveles:
- nivel de servidor: el nivel principal y el que aplica a todos los kjars implementados en el servidor.
- Nivel kjar: le permite configurar descriptores sobre la base de un kjar.
- nivel de tiempo de implementación: descriptores que aplican durante la implementación de kjar.
Los elementos de configuración de grano fino especificados por los descriptores de implementación tienen prioridad sobre los niveles de servidor, salvo en caso de elementos de configuración que se basan en colección, los cuales se fusionan. La jerarquía funciona como esto: configuración de tiempo de implementación > configuración kjar >configuración de servidor.
Nota
El tiempo de implementación aplica la configuración para implementaciones realizadas a través de la API REST.
Por ejemplo, si el modo de persistencia (uno de los elementos que usted configura) definido en el nivel de servidor es
NONE, pero el mismo modo es especificado como JPA en el nivel de kjarl, el modo real será JPA para dicho kjar. Si no se especifica nada para el modo persistencia en el descriptor de implementación ), se retrocederá a la configuración de nivel de servidor, la cual en este caso es NONE (o para JPA si no hay descriptor de implementación de nivel de servidor).
¿Puede usted sobrescribir esta conducta de modo de fusión jerarquía?
Sí. En la forma predeterminada, si existen descriptores de implementación presentes en múltiples niveles, las propiedades de configuración se fusionan con las granulares que sobrescriben los valores en bruto y por los ítems de configuración faltantes en el nivel granular que se suple con dichos valores en los niveles superiores. El resultado final es una configuración fusionada de descriptor de implementación. Este modo de fusión predeterminado se denomina el modo
MERGE_COLLECTIONS. No obstante, usted puede cambiarlo (Sección 2.4.2, “Administración de los descriptores de implementación”) si no se ajusta a su entorno:
- KEEP_ALL: en este modo , todos loa valores superiores sobrescriben los valores de nivel inferior (los valores de nivel de servidor remplazan los valores kjar.)
- OVERRIDE_ALL: en este modo, todos los niveles inferiores sobrescriben todos los valores superiores (los valores kjar remplazan los valores de nivel de servidor)
- OVERRIDE_EMPTY: en este modo, todos los ítems de configuración non empty de los niveles inferiores, remplazan los de los niveles superiores, incluidos los que se representan como colecciones.
- MERGE_COLLECTIONS (PREDETERMINADO): en este modo, todos los ítems de configuración no vacíos del nivel inferior remplazan los de los niveles superiores (como en OVERRIDE_EMPTY), pero las propiedades de colección se fusionan (combinan).
Los descriptores de implementación de kjar dependientes se sitúan en un nivel inferior al del kjar real que se implementa.
¿Necesitaré proveer un descriptor de implementación completo para todos los kjar?
No. Es precisamente aquí que la fusión entre los diferentes archivos puede serle útil. Es posible y recomendable proveer los descriptores de implementación parciales. Por ejemplo, si desea sobrescribir el modo auditoría en un kjar, deberá proporcionarlo y el resto de los valores se fusionarán desde el nivel de servidor o los kjar de nivel superior
Vale la pena anotar que al utilizar el uso de modo fusión OVERRIDE_ALL, todos los ítems de configuración deben especificarse, ya que el kjar relevante, siempre los usará y no se fusionará con otro descriptor de implementación en la jerarquía.
¿Qué puede configurar?
Los detalles de un nivel superior técnico pueden ser configurados a través de los descriptores de implementación. La siguiente tabla los enumera con los valores permisibles y predeterminados para cada uno.
Tabla 2.1. Descriptores de implementación
| Configuración | Entrada XML | Valores permisibles | Valor predeterminado |
|---|---|---|---|
| Nombre de la unidad de persistencia para datos de tiempo de ejecución | persistence-unit | Cualquier nombre de paquete válido de persistencia | org.jbpm.domain |
| Nombre de la unidad de persistencia para datos de auditoría | audit-persistence-unit | Cualquier nombre de paquete válido de persistencia | org.jbpm.domain |
| Modo de persistencia | persistence-mode | JPA, NONE | JPA |
| Modo de auditoría | audit-mode | JPA, JMS o NONE | JPA |
| Estrategia de tiempo de ejecución | runtime-strategy | SINGLETON, PER_REQUEST o PER_PROCESS_INSTANCE | SINGLETON |
| Lista de oyentes que van a ser registrados | event-listeners | Nombres de oyentes válidos como ObjectModel | Sin valor predeterminado |
| Lista de tareas que van a ser registradas | task-event-listeners | Nombres de oyentes válidos como ObjectModel | Sin valor predeterminado |
| Lista de manejadores de elementos de trabajo que van a ser registradas | work-item-handlers | Clases válidas del manejador de elementos dados como NamedObjectHandler | Sin valor predeterminado |
| Lista de variables globales a ser registradas | globals | Variables globales dadas como NamedObjectModel | Sin valor predeterminado |
| Las estrategias de Marshalling que van a ser registradas (para persistencia variables conectables) | marshalling-strategies | Clases ObjectModel válidas | Sin valor predeterminado |
| Roles requeridos que van a ser otorgados a los recursos del kjar | required-roles | Cadena de nombres de roles | Sin valor predeterminado |
| Entradas de entorno adicionales para la sesión de conocimientos | environment-entries | NamedObjectModel válido | Sin valor predeterminado |
| Opciones de configuración adicionales para la sesión de conocimientos | configuraciones | NamedObjectModel válido | Sin valor predeterminado |
Cómo proveer valores para colecciones basadas en ítems de configuración?
En los ítems de configuración en la tabla de ítems de configuración anterior, debería notar los valores válidos para la colección basada en ítems pueden ser
ObjectModel o NamedObjectModel. Ambos son similares y proveen definición del objeto para el tiempo de ejecución construido o creado, a excepción de los detalles de nombre de objeto NamedObjectModel que deben ser observados. Ambos tipos se definen mediante un identificador, parámetros opcionales y un 'resolver' (para resolver el objeto).
- identifier - define toda la información sobre el objeto, como por ejemplo el nombre de clase completo, el identificador de bean Spring o la expresión MVEL.
- parameters - parámetros opcionales que deben utilizarse durante las instancias de creación de objetos desde este modelo.
- resolver - identificador del resolver que será utilizado para crear instancias de objetos desde el modelo - (reflection, mvel o Spring).
Como un ejemplo, si ha construido una estrategia marshalling y desea que sus implementaciones usen dicha estrategia en lugar de la predeterminada, deberá proveer esa estrategia como un
ObjectModel, con el identificador com.mycompany.MyStrategy, el programa de resolución que es reflexión (los parámetros más fáciles y predeterminados que se requieren para que su estrategia funcione. La reflexión será utilizada para crear una instancia de esta estrategia mediante el nombre de clase completo que usted ya ha provisto como identificador.
<marshalling-strategy>
<resolver>reflection</resolver>
<identifier>com.myCompany.MyStrategy</identifier>
<parameters>
<parameter xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema">
param
</parameter>
</parameters>
</marshalling-strategy>
En el caso de que un programa de resolución no sea suficiente (como se demuestra en el ejemplo anterior), usted puede usar el resolver basado en la expresión MVEL como identificador del modelo de objeto. Al evaluar las expresiones, usted puede sustituir los parámetros que venían ya establecidos. Por ejemplo:
<marshalling-strategy> <resolver>mvel</resolver> <identifier>new com.myCompany.CustomStrategy(runtimeManager)</identifier> </marshalling-strategy>
El resolver basado en Spring le permite buscar un bean por su identificador desde un contexto de aplicación Spring. Siempre y cuando JBoss BPM Suite se utilice con Spring, este resolver ayuda en la implementación de kjars dentro del tiempo de ejecución. A manera de ejemplo (observe que el identificador en este caso es un bean denominado en el contexto Spring):
<marshalling-strategy> <resolver>spring</resolver> <identifier>customStrategy</identifier> </marshalling-strategy>
2.4.2. Administración de los descriptores de implementación
Los descriptores de implementación pueden ser modificados a través de la Central empresarial en una de las siguientes formas: En forma gráfica (haciendo clic en Autoría → Autoría de proyecto y luego al seleccionar Herramientas → Descriptor de implementación) o al hacer clic en el menú Authoría → Administración y luego haga clic a través de la carpeta
META-INF en el archivo Explorer. Haga clic en el archivo kie-deployment-descriptor.xml para editarlo de forma manual.
Cada vez que se crea un proyecto, el archivo
kie-deployment-descriptor.xml de inventario se genera con los valores predeterminados como se describió anteriormente.
Sobrescritura del comportamiento de modo de fusión jerárquico
Para cambiar el modo predeterminado de MERGE_COLLECTIONS a uno de KEEP_ALL, OVERRIDE_ALL o OVERRIDE_EMPTY utilice los siguientes métodos, según el requerimiento.
- Establezca la propiedad del sistema org.kie.dd.mergemode a uno de estos valores. Este modo de fusión se convertirá en predeterminado para todos los kjars implementados en el sistema, a menos que usted lo sobrescriba en un nivel kjar a través del siguiente método.
- Al implementar una nueva unidad a través de Central empresarial (Implementar → Implementaciones) usted puede seleccionar que el modo de fusión sea utilizado para dicho kjar determinado.
- Cuando se implementa a través de la API REST, usted puede agregar el parámetro de la petición mergemode a la URL del comando a uno de estos modos a fin de establecer el modo de fusión para dicha implementación.
Restricción del acceso al motor Runtime
Uno de los ítems de configuración discutidos anteriormente, required-roles, pueden ser modificados a través de los descriptores de implementación. Esta propiedad restringe el acceso al motor de tiempo de ejecución en un nivel por kjar o por servidor al garantizar que el acceso a algunos procesos sea únicamente otorgado a los usuarios pertenecientes a grupos definidos por esta propiedad.
El rol de seguridad puede utilizarse para restringir el acceso a las definiciones del proceso o restringir el acceso en tiempo de ejecución.
La conducta predeterminada debe ser agregada a los roles requeridos con base en restricciones de repositorios. Claro está que usted puede modificar estas propiedades de forma manual, como se describe arriba al proporcionar los roles que coincidan con los roles reales definidos en el reino de seguridad.