Visión general de integración entre ILOG JRules y WebSphere Process Server

Aprenda a integrar WebSphere® ILOG® JRules y WebSphere Process Server para implementar procesos de negocios ágiles. Este artículo describe puntos claves de la instalación y configuración, diferentes metodologías de integración y el monitoreo de JRules usando CEI en WebSphere Process Server.

Zi Hui Duan, Staff Software Engineer, IBM

Photo of Zi Hui DuanZi Hui Duan (Steven) es Staff Software Engineer y Business Process Management Integration Quality Assurance Team Designer en el IBM China Development Lab de Beijing, China. Posee profundos conocimientos de SOA, BPM y J2EE y cuenta con amplia experiencia en productos de la familia IBM BPM. Antes de pertenecer al equipo BPM IQA, Steven era desarrollador de WebSphere Process Server y WebSphere Interchange Server. Además, tiene experiencia en L3 con WebSphere Process Server.



Zhi Qiu Xie, Software Engineer, IBM

Photo of Zhi Qiu XieZhi Qiu Xie (Samuel) es actualmente miembro del equipo Business Process Management Integration Quality Assurance del IBM China Development Lab en Beijing, China. Posee amplia experiencia en productos BPM como WebSphere Integration Developer, WebSphere Process Server, WebSphere Business Monitor, WebSphere Dynamic Process Edition, WebSphere Service Registry and Repository, y ILOG Business Rule Management System. También tiene profundos conocimientos de desarrollo de Java/J2EE y prueba de productos. Antes de unirse al equipo BPM IQA, Samuel pertenecía al equipo de validación de sistemas WebSphere Process Server.



Hua Cheng, BPM Integration QA, IBM  

Hua ChengHua Cheng (Ted) forma parte de IBM desde el año 2003 y actualmente es Team Lead del equipo de BPM Integration QA. Tiene amplia experiencia en productos BPM como WID, WPS, Modeler, Monitor y Adapter. También posee profundos conocimientos en desarrollo de Java/J2EE y pruebas de productos. Antes de ocupar su rol actual, trabajó en varios desarrollos y proyectos de prueba de WPS (Webpshere Process Server), como WPS Component Owner, Development Lead y Test Lead.



01-08-2011

Introducción

La Gestión de Procesos de Negocios (BPM, por su sigla en inglés) y el Sistema de Gestión de Reglas de Negocios (BRMS, por su sigla en inglés) son dos aspectos fundamentales en los productos de middleware empresarial actual. Con el aumento de los requisitos de los clientes, BPM y BRMS se integran cada vez más para entregar soluciones de clientes de gran agilidad y extensibilidad para los procesos de negocios. WebSphere Process Server V7.0 y ILOG JRules V7.0.2 son los productos centrales de BPM y BRMS, respectivamente. Este artículo comienza con una breve introducción a Process Server y JRules y luego explica en detalle cómo integrar ILOG JRules y Process Server para implementar un proceso de negocios ágil abordando puntos claves de la instalación y configuración, diferentes metodologías de integración como POJO, EJB, servicios web y JMS/MQ, y refiriéndose a servicios JRules de monitoreo que usan Infraestructura de Eventos Comunes (Common Event Infrastructure - CEI) en Process Server.

Este artículo proporciona una visión general de la integración de ILOG JRules y WebSphere Process Server. Si necesita una guía que describa paso a paso los puntos de integración mencionados en este artículo, consulte el white paper Integrate WebSphere ILOG JRules with WebSphere Process Server.


Generalidades

La Gestión de Procesos de Negocios es cada vez más importante y se ha convertido en una parte clave de la infraestructura de TI empresarial. Los procesos de negocios de una empresa pueden modelarse, implementarse, ejecutarse y monitorearse en una plataforma de una suite de productos BPM y las reglas de negocios pueden formar parte de un proceso de negocios. Por ejemplo, en un proceso de verificación de cuentas de un banco, las políticas de negocios empleadas para evaluar la eligibilidad de una decisión con respecto a clientes o precios son complejas y propensas a cambiar en una realidad de mercados en rápida evolución. Por consiguiente, codificar las políticas de forma rígida en el proceso no es recomendable, ya que gestionar y mantener reglas de negocios durante el tiempo de ejecución resulta una tarea difícil. Separar las reglas de negocios del proceso de negocios para ejecutarlas y gestionarlas de manera independiente se traduce en una mejora de la agilidad y extensibilidad del proceso de negocios en su totalidad. La Figura 1 representa esta idea.

Figura 1. Reglas de negocios separadas del proceso de negocios
Reglas de negocios separadas del proceso de negocios

Dentro de la cartera BPM actual de IBM, WebSphere Process Server es la plataforma de ejecución de procesos de negocios para la empresa que proporciona una infraestructura de procesos de negocios poderosa, ampliamente extensible y compatible con los estándares de la industria. Process Server se basa en la plataforma WebSphere Application Server y brinda la capacidad Enterprise Service Bus (ESB), la cual habilita la arquitectura orientada a servicios (SOA) en la empresa. WebSphere Integration Developer (en adelante denominado “Integration Developer”) es la herramienta de desarrollo y montaje del proceso de negocios. Los proyectos desarrollados en Integration Developer pueden implementarse en Process Server y luego ejecutarse directamente.

Si bien Integration Developer y Process Server ya poseen incrustados un editor y un motor de reglas de negocios, estos solamente pueden usarse para implementar reglas o tablas de decisión simples con una interacción de usuarios de negocios limitada. En la mayoría de los casos de uso, el motor de reglas incrustado no logra cumplir con requisitos de negocios complejos. Por lo tanto, lo que se necesita es un sistema de gestión de reglas de negocios dedicado y poderoso que soporte todo el ciclo de vida de modelado, ejecución y gestión de reglas de negocios y que pueda integrarse fácilmente con productos BPM.

ILOG JRules, sistema de gestión de reglas de negocios líder de mercado, ofrece las capacidades de negocios requeridas para crear, implementar y gestionar reglas de negocios. ILOG JRules soporta el cambio eficiente de políticas y la rápida implementación de políticas, dos atributos necesarios para toda empresa ágil y globalmente integrada.

ILOG JRules brinda una forma sistemática de modelar, implementar e implantar reglas de negocios y soporta la colaboración de manera ordenada y eficiente. Este producto incluye herramientas personalizadas en base a las habilidades y el conocimiento de usuarios individuales que permiten que los administradores de políticas, los analistas de negocios y los desarrolladores obtengan el soporte que necesitan para aprovechar al máximo sus BRMS.

La Figura 2 muestra la arquitectura de ILOG JRules.

Figura 2. Arquitectura de ILOG JRules
Arquitectura de ILOG JRules

La siguiente sección incluye una breve introducción de los distintas partes que componen la arquitectura de ILOG JRules.

ILOG Rule Studio: Entorno de desarrollo basado en Eclipse para el desarrollo de aplicaciones de reglas. Permite la coedición y depuración integrada de reglas y código Java™. Posee las siguientes características:

  • Integración con Eclipse
  • Auto corrección en la edición de reglas
  • Asistentes de generación de código
  • Repositorio de interfaz única
  • Integración del control del código fuente
  • Detección de conflictos y redundancias
  • Fácil implementación

ILOG Rule Team Server: Entorno Web que permite que equipos de negocios distribuidos colaboren, creen, gestionen, validen e implementen reglas de negocios.

  • Rule Execution Server de ILOG JRules proporciona un entorno de ejecución robusto que cumple con J2SE y J2EE para la implementación y ejecución de reglas de negocios. Este servidor de ejecución de reglas incluye componentes para la invocación de reglas de negocios sincrónica, asincrónica y basada en servicios web, así como también una consola de administración Web. Está completamente integrado con Rule Studio y Rule Team Server de ILOG JRules para soportar la implementación de reglas de negocios tanto para desarrolladores como para usuarios de negocios.
  • ILOG JRules es un producto de la familia IBM WebSphere y ofrece amplias posibilidades de integración técnica con otros productos WebSphere como Process Server e Integration Developer. ILOG JRules permite a los usuarios de negocios crear y modificar reglas rápidamente para hacer frente a las necesidades de negocios dinámicas propias del personal de TI. Además, este producto ayuda a establecer la visibilidad, la capacidad de seguimiento y la calidad de las reglas de negocios en toda la empresa para que los gerentes de negocios puedan tomar mejores decisiones más rápido. Por estos motivos, ILOG JRules es la opción natural para la integración con productos IBM BPM para la prestación de servicios de políticas y decisiones en escenarios de procesos de negocios de clientes. La Figura 3 muestra un ejemplo en el que un proceso de negocios invoca a un servicio JRules en Process Server.
Figura 3. Ejemplo de integración de ILOG JRules con WebSphere Process Server
Ejemplo de integración de ILOG JRules con WebSphere Process Server

Este artículo se centra en la perspectiva de integración de ILOG JRules con Process Server y desarrolla la instalación y configuración, los diferentes aspectos de integración usando POJO, EJB, servicios web, JMS/MQ, y el monitoreo de servicios JRules usando CEI en Process Server.


Integración de ILOG JRules con WebSphere Process Server

Como Process Server se basa en una plataforma WebSphere Application Server y ILOG JRules cumple con J2EE, la integración de los componentes del tiempo de ejecución de ILOG JRules con Process Server es un proceso de integración de aplicaciones J2EE estándar. La Figura 4 muestra los componentes centrales del servidor de ejecución JRules luego de su implementación en un entorno J2EE.

Figura 4. Componentes centrales del servidor de ejecución JRules en un entorno J2EE
Componentes centrales del servidor de ejecución JRules en un entorno J2EE

JRules usa una base de datos para almacenar y gestionar el establecimiento y la aplicación de reglas. La fuente y la persistencia de datos proporcionan una solución JDBC para accedes a la base de datos usada por JRules.

La Unidad de ejecución (Execution Unit - XU) es un adaptador de recursos para la arquitectura de conectores Java EE (JCA 1.5). XU administra detalles de nivel inferior de la ejecución de conjuntos de reglas y proporciona acceso para gestionar sus recursos. XU puede ejecutarse independientemente del modelo de gestión. Además, la XU pone a disposición del modelo de gestión los datos de configuración y tiempo de ejecución e implementa los contratos JCA entre el servidor de aplicaciones y el motor de reglas. El servidor de aplicaciones o el cliente de aplicaciones usan a XU para conectarse con el motor de reglas.

Los componentes de ejecución son elementos que autorizan la ejecución de reglas establecidas por XU. Los componentes de ejecución de Rule Execution Server permiten escribir código para interactuar con el modelo de Rule Execution Server sin establecer dependencias de ningún tipo en la implementación interna.

El módulo del cliente debe incrustar los componentes de ejecución de Rule Execution Server (jrules-res-session-<appserver>.jar) que se usarán para referenciar la XU.

La Figura 5 muestra la arquitectura de la integración de JRules con Process Server.

Figura 5. Arquitectura de la integración de JRules con WebSphere Process Server
Arquitectura de la integración de JRules con WebSphere Process Server

Para integrar el tiempo de ejecución de JRules en Process Server deberá seguir los siguientes pasos:

  1. Configure la fuente de datos para la fuente/persistencia de datos de JRules en Process Server. El nombre de JNDI de la fuente de datos debe ser jdbc/resdatasource, como muestra la Figura 6. De lo contrario, JRules no podrá conectarse correctamente con su base de datos.
    Figura 6. Creación de fuente de datos para JRules en WebSphere Process Server
    Creación de fuente de datos para JRules en WebSphere Process Server
  2. Implemente XU RAR en Process Server. XU es un adaptador de recursos proporcionado por JRules. Puede encontrarla en JRulesInstallDir\executionserver\applicationservers\WebSphere7\jrules-res-xu-WAS7.rar. El nombre de JNDI para las fábricas de conexiones XU J2C es eis/XUConnectionFactory. Para acceder a XU, otro componente de JRules podría referenciar este nombre de JNDI predeterminado (Figura 7).
    Figura 7. Implementación de XU como adaptador de recursos en WebSphere Process Server
    Implementación de XU como adaptador de recursos en WebSphere Process Server
  3. Implemente el EAR de gestión de ejecución en Process Server (Figura 8). El EAR de gestión de ejecución es una aplicación de gestión de JRules que cumple con J2EE y proporciona una consola de gestión para implementar, navegar, configurar y gestionar todas las aplicaciones de reglas implementadas en Rule Execution Server. Encuentre el EAR de gestión de ejecución en JRulesInstallDir\executionserver\applicationservers\WebSphere7\ jrules-res-management-WAS7.ear.
    Figura 8. Implementación del EAR de gestión de ejecución en WebSphere Process Server
    Implementación del EAR de gestión de ejecución en WebSphere Process Server
  4. Configure la seguridad del tiempo de ejecución JRules. El servidor de ejecución JRules define varios roles de seguridad para limitar el acceso a su MBean. WebSphere Application Server proporciona una infraestructura y una serie de mecanismos de seguridad para proteger los recursos administrativos y los recursos JEE sensibles. Para proteger el acceso a JRules, deberá activar la seguridad global en Process Server (Figura 9).
    Figura 9. Activación de seguridad global en WebSphere Process Server
    Activación de seguridad global en WebSphere Process Server
    En segundo lugar, deberá definir los siguientes tres grupos de usuarios de JRules (Figura 10):
    • resAdministrators
    • resDeployers
    • resMonitors
    Luego, defina los siguientes miembros para cada grupo de usuarios (Figura 11):
    • resAdmin
    • resDeployer
    • resMonitor
    Figura 10. Definición de grupos de usuarios de JRules en WebSphere Process Server
    Definición de grupos de usuarios de JRules en WebSphere Process Server
    Figura 11. Definición de usuarios de JRules en WebSphere Process Server
    Definición de usuarios de JRules en WebSphere Process Server
    Para que una aplicación logre acceder al MBeans del modelo de Rule Execution Server, ésta debe contar con ciertas credenciales de seguridad. Por lo tanto, deberá mapear los roles de seguridad definidos por el servidor de ejecución con los grupos de usuarios correspondientes (Figura 12).
    Figura 12. Mapeo de roles de seguridad del servidor de ejecución JRules
    Mapeo de roles de seguridad del servidor de ejecución JRules

Ya tenemos integrados los componentes básicos del tiempo de ejecución JRules en Process Server. Estos están listos para desarrollar e implementar la aplicación de reglas en JRules ejecutándose en Process Server. El proceso de negocios puede invocar al conjunto de reglas como nodo de servicio de decisiones a través de distintos enlaces.


Invocación de reglas de negocios desde dentro de un proceso de negocios

La Figura 13 muestra el modelo de invocación definido por JRules.

Figura 13. Modelo de invocación de JRules
Modelo de invocación de JRules

Basándose en XOM, modelo de objetos de ejecución definido en la aplicación de reglas, el cliente puede invocar al conjunto de reglas implementado en Rule Execution Server a través de diferentes métodos, como POJO, EJB (remoto o local), JMS, etc. Al mismo tiempo, JRules también proporciona un servicio de decisiones transparente para que el cliente pueda acceder al conjunto de reglas a través de un servicio web usando SOAP/HTTP. En este artículo, el cliente de JRules es el proceso de negocios implementado en Process Server. Por consiguiente, diferentes métodos de invocación corresponden a distintos componentes SCA en Process Server. La Tabla 1 resume varias invocaciones de JRules.

Tabla 1. Resumen de invocaciones de JRules a través de WebSphere Process Server
Método de invocaciónComponente SCALocal o remota
POJOSCA POJOSólo local
EJBSCA POJOLocal y remota
JMSImportación de enlace MQ JMSLocal y remota
servicio webImportación de enlace de servicio webLocal y remota

Las siguientes secciones describen cada método de invocación en detalle.

Invocación de servicio de reglas usando una sesión POJO

La invocación SCA POJO es muy eficiente porque no requiere de serialización o deserialización de parámetros de entrada y respuesta. Sin embargo, este método tiene la limitación de soportar únicamente la invocación local. Esto implica que es necesario que el servidor de ejecución JRules esté ubicado en la misma JVM que Process Server, donde reside el proceso de negocios llamante. La Figura 14 muestra el modelo de invocación de un conjunto de reglas usando el componente SCA POJO.

Figura 14. Invocación de JRules usando SCA POJO
Invocación de JRules usando SCA POJO

En este modelo, un componente SCA POJO invoca a las API proporcionadas porjrules-bres-session-WAS7.jar, el cual invoca a XU para que acceda al conjunto de reglas y devuelva el resultado al componente SCA POJO. El Listado 1 muestra un fragmento Java que invoca a JRules usando una sesión POJO.

Listado 1. Ejemplo de invocación de JRules usando SCA POJO
Map
inputParameters = new HashMap(); String strAMERICASPricing =
serialize(AMERICASPricingSdo, "http://AMERICAS_Pricing", "AMERICAS_Pricing");
inputParameters.put("AMERICASPricing", strAMERICASPricing); //Get the session
factory for a Java rulesession invocation IlrSessionFactory sessionFactory = new
IlrPOJOSessionFactory(); IlrSessionRequest request = sessionFactory.createRequest();
request.setRulesetPath(IlrPath.parsePath(rulesetPath));
request.getInputParameters().putAll(inputParameters); //create a stateless rule
session IlrStatelessSession ruleSession = sessionFactory.createStatelessSession();
IlrSessionResponse result = ruleSession.execute(request); Map outputParameters =
result.getOutputParameters(); String strOutAMERICASPricing = (String)
outputParameters.get ("AMERICASPricing"); DataObject response =
createResponse("http://com", "AMERICAS_Pricing_RuleProjectExecutionResult");
response.set("AMERICASPricing", deserialize
(strOutAMERICASPricing,"AMERICAS_Pricing"));

JRules porporciona el Decision Service Wizard (Asistente de servicio de decisiones) en Integration Developer para generar el componente SCA POJO automáticamente (Figura 15).

Figura 15. Uso de Decision Wizard para generar SCA POJO en WebSphere Integration Developer
Uso de Decision Wizard para generar SCA POJO en WebSphere Integration Developer

Invocación de reglas usando una sesión EJB

Puede acceder a los servicios de reglas implementados en ILOG JRules a través de una invocación de EJB, ya sea local o remota. La Figura 16 muestra el modelo de invocación de conjuntos de reglas usando enlaces EJB.

Figura 16. Invocación de JRules usando EJB
Invocación de JRules usando EJB

La Figura 16 muestra cómo la aplicación cliente invoca el servicio de reglas usando una sesión de reglas (IlrStatelessRuleSession o IlrStatefulRuleSession). En la sesión de reglas se invocará a IlrStatelessRuleSessionEJB o IlrStatefulRuleSessionEJB. IlrStatelessRuleSessionEJB y IlrStatefulRuleSessionEJB pueden residir en diferentes JVM de cliente. IlrStatelessRuleSessionEJB o IlrStatefulRuleSessionEJB invocarán al conjunto de reglas ejecutándose en XU a nivel local. En ILOG JRules, IlrStatelessRuleSession, IlrStatefulRuleSession, IlrStatelessRuleSessionEJB y IlrStatefulRuleSessionEJB forman parte del paquete jrules-res-session-WAS7.jar. En Process Server, el cliente será el escenario con ejecución en Process Server que invoque al servicio de reglas. El servidor será el servidor de aplicaciones en el que se encuentra el servidor de ejecución ILOG JRules.

El Listado 2 muestra un fragmento Java que invoca al servicio de reglas usando una sesión EJB.

Listado 2. Ejemplo de invocación de JRules usando una EJB
//Sets IN
and INOUT parameters. Map inputParameters = new HashMap(); String strCreditpricing =
serialize(creditpricingSdo,"http://creditpricing", "CreditPricing");
inputParameters.put("creditpricing", strCreditpricing); Properties properties = new
Properties(); properties.put(JAVA_NAMING_FACTORY_INITIAL, INITIAL_CONTEXT_FACTORY);
properties.put(JAVA_NAMING_PROVIDER_URL, ENGINE_URL); IlrSessionRequest request =
new IlrSessionRequest(rulesetPath);
request.getExecutionSettings().getInputParameters().setParameters (inputParameters);
//Get the provider for a Remote EJB IlrRuleSessionProvider rsProvider = new
IlrRuleSessionProviderFactory.Builder(
properties).setJNDINameOfRuleSessionStateless(JNDI_NAME).build(); //create a
stateless rule session IlrStatelessRuleSession ruleSession =
rsProvider.createStatelessRuleSession(); IlrSessionResponse result =
ruleSession.executeRules(request); ilog.rules.bres.session.IlrSessionParameters
outputParameters = result .getExecutionResult().getOutputParameters(); String
strOutCreditpricing = (String) outputParameters.getObjectValue ("creditpricing");
DataObject response = createResponse("http://com", "PricingrulesExecutionResult");
response.set("creditpricing",
deserialize(strOutCreditpricing,"CreditPricing"));

JRules proporciona el Decision Service Wizard en Integration Developer para generar el componente SCA POJO y la EJB invoca el código automáticamente (Figura 17).

Figura 17. Uso de Decision Wizard para generar SCA POJO en WebSphere Integration Developer
Uso de Decision Wizard para generar SCA POJO en WebSphere Integration Developer

Invocación de reglas usando un servicio web

Puede acceder al servicio de reglas desde dentro de Process Server a través de un servicio web. ILOG JRules usa el servicio de decisiones transparentes para brindar acceso al conjunto de reglas a través de servicios web. JRules proporciona los dos tipos de servicios de decisiones transparentes:

  • Servicio de decisiones transparentes alojado: Se trata básicamente de un conjunto de reglas implementado como servidor Web. Se instala en el mismo servidor de aplicaciones donde se encuentra Rule Execution Server y luego se integra con éste.
  • Servicio de decisiones transparentes monitoreado: Es generado por Rule Studio y reside en el mismo servidor de aplicaciones donde se encuentra Rule Execution Server, pero no se integra con éste. El servicio de decisiones se mantiene independiente de Rule Execution Server pero accede a él para ejecutar las reglas.

En el caso del servicio de decisiones transparentes monitoreado, los únicos servidores de aplicaciones soportados son JBoss y Tomcat. Por lo tanto, para la integración con Process Server se usará únicamente el servicio de decisiones transparentes alojado. La Figura 18 muestra cómo usar el servicio de decisiones transparentes alojado para acceder al servicio JRules.

Figura 18. Invocación de JRules usando un servicio web
Invocación de JRules usando un servicio web

Para usar un servicio web para acceder al conjunto de reglas, se implementa el servicio de decisiones transparentes alojado (jrules-res-htds-WAS7.ear) en el mismo Process Server donde se encuentra el Rule Execution Server. El host puede ser o bien el mismo del proceso de negocios llamante u otro.

Figura 19. Implementación de servicio de decisiones transparentes en WebSphere Process Server
Implementación de servicio de decisiones transparentes en WebSphere Process Server

Primero, para invocar el conjunto de reglas usando un servicio web, deberá exportar el WSDL de la aplicación de reglas objetivo desde la consola de Rule Execution Server (Figura 20).

Figura 20. Exportación de WSDL desde la consola de Rule Execution Server
Exportación de WSDL desde la consola de Rule Execution Server

Luego, en Integration Developer, importe el archivo WSDL al módulo SCA que invocará el servicio de reglas y especificará la interfaz definida en el archivo WSDL para la importación de enlace de servicio web.

Invocación de reglas usando JMS

Un proceso de negocios puede invocar el conjunto de reglas que se está ejecutando en JRules asincrónicamente usando los estándares de mensajería de Java Message Service (JMS). La Figura 21 muestra el modelo de invocación de un conjunto de reglas usando JMS.

Figura 21. Invocación de servicio JRules usando JMS
Invocación de servicio JRules usando JMS

Como muestra la Figura 21, la aplicación cliente invoca servicios JRules usando los estándares de mensajería de JMS. La aplicación envía mensajes JMS a un destino de mensajes. El bean de reglas impulsado por mensajes (MDB) escucha a este destino para obtener los mensajes recibidos. El MDB (o MDB de JRules) es un bean empresarial que funciona como escucha de mensajes. Dentro del bean, IlrRuleExecutionBean es el MDB de cola y IlrRuleExecutionTopicEJB es el MDB de tema (Listado 3). Puede asignar el destino del bean de reglas impulsado por mensajes usando recursos del servidor de aplicaciones.

Listado 3. MDB de cola y MDB de tema en ILOG JRules
<message-driven>
<ejb-name>IlrRuleExecutionEJB</ejb-name>
<ejb-class>ILOG.rules.bres.mdb.ejb.IlrRuleExecutionBean</ejb-class>
... </message-driven> <message-driven>
<ejb-name>IlrRuleExecutionTopicEJB</ejb-name>
<ejb-class>ILOG.rules.bres.mdb.ejb.IlrRuleExecutionBean</ejb-class>
... </message-driven>

Cuando llega un mensaje JMS, el contenedor EJB llama al método onMessage de IlrRuleExecutionBean o IlrRuleExecutionTopicEJB de MDB. IlrRuleExecutionBean o IlrRuleExecutionTopicEJB pueden residir a nivel local en la aplicación cliente o a nivel remoto. Por su parte, el MDB llama a los conjuntos de reglas que se están ejecutando en XU. La invocación real del motor de reglas se delega a una sesión de reglas simple.

Luego del procesamiento del motor de reglas, el MDB se ocupa de enviar mensajes de respuesta (de haberlos). Éste asienta el resultado en el destino de respuesta JMS especificado en el encabezado JMSReplyTo.

En JRules, las clases de implementación de IlrRuleExecutionBean y IlrRuleExecutionTopicEJB de MDB en WebSphere Application Server están incluidas en el paquete jrules-res-mdb-WAS7.jar.

Deberá empaquetar jrules-res-mdb-WAS7.jar en un archivo EAR dummy e implementarlo en el mismo Process Server donde se encuentra XU al usar JMS para invocar el conjunto de reglas. En el extremo del MDB de JRules, deberá definir los siguientes recursos:

  • Configure las siguientes fábricas de conexiones MQ:
    • Fábrica de conexiones de cola con el nombre JNDI jms/BRESQueueConnectionFactory.
    • Fábrica de conexiones de tema con el nombre JNDI jms/BRESTopicConnectionFactory.
  • Configure las siguientes definiciones de cola y tema:
    • Cree una definición de cola para que el MDB de JRules reciba un mensaje. Aquí usamos el nombre JNDI jms/BRESQueueIn como ejemplo.
    • Cree una definición de cola para que el MDB de JRules responda a un mensaje. Aquí usamos el nombre JNDI jms/BRESQueueOut como ejemplo.
    Si desea usar el tema, deberá establecer las definiciones de tema correspondientes.
  • Configure un puerto de escucha de mensajes o una especificación de activación para que MDB de JRules se active cuando exista un mensaje en la cola jms/BRESQueueIn.

En el extremo del cliente, puede usar una importación con enlace JMS para enviar y recibir un mensaje JMS desde y hacia el MDB de JRules. Así como el MDB de JRules espera un java.util.Map como carga útil de un mensaje de objetos JMS, la aplicación cliente SCA en Process Server espera un objeto de negocios. Deberá crear un enlace de datos JMS personalizado que mapee java.util.Map con la representación de objetos de negocios de Process Server. El Listado 4 muestra cómo usar un enlace de datos personalizado para construir un mapa entre el objeto de negocios y java.util.HashMap.

Listado 4. Ejemplo de uso de enlace de datos personalizados en importación JMS para invocar JRules
public class CustomerApplicationDataBinding
implements JMSDataBinding { public int getMessageType() { return
JMSDataBinding.OBJECT_MESSAGE; } public void write(Message message) throws
JMSException { try { ObjectMessage requestMessage = (ObjectMessage) message; //Get
the data object DataObject customerApplicationSdo = getDataObject(); // Create the
java.util.HashMap HashMap inputParameters = new HashMap(); // CustApplicationObj is
the custom object defined in the parameters of rule application //
convertSDOToCustApplicationObj converts the incoming SDO to CustApplicationObj
CustApplicationObj customerApplicationObj
=convertSDOToCustApplicationObj(customerApplicationSdo);
inputParameters.put("CustomerApplicationObj", customerApplicationObj); // Set the
payload of the JMS Object Message requestMessage.setObject(inputParameters); String
rulesetPath = "/" + RULEAPP_NAME + "/" + RULESET_NAME_EMEARULE; //Set the JMS
message header properties.
requestMessage.setStringProperty("ILOG_rules_bres_mdb_rulesetPath", rulesetPath);
requestMessage.setStringProperty("ILOG_rules_bres_mdb_status", "request"); } catch
(DataBindingException e) { throw new JMSException(e.getLocalizedMessage()); } }
public void read(Message message) throws JMSException { //Get the payload of the JMS
Object message ObjectMessage responseMessage = (ObjectMessage) message; HashMap
parameters = (HashMap) responseMessage.getObject(); CustApplicationObj
outCustomerApplicationObj = (CustApplicationObj)
parameters.get("CustomerApplicationObj")); // convertCustApplicationObjToSDO
converts the rule application parameter to SDO DataObject dobject =
convertCustApplicationObjToSDO(outCustomerApplicationObj); try { // Set the data
object setDataObject(dobject); } catch (DataBindingException e) { throw new
JMSException(e.getLocalizedMessage()); } } }

Monitorero de servicios JRules en WebSphere Process Server

En Process Server, puede monitorear el proceso de negocios basándose en CEI. Todos los eventos con formato Common Base Event (CBE) activados se emiten en el servidor CEI y se almacenan con fines de monitoreo. Puede usar el navegador CBE incluido en Process Server para verificar los eventos generados durante la ejecución del proceso de negocios. También puede usar WebSphere Business Monitor para monitorear las medidas específicas como métricas y KPI del proceso de negocios.

Los servicios de reglas en ILOG JRules también pueden enviar eventos CBE al marco CEI, el cual proporciona un mecanismo de monitoreo coherente con Process Server. Estos eventos CBE brindan pistas de auditoría de los servicios JRules detalladas e integradas.

JRules proporciona API para emitir eventos CEI. Para simplificar la operación, JRules posee un componente denominado ILOG JRules CEI Event Source (Fuente de eventos CEI de ILOG JRules) para posibilitar la integración con Process Server. Este componente incluye el módulo CEIEventBOM que define la marca de orden de bytes (BOM) del evento CEI y encapsula API para emitir eventos CEI. El proyecto de reglas puede referenciar al módulo CEIEventBOM y definir una variable de tipo ilog.connector.ibm.runtime.EventContainer para emitir eventos CEI en Process Server. Ver los ejemplos de la Figura 22 y la Figura 23.

Figura 22. Referenciación de módulo CEIEventBOM para emitir eventos CEI
Referenciación de módulo CEIEventBOM para emitir eventos CEI
Figura 23. Definición de una variable de tipo EventContainer para emitir eventos CEI
Definición de una variable de tipo EventContainer para emitir eventos CEI

Luego puede agregar un código que indique hacia donde se deben emitir los eventos CEI, como muestra la Figura 24.

Figura 24. Agregado de código para emitir eventos CEI
Agregado de código para emitir eventos CEI

Luego de invocar el conjunto de reglas, puede usar el navegador CBE para verificar los eventos (Figura 25). Allí podrá visualizar las pistas de auditoría de la invocación de reglas y obtener información útil acerca de, por ejemplo, las reglas activadas y el flujo de reglas ejecutadas.

Figura 25. Uso de navegador CBE para buscar eventos generados por las reglas
Uso de navegador CBE para buscar eventos generados por las reglas

Conclusión

Este artículo proporcionó una visión general de la integración entre ILOG JRules y WebSphere Process Server. Se mostró cómo invocar un servicio de reglas desde un proceso de negocios usando distintas metodologías como POJO, EJB, servicios web y JMS/MQ. Por último, este artículo explicó cómo monitorear servicios JRules a través de CEI en WebSphere Process Server.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=482399
ArticleTitle=Visión general de integración entre ILOG JRules y WebSphere Process Server
publish-date=08012011