Integración de Tivoli Netcool Impact y WebSphere ILOG BRMS

Escenarios y su materialización

Este artículo describe los escenarios de negocios donde resulta conveniente usar Tivoli Netcool/Impact y WebSphere ILOG Business Rule Managements System (JRules) en conjunto y se ocupa de cómo integrar los productos de manera rápida para materializar una solución para estos escenarios.

Sudhakar Chellam, Senior Software Engineer , IBM

Sudhakar Chellam es Senior Software Engineer en el equipo del producto Tivoli Netcool/Impact. Como parte del equipo de desarrollo, trabajó en implementación de notificaciones de servicios web, y en implementación y soporte de Listener para Web Services Data Source Adapter. Antes, Sudhakar fue el Chief Programmer del IBM Tivoli Composite Application Manager para el producto SOA.



Duncan Clark, IT Architect, IBM

Duncan Clark es IT Architect del equipo ILOG Synergies y se especializa en integraciones entre ILOG y productos Tivoli, y sus aplicaciones en soluciones centradas en la industria. Antes, Duncan estuvo a cargo de los aspectos de Gobernabilidad y Política de WebSphere Service Registry and Repository.



05-08-2011

Resumen ejecutivo

Este artículo describe las situaciones (escenarios) de negocios donde resulta conveniente usar Tivoli Netcool/Impact y WebSphere ILOG Business Rule Managements System (JRules) en conjunto y se ocupa de cómo integrar los productos de manera rápida para materializar una solución para estos escenarios.

Las soluciones de negocios modernas involucran el procesamiento de grandes cantidades de eventos que cubren tanto eventos de negocios como de infraestructura como se muestra en este artículo.

Figura 1. Necesidades en la toma de decisiones de negocios e infraestructura
Necesidades en la toma de decisiones de negocios e infraestructura

Los usuarios de negocios necesitan detectar y responder a patrones de negocios sobre los que se pueda actuar con el tiempo suficiente como para afectar la ejecución de los negocios. Las soluciones deben correlacionar patrones complejos en eventos de negocios a partir de recursos y sistemas instrumentados con el fin de tomar las decisiones de negocios necesarias para gestionar la actividad y el desempeño comercial.

Los usuarios de Operaciones de TI deben comprender y asegurar el buen estado de los servicios, la infraestructura y los procesos críticos. Las soluciones deben correlacionar los eventos relativos a la infraestructura en todos los recursos y sistemas instrumentados, de manera que se pueda comprender el impacto sobre el negocio y se puedan tomar las decisiones correspondientes para gestionar el buen estado de los servicios, los procesos y la infraestructura.

Sin embargo, estos dominios no son independientes, por lo cual en estas soluciones modernas ambos roles de usuarios deben comprender de qué manera los patrones de negocios procesables se afectan entre sí, y a la condición de infraestructura, procesos y servicios complejos.

IBM ofrece los productos WebSphere Business Process Management para dar soporte a los usuarios de negocios y los productos Tivoli Service Management para dar soporte a las Operaciones de TI como se muestra a continuación.

Figura 2. Soporte de productos para usuarios de negocios e infraestructura
Soporte de productos para usuarios de negocios e infraestructura

Esto demuestra la necesidad de integración entre estas familias de productos para dar soporte al insight y a la toma de decisiones en común. Este artículo se centra en cómo lograr decisiones compartidas entre las áreas de negocios e infraestructura usando WebSphere ILOG Business Rule Management System y Tivoli Netcool Impact, como se ilustra continuación.

Figura 3. Generalidades sobre la integración de Netcool Impact y ILOG BRMS
Generalidades sobre la integración de Netcool Impact y ILOG BRMS

La Sección 1 ofrece generalidades sobre Tivoli Netcool Impact y WebSphere ILOG BRMS (JRules) que permiten a los lectores familiarizarse con los correspondientes roles de productos y proposiciones de negocios.

Se describen a continuación dos escenarios de comercio clave.

Figura 4. Escenario 1: El evento de TI influye sobre la decisión de negocios
Escenario 1: El evento de TI influye sobre la decisión de negocios

En este primer escenario, se produce un evento de TI, (centro de datos o capacidad del sistema de comercio offline). En este caso, el rol de Operaciones de TI debe decidir si esto tiene un impacto significativo sobre el negocio y, en ese caso, debe informar al negocio para que se puedan tomar las medidas necesarias. Sin embargo, quien debe decidir si el evento de TI es significativo para las necesidades del negocio es el Usuario de Negocios o reglas que automatizan estas decisiones. Este escenario se describe en la sección 2.2, mientras que las secciones 3.1 a 3.4 analizan detalladamente de qué manera se logra.

Figura 5. Escenario 2: El evento de negocios requiere una respuesta de Infraestructura
Escenario 2: El evento de negocios requiere una respuesta de Infraestructura

En este segundo escenario, el usuario de negocios se percata de situaciones y necesita conocer información del dominio de Operaciones de TI para poder tomar esas decisiones de manera eficaz. En el ejemplo la lentitud en los tiempos de cumplimiento puede deberse a una cantidad de motives de TI, como por ejemplo la caída de los centros de datos o el haber llegado al límite de capacidad en las aplicaciones mismas. Sin embargo, el riesgo se basa en la duración probable de esta situación, de manera que se debe solicitar esta información antes de tomar la decisión. Si en Operaciones de TI no se conoce la situación del negocio, la comunicación de la misma puede también dar origen a una investigación y a la rectificación del problema. Este escenario se describe en más detalle en la sección 2.3 y la integración se describe en la sección 3.5.

El artículo finaliza hacienda un recorrido por los escenarios en la sección 4 con el fin de mostrar cómo se manifiesta realmente la integración.


Introducción

Generalidades

Este artículo describe las situaciones (escenarios) de negocios donde resulta conveniente usar Tivoli Netcool/Impact y WebSphere ILOG Business Rule Managements System (JRules) en conjunto y se ocupa de cómo integrar los productos de manera rápida para materializar una solución para estos escenarios.

Las generalidades de la sección brindan una descripción de Tivoli Netcool/Impact y WebSphere ILOG BRMS (JRules) que permite a los lectores familiarizarse con los respectivos roles y proposiciones de negocios de los productos.

En la siguiente sección se discute un conjunto de escenarios que muestran el valor que tiene para el negocio la integración de Impact y JRules para permitir una mejor comunicación entre los usuarios de Operaciones de TI y del negocio.

También se ofrece un análisis técnico de todos los pasos necesarios para integrar ambos productos y materializar los escenarios, que brinda instantáneas de los productos a medida que avanza la integración e incluye orientación sobre el desarrollo y la verificación de la integración.

Luego se ofrecen generalidades sobre el funcionamiento en la sección final, y el documento finaliza con algunas referencias de relevancia para los integradores.

Generalidades sobre Netcool / Impact

Netcool/Impact ofrece funcionalidad para realizar la gestión de eventos de TI y la integración de datos de TI. Impact brinda un modo de integrar los datos de diferentes fuentes, como bases de datos, LDAP y fuentes de terceros. Consulte la Figura 3 para ver la arquitectura simple de Impact.

Tivoli Netcool/Impact brinda un conjunto de componentes de servidores interrelacionados y ejecutables. Estos componentes son:

  • Impact Server
  • GUI Server

Netcool/Impact Server

El Netcool/Impact Server es el componente de software principal del sistema. Este componente es responsable de la funcionalidad central de Netcool/Impact, incluyendo la gestión del modelo de datos de Netcool/Impact, los servicios que se ejecutan y las políticas que se aplican. Según el uso que se le dé al producto, usted puede ejecutar una única instancia del Netcool/Impact Server o ejecutar múltiples instancias como parte de un cluster de servidores. La mayoría de las tareas que usted realiza con Netcool/Impact exigen que trabaje con este componente del servidor.

Netcool GUI Server

El Netcool GUI Server es el componente responsable de alojar y atender a la GUI de Netcool/Impact. Por lo general, usted cuenta con una única instalación del GUI server para todos los productos Netcool compatibles que se ejecutan en su entorno.

Casos de uso de Netcool/Impact

Usted puede usar Netcool/Impact en una amplia variedad de modos, según las necesidades de su entorno. Una manera de determinar qué es lo que usted puede hacer con Netcool/Impact es analizar sus características centrales y ver de qué manera puede armar una solución que amplíe el valor de su instalación Netcool. Otra manera consiste en observar las soluciones típicas implementadas por otros usuarios de Netcool para ver de qué modo las puede adaptar para el uso en su entorno. Por último, también puede examinar el flujo de trabajo de su entorno de red y ver cuáles son las partes del proceso que pueden mejorar con Netcool/Impact.

Figura 6. Casos de uso de Netcool Impact
Casos de uso de Netcool Impact

Características centrales de Netcool/Impact

Como se mencionara anteriormente, una manera de determinar qué es lo que usted puede hacer con Netcool/Impact consiste en analizar sus características centrales y ver de qué manera las puede hacer funcionar en su entorno. Las siguientes secciones se ocupan de algunas de las características más importantes de Netcool/Impact, y de cómo se relacionan con la gestión de eventos en su totalidad y con la suite de productos Netcool en particular.

Las características centrales de Netcool/Impact son:

  • Automatización
  • Acceso al origen de los eventos
  • Acceso a los datos
  • Integración con aplicaciones de terceros
  • Acciones predefinidas

Automatización

En un sentido general, la automatización es la característica más importante de Netcool/Impact. Netcool/Impact le permite automatizar las tareas de gestión de eventos que de otro modo debería realizar en forma manual que no podría llevar a cabo en absoluto. Estas tareas incluyen el monitoreo de eventos, el enriquecimiento de eventos, y la notificación sobre eventos. La automatización, sin embargo, constituye realmente la base de las tareas de Netcool/Impact. La automatización es el acto de establecer una tarea de manera que se realice automáticamente en determinados momentos o cuando se cumplen determinadas condiciones.

Al igual que una línea de montaje, el entorno de operaciones en red puede beneficiarse de la automatización de ciertos procesos. Por ejemplo, tareas tales como la notificación a técnicos o administradores de sistemas cuando una alerta alcanza un cierto nivel de gravedad, o la actualización de un evento para que incluya datos de negocios relacionados, pueden requerir tiempo y esfuerzo por parte de uno o más operadores de red.

Este ejemplo se traduce en un entorno de gestión de eventos que resulta menos costoso que uno manual, además de tener menos probabilidades de error. El marco que ofrece Netcool/Impact para la automatización consiste en el motor de políticas, el lenguaje de scripting de políticas y varios disparadores que se pueden usar para ″programar″ a Netcool/Impact para que inicie las políticas en base a distintas condiciones. El motor de políticas es una característica de Netcool/Impact que lleva a cabo las tareas que usted desea automatizar. Estas tareas se especifican en el lenguaje de scripting de políticas, que es un lenguaje de programación similar a C/C++ y Java en cuanto a su sintaxis.

Acceso a los eventos

Después de la automatización, el acceso a los eventos constituye la segunda característica más importante de Netcool/Impact. El acceso a los eventos es la característica que permite que Netcool/Impact use el flujo de eventos que pasa desde los detectores y los monitores de Netcool al Netcool/OMNIbus ObjectServer. Esta característica es una parte esencial de la mayoría de las implementaciones del producto.

Para poder ver cómo y por qué tiene importancia el acceso a los eventos, usted debe comprender en primer lugar el flujo de eventos de Netcool y cómo se genera el mismo. El flujo de eventos de Netcool es el flujo de alertas que van desde los detectores y los monitores de Netcool hasta ObjectServer. Cada alerta representa cierto estado o actividad en la red y se puede originar en cualquiera de los cientos de tipos diferentes de sistemas, dispositivos o aplicaciones. Por lo general, las alertas están diseñadas para informar a los operadores de red que se ha producido una condición de falla en algún lugar del entorno. También se pueden usar para comunicar otros tipos de estados o de información sobre eventos.

En sí mismas, las alertas son generadas por componentes de software denominados detectores y monitores, que vigilan los sistemas, dispositivos o aplicaciones y generan alertas cuando se producen diversas condiciones. Después de que los detectores y monitores generan las alertas, las mismas son enviadas al ObjectServer, donde pueden ser visualizadas por los operadores de red a través de la lista de eventos de Netcool/OMNIbus.

Como se mencionara en la sección anterior, el entorno de gestión de red se beneficia con las tareas de gestión automática de eventos. Esta automatización depende de la capacidad de Netcool/Impact para hacer uso del flujo de eventos de Netcool. El marco que ofrece Netcool/Impact para acceder a los eventos consta de tres características: el event reader (lector de eventos), el event listener (oyente de eventos) y el event processor (procesador de eventos). Las mismas son servicios ejecutables que usted puede controlar dentro de Netcool/Impact.

El OMNIbus event reader funciona monitoreando una instancia del ObjectServer. Cuando descubre eventos nuevos o actualizados, o descubre que un evento ha sido eliminado, toma el evento y lo devuelve a Netcool/Impact para su procesamiento.

De manera similar, el event listener monitorea otras fuentes de eventos que no sean ObjectServer, como por ejemplo las bases de datos SQL. Al igual que el event reader, toma los eventos nuevos o actualizados cuando los descubre y los vuelve a colocar en Netcool/Impact.

El event processor es responsable de lo que sucede después de que los eventos han sido recuperados. Cuando usted configura un event reader o un event listener, define una o más políticas que se deberán ejecutar cuando el evento corresponde a ciertos criterios especificados. Como se indicó en la sección anterior, una política es un conjunto de instrucciones para Netcool/Impact que especifica las tareas que usted desea automatizar. Cuando se acopla al event reader o al event listener, usted puede usar una política para especificar el conjunto de tareas que desea que Netcool/Impact realice de manera automática cuando aparecen ciertos tipos de alertas en el ObjectServer o aparecen otros eventos en otras fuentes de eventos.

Esta combinación de acceso a los eventos y funcionalidad de automatización le permite crear una amplia variedad de soluciones para la gestión de eventos. Estas soluciones incluyen el enriquecimiento de eventos, eventos X en momentos Y, la notificación sobre eventos, y las puertas de enlace a los eventos, como se describe posteriormente en este capítulo.

Acceso a los datos

Al igual que la automatización y el acceso a los eventos, el acceso a los datos también es una característica importante de Netcool/Impact. El acceso a los datos es la característica que permite a Netcool/Impact conectarse con fuentes de datos externas, como por ejemplo bases de datos SQL y servidores LDAP.

Para poder comprender cómo es importante esta característica, piense en todas las maneras en que usa datos externos a Netcool/OMNIbus en su entorno de gestión de red. Quizás cuente con una base de datos que contiene información de inventario en red y otra base de datos que contiene información sobre facturación y atención al cliente. Además, probablemente tenga un directorio de LDAP que puede usar para almacenar información sobre el personal de la empresa.

En un entorno sin Netcool/Impact, es posible que los operadores de red sean responsables de recuperar los datos manualmente desde una o más de estas fuentes de datos y de usar esta información para deducir la importancia de los eventos o decidir cómo manejarlos. Con Netcool/Impact, usted puede integrar este tipo de datos directamente en alertas al nivel de ObjectServer o puede usar estos datos para realizar diversos tipos de análisis sobre la gravedad o la relevancia de las alertas individuales.

El mecanismo para acceder a los datos que usa Netcool/Impact consiste en adaptadores de fuentes de datos (Data Source Adaptors - DSA) y modelos de datos de Netcool/Impact. Al nivel de los componentes de software, los DSA brindan el medio para que Netcool/Impact se conecte a una amplia variedad de bases de datos SQL, servidores LDAP, y otras fuentes de datos. Al nivel de las soluciones, el modelo de datos es una representación abstracta de los datos de su entorno. Netcool/Impact usa el modelo de datos dentro de políticas al recuperar, agregar, actualizar y eliminar datos de las fuentes de datos.

Integración con terceros

La capacidad de integración con aplicaciones de terceros es otra importante característica de Tivoli Netcool/Impact. En numerosos entornos de operaciones en red, usted cuenta con sistemas implementados que han sido creados por más de un proveedor de sistemas. Por ejemplo, además de la suite de productos Netcool, quizás tenga aplicaciones independientes de terceros para la gestión de inventario en red, facturación, rastreo de problemas, atención al cliente, y mesa de ayuda.

Tivoli Netcool/Impact ofrece interfaces para una amplia variedad de estas aplicaciones de terceros, incluyendo GE Smallworld, Portal Infranet, y TIBCO TIB/Rendezvous. Tivoli Netcool/Impact puede conectarse con una amplia variedad de otras aplicaciones estableciendo interfaces directas con sus bases de datos subyacentes.

Generalidades sobre ILOG / JRules

IBM WebSphere ILOG Business Rule Management System (JRules) brinda soporte para la autoría, verificación, simulación, implementación, ejecución y gestión de reglas de negocios que dan soporte a usuarios de negocios y a usuarios técnicos.

Los usuarios técnicos como por ejemplo los desarrolladores y el personal de Operaciones de TI deberán definir la estructura de las aplicaciones y las interfaces usadas para invocar los sistemas de reglas. Esto, a su vez, definirá el vocabulario que emplearán los Usuarios de Negocios para expresar sus requerimientos y políticas para lo importante del negocio. De este modo, pueden cambiar rápidamente las reglas y el comportamiento de las aplicaciones del negocio para responder a las cambiantes condiciones del mercado.

En la sección anterior, vimos cómo Tivoli Netcool/Impact puede monitorear las alertas desde una amplia variedad de detectores y sistemas y cómo ayuda a segmentar esos eventos usando mecanismos de acceso a los datos. Este artículo le mostrará de qué manera se puede usar JRules em conjunto con Netcool/Impact para permitir que los Usuarios de Negocios definan (y mantengan) reglas que agregan información sobre la perspectiva del negocio al procesamiento de eventos de TI.

Arquitectura de WebSphere ILOG Business Rule Management System

Los componentes de BRMS y su soporte para diversos soles se ilustran en el diagrama que se muestra a continuación.

Figura 7. Arquitectura del sistema ILOG BRMS
Arquitectura del sistema ILOG BRMS

A continuación se describen los componentes:

  • Rule Studio: Entorno de desarrollo integrado (ODE por su denominación en ingles) basado en Eclipse para desarrolladores y usuarios técnicos que dan soporte al desarrollo y la depuración de la Aplicación de Reglas.
  • Rule Team Server: Servidor de gestión de reglas basado en Internet que brinda a los usuarios de negocios una forma de autoría, gestión, validación e implementación de reglas de negocios que determinan el comportamiento de la Aplicación de Reglas. Rule Team Server brinda también acceso a un Rule Repository (Repositorio de reglas) compartido que permite que las reglas sean gestionadas de manera central.
  • Rule Execution Server: Entorno de ejecución de reglas compatible con J2SE o J2EE que puede ser llamado por Business Applications para que ejecute las reglas usando invocaciones sincrónicas, asincrónicas o basadas en el servicio web.
  • Decision Validation Services (DVS): Entorno integrado para la prueba, la verificación de la corrección de las reglas y la simulación de cambios en las políticas de negocios.

Arquitectura de las aplicaciones de reglas de negocios

Para poder usar reglas de negocios en un contexto de aplicaciones, los lectores deben comprender la terminología y la arquitectura de una Aplicación de Reglas y de qué manera es invocada por las aplicaciones de negocios. La arquitectura de una Aplicación de Reglas se muestra en la Figura que aparece a continuación. Cada uno de estos conceptos será desarrollado en el análisis de la sección siguiente.

Figura 8. Arquitectura de la Aplicación de Reglas de negocios
Arquitectura de la Aplicación de Reglas de negocios

La Aplicación de Negocios invoca la Aplicación de Reglas mediante una cantidad de mecanismos de Invocación de Reglas soportados. Este documento se centrará en el enfoque del Servicio de Decisiones para la invocación de reglas. La Aplicación de Negocios tundra también un Modelo de Información que usa para representar a los objetos que serán analizados por las reglas. Cada uno de ellos puede estar representados en Java o en XML como un esquema, y se denominan en conjunto Execution Object Models (XOM).

El Rule Execution Server aloja la Aplicación de Reglas y los Conjuntos de Reglas dentro de la misma. Las reglas pueden ser implantadas o actualizadas desde Rule Studio (para los usuarios técnicos) o desde Rule Team Server para los usuarios de negocios. Los usuarios técnicos determinan que la Aplicación de Reglas contenga los Conjuntos de Reglas necesarios. Cada Conjunto de Reglas contiene un vocabulario o Business Object Model (BOM) que se usa para expresar las reglas que usan terminología o “verbalización” adecuada para los Usuarios de Negocios. Inicialmente, cada una de las entradas de BOM puede derivar de un XOM existente que se encuentre en uso en la Aplicación de Negocios. Los usuarios técnicos usan Rule Studio para definir estas entradas de BOM y la verbalización que estará disponible para los usuarios de negocios.

Los usuarios técnicos deben además identificar las situaciones (Invocaciones de Reglas) en las Aplicaciones de Negocios en las cuales sea necesario aplicar una regla. Cada Invocación de Reglas será mapeada a un flujo de reglas definido en el Conjunto de Reglas y por lo tanto en la Aplicación de Reglas). El Flujo de Reglas posee una firma definida conforme a parámetros que se toman del Modelo de Información (XOM) cuando es llamado por la Aplicación de Negocios y mapeado al BOM al ser procesado por las Reglas. Cuando se llama a un flujo de reglas, es posible configurar para su ejecución una secuencia de paquetes de reglas y/o una regla. Si se inserta un paquete de reglas en un flujo, todas las reglas definidas dentro de dicho paquete podrán ser ejecutadas. Si se especifica una regla determinada, sólo se ejecutará esa regla en ese momento dentro del flujo.

Cada una de las reglas posee la estructura que se muestra a continuación.

Figura 9. Muestra de regla
Muestra de regla

La primera parte de la regla define las condiciones según las cuales se activa la regla.

  • La sección de definiciones consta de una cantidad de enunciados establecidos que definen nuevas variables según la información disponible para la regla (por lo general pasadas como parámetros al flujo en el cual se ejecuta). En algunos casos es posible que la información no se encuentre disponible, en cuyo caso la regla no se activará. Si la información se encuentra disponible, es POSIBLE que la regla se active siempre y cuando se cumplan las condiciones.
  • La sección de condiciones consiste en una cláusula “si”. Si esta cláusula evalúa a verdadero, se ejecuta la cláusula “entonces” en la sección acciones. Si la cláusula evalúa a falso, se ejecuta la cláusula “de lo contrario” (si está presente).
  • La sección acciones define las cláusulas a ejecutarse según el resultado de la cláusula de condiciones.

Observe que la verbalización y los tipos de todas las variables de la regla se definen en el BOM que, a su vez, se relaciona con los parámetros intercambiados con la Aplicación de negocios a través del XOM.


Escenarios

Esta sección identifica los escenarios de negocios clave que soporta la integración descripta en este artículo.

Uso de Impact para brindar acceso de datos de Operaciones de TI a un Sistema de Gestión de Reglas de Negocios

El principal escenario descripto en este documento es la provisión de datos de Operaciones de TI a los usuarios de negocios de modo que puedan gestionar mejor sus aplicaciones de negocios y dar orientación a Operaciones de TI sobre la mejor forma de soportarlas. En el escenario, Impact gestiona y aumenta esos datos de Operaciones de TI y brinda acceso a BRMS (JRules) para permitir que los usuarios de negocios expresen sus políticas y reglas.

Este documento describe dos patrones de acceso a datos, cada uno de los cuales se describe con más detalle en las siguientes secciones de escenarios.

  1. Inicio de Impact – En este caso, un Evento de TI inicia la llamada a BRMS y la subsiguiente aplicación de reglas de Usuarios de Negocios. Esto puede generar el agregado de información a los datos de Operaciones de TI que son relevantes para el Contexto de Negocios.
  2. Inicio de BRMS – En este caso, se produce un Evento de negocio o transacciones de negocios que deben acceder a los datos de Operaciones de TI para poder tomar una decisión de negocios válida.

Estos dos patrones requieren configuraciones similares en Impact si bien se dispone de una amplia variedad de opciones de integración, como se discutiera en la sección anterior.

En cualquiera de los escenarios de integración, el software BRMS puede usar los Impact Servers para acceder a distintos conjuntos de datos desde diferentes fuentes de datos durante el procesamiento de reglas. Es importante comprender cuáles son estas fuentes y cómo pueden exponerse a BRMS.

Durante la integración se debe seguir una serie de pasos:

  • Definir una fuente de datos en Impact Server. Esto determina de dónde provienen el evento y los datos de Operaciones de TI. Por lo general, será de tablas Netcool / OMNIbus aunque puede también incluir otras bases de datos y otros sistemas a los cuales se pueda acceder a través de Impact.
  • Definir un tipo de datos en Impact Server. Esto determina el vocabulario de negocios que se puede exponer a los usuarios de negocios en las Reglas.
  • Definir en Impact Server una política para ejecutar la consulta y devolver los datos. Esto se invoca cuando se debe acceder a los datos y proporciona la información en la forma correcta para la comunicación entre Impact y el BRMS.
  • Definir cuándo se produce el acceso a los datos. Aquí es donde los escenarios difieren:
    • El escenario de las políticas se invoca como respuesta a un Evento de TI que se puede configurar en Impact. La política entonces amplía los datos de las Operaciones de TI y los pasa al BRMS. La inormación que llega de vuelta desde el BRMS puede ser usada por Impact en el procesamiento.
    • El escenario de BRMS usa la interfaz de servicios web provista por Impact Server para ejecutar la política y recuperar los datos de las Operaciones de TI para usarlos en las reglas de negocios.

Impact Server, además, expone los datos a través de APIs Restful. La API Restful ofrece una manera de recuperar los datos de la fuente de datos y el tipo de datos configurados. En este escenario el usuario final no tiene que definir una política para recuperar los datos. Podrían usar su Cliente HTTP preferido para recuperar los datos. Los datos pueden ser devueltos con formato JSON o XML. Este patrón de acceso alternativo no ha sido incluido en el análisis de la siguiente sección.

Uso de BRMS para extender las políticas de Impact

Este escenario representa una situación en la cual un usuario de negocios tiene interés en alertas y eventos que se gestionan como parte del dominio de Operaciones de TI soportado por Tivoli Netcool/Impact. Este escenario se ilustra a continuación.

Figura 10. Escenario 1: El evento de TI influye sobre la decisión de negocios
Escenario 1: El evento de TI influye sobre la decisión de negocios

El usuario de negocios cuenta con una cantidad de Aplicaciones de Negocios para la compraventa de acciones. Las aplicaciones de negocios consisten en:

  • Una aplicación de compraventa de acciones que permite a los comerciantes solicitar ventas en nombre de sus clientes y
  • Un proceso de cumplimiento de transacciones que verdaderamente transfiere el dinero entre las partes.

Las aplicaciones de negocios son gestionadas por el usuario de negocios a través de reglas de negocios que imponen políticas sobre quien realiza las transacciones y aseguran el mantenimiento de carteras equilibradas. El Rule Execution Server (Servidor de Ejecución de Reglas) ha sido integrado a estas aplicaciones para permitir que los usuarios de negocios modifiquen estas reglas con rapidez según las necesidades del mercado,

  • Tivoli Netcool OMNIbus para recopilar e intercalar las alertas provenientes de la infraestructura de TI y las aplicaciones instaladas y
  • Netcool Impact para definir las políticas para la generación de informes, analizar causas raíz y dar soporte a las mesas de ayuda.

En este escenario el usuario de negocios debe saber si se derrumba un centro de datos para poder trabajar por fuera del mismo en caso que este hecho impacte en sus procesos de cumplimiento de transacciones. Los pasos que se deben tomar en este escenario se muestran en el diagrama con flechas de color rojo

  1. Un centro de datos queda fuera de línea y es monitoreado por un detector de Netcool OMNIbus lo cual genera una nueva alerta
  2. El Object Stores de Netcool OMNIbus canaliza la alerta a Impact donde la misma active políticas que indican qué acciones se deberán seguir.
  3. Se amplía la Política de Impact en este escenario para invocar un Servicio de Decisiones implantado en el Rule Execution Server. Además, agrega información de otras alertas asociadas con el centro de datos.
  4. Luego, el Rule Execution Server invoca las reglas definidas por el usuario de negocios. Esto define las dependencias de los procesos de Cumplimiento de Transacciones en cualquier centro de datos dado y, según la gravedad de la alerta, la regla determina si se debe elevar una nueva alerta para el Proceso de Cumplimiento de Transacciones.
  5. Si es necesaria una nueva alerta (o la actualización de una alerta existente), la misma se vuelve a enviar al Impact Server y luego la política agrega esta nueva información a las alertas y los procesos que soporta.
  6. Impact genera entonces la nueva alerta para el Proceso de Cumplimiento en el OMNIbus Store para que luego Operaciones de TI alerte al personal de soporte y a los usuarios del Proceso de Cumplimiento sobre el problema de negocios identificado.

Uso de un BRMS para mejorar la interoperabilidad entre las áreas de TI y Negocios

En este escenario el usuario de negocios no desea confiar en el soporte de Operaciones de TI para tomar nota de las alertas significativas, sino que desea automatizar las acciones como parte de sus aplicaciones de negocios. Este escenario se muestra a continuación.

Figura 11. Escenario 2: El evento de negocios requiere una respuesta de Infraestructura
Escenario 2: El evento de negocios requiere una respuesta de Infraestructura

En este escenario el usuario de negocios establece una regla para asegurar que no se acepte ninguna transacción si existe el riesgo de que no se pueda realizar. Los pasos que se toman en este escenario se muestran en el diagrama con flechas de color rojo.

  1. Se produce una transacción en la aplicación de compraventa y la aplicación de negocios invoca el Rule Execution Server que pasa los detalles del cliente y de las acciones que se compran o venden.
  2. Se invoca una cantidad de reglas de negocios que evalúan al cliente o a la orden de acciones. Además, se active una regla que busca alertas asociadas con el proceso de Cumplimiento de Transacciones asociado al intercambio. El intercambio se puede determinar a partir de la orden y se invoca un método definido en el BOM para consultar las alertas asociadas con el Proceso de Cumplimiento de Transacciones.
  3. El código de XOM invocado desde la llamada al método del BOM invoca una política de Impact que realiza una consulta.
  4. La política recupera todas las alertas para el Proceso de Cumplimiento de Transacciones (incluyendo cualquiera de las alertas generadas en el escenario 1). Esto puede incluir también cualquier alerta de desempeño provista directamente desde el proceso.
  5. En base a las alertas recibidas, la regla identifica que la transacción constituiría un riesgo inaceptable y pasa el resultado al Rule Execution Server.
  6. El Rule Execution Server luego vuelve a pasar el resultado de esta regla (y de cualquier otra regla activada) a la aplicación, que puede entonces relacionarlas nuevamente con el usuario indicando porqué la transacción no puede proseguir; existe un riesgo de que la transacción no se pueda completar dentro de un plazo aceptable.

Análisis de la integración

Esta sección explica cómo realizar la integración entre Impact y JRules para materializar los escenarios que se describen en la sección anterior. El objetivo es permitir que un usuario de negocios defina reglas que operan sobre los eventos de TI provistos desde Tivoli Netcool de tal manera que puedan indicar las situaciones de importancia para ellos. Esto permite luego que las Operaciones de TI reaccionen de mejor manera ante las necesidades de los usuarios de negocios y persistan y gestionen la información que los usuarios de negocios utilizan en sus aplicaciones de negocios. Esto se ilustra a continuación so el primer escenario que se muestra en color verde y con el Segundo escenario que se muestra en color azul.

Figura 12. Generalidades de la integración para materializar los escenarios
Generalidades de la integración para materializar los escenarios

El análisis consiste en instrucciones detalladas para el desarrollo y la depuración de una integración en funcionamiento entre Tivoli Netcool Impact y WebSphere ILOG BRMS. Se supone que el usuario ha instalado ambos productos. Las etapas que abarca el análisis son:

  • Diseño del modelo de información: Cómo implementar el vocabulario que se expone al usuario de negocios en las reglas en base al modelo de información disponible en Netcool.
  • Materialización del Servicio de Decisiones de JRules: Cómo implementar un servicio de decisiones (HTDS) que pueda ser llamado desde el DSA de servicios web de Netcool/Impact y permita a los usuarios de negocios expresar sus reglas en los términos del vocabulario definido.
  • Integración de Impact y Servicio de Decisiones de JRules: Cómo generar el DSA de servicios web y la política de Impact a partir del WSDL del Servicio de Decisiones de JRules e invocar el Servicio de Decisiones de JRules según los eventos de OMNIBus para obtener las respuestas correspondientes.
  • Desarrollo de políticas de Impact que invocan el Servicio de Decisiones de JRules: Ofrece ejemplos de los patrones comunes que se requieren en una política de Impact cuando se invoca un servicio de decisiones de JRules.
  • Llamadas de seguimiento a las aplicaciones de reglas en Impact: Describe de qué manera una aplicación de reglas de JRules puede invocar políticas de Impact a través de su Web Service Listener con el fin de obtener información sobre alertas que se pueda usar en sus reglas de negocios.

Diseño del modelo de información

Esta sección identifica de qué manera se selecciona y especifica el esquema que se usará en JRules para verbalizar las alertas y eventos de Netcool sobre los cuales las reglas van a razonar.

Estructura de tablas

El principal concepto usado dentro de Netcool OMNIbus e Impact es el de Alerta. Éste se encuentra identificado en la tabla alerts.status de una base de datos de ObjectServer, que posee más de 50 columnas o campos. Si bien todos ellos podrían definirse en el XOM, se decidió poner énfasis en unos pocos campos fundamentales que se usan de manera constante. Los mismos están resumidos en la tabla que aparece a continuación.

Tabla 1. Campos de la tabla Alert Status
Column Name (Nombre de la columna)Type (Tipo)Field Description and interpretation (Descripción e interpretación del campo)
Serial (Número de serie)Integer (Número entero)Es actualizado por OMNIbus y funciona como la única clave para cualquier alerta en un servidor particular. Se actualiza de manera automática.
Identifier (Identificador)String (Cadena)Usado para identificar una alerta particular y eliminar el duplicado de alertas que en realidad se refieren a la misma condición.
Node (Nodo)StringIdentifica la entidad gestionada de la cual se origina la alerta. Puede ser un nombre de host o dispositivo, un nombre de servicio u otro nombre que identifique de manera única a la entidad gestionada.
Manager (Administrador)StringNombre del detector que recogió y reenvió la alerta.
Agent (Agente)StringNombre del sub-manager dentro del detector.
AlertGroup (Grupo de alertas)StringNombre del tipo de falla indicada en la alerta.
AlertKey (Clave de alerta)StringNombre de la instancia de objeto gestionada dentro del nodo indicado por la alerta.
Severity (Gravedad)IntegerNumeración con enteros que indica la gravedad de una alerta. Se usa para dar color a las alertas en las visualizaciones de los eventos de Netcool.
0: Libre (Verde)
1: Indeterminada
2: Advertencia
3: Menor
4: Significativa
5: Crítica (Roja)
FirstOccurence (Primer episodio)IntegerMomento en segundos (a partir del 1 de enero de 1970) cuando se creó la alerta.
LastOccurence (Último episodio)IntegerMomento en segundos (a partir del 1 de enero de 1970) cuando se produjo la última actualización de la alerta en el detector
TypeIntegerNumeración con enteros que clasifica el tipo de alerta:
0: Tipo no configurado
1: Problema
2: Solución
........
11: Más grave
12: Menos grave
13: Información
Tally (Conteo)IntegerRecuento de la cantidad de actualizaciones y fusiones de la alerta producto de la eliminación de duplicados.

Para representar esta tabla en un XOM que se pueda usar en Impact y JRules, debemos decidir el tipo de XOM que se va a usar tomando en cuenta el mecanismo de invocación que se aplicará. Debido a que vamos a usar un Servicio de Decisiones, deberemos definir un Esquema XML para representar al XOM. Entonces se convierte en un XOM Dinámico.

Al diseñar el esquema, se deberá tomar en cuenta la cardinalidad de los campos ya que esto determinará si un valor es siempre necesario cuando se intercambian alertas entre Impact y JRules. En la tabla, los campos de calendario (FirstOccurence , Last Occurrence), Type y Serial son opcionales, mientras que todos los demás campos requerirán la presencia de un valor válido. Observe que para las cadenas, se acepta una "" o cadena vacía.

Esto genera un tipo de AlertType en el esquema OMNIBus.xsd como se muestra a continuación.

Figura 13. Representación esquemática de una alerta
Representación esquemática de una alerta

Además de considerar de qué manera representamos una alerta debemos tomar en cuenta cualquier otra información que pase a la Aplicación de Reglas para que se puedan evaluar las reglas, y qué información obtendremos de las reglas para determinar la respuesta.

Los datos de entrada a las reglas incluyen no sólo la alerta actualizada, sino cualquier otra alerta asociada con el mismo nodo. Por lo tanto, definimos una estructura AlertEventInput como se muestra a continuación.

Figura 14. Representación esquemática de un conjunto de Alertas para el procesamiento de Reglas
Representación esquemática de un conjunto de Alertas para el procesamiento de Reglas

De modo similar, lo que obtenemos en una selección de las alertas que se deben crear, actualizar o eliminar.

Figura 15. Representación esquemática de las Alertas que devuelve el procesamiento de Reglas
Representación esquemática de las Alertas que devuelve el procesamiento de Reglas

Para que el escenario siga siendo simple, estas alertas se brindan como únicas Alertas opcionales, pero en un escenario más sofisticado, una única invocación podría generar múltiples eventos de respuesta.

Cómo crear el proyecto de reglas

El paso siguiente consiste en crear el Proyecto de Reglas que define el conjunto de reglas. Cree en Rule Studio un nuevo Proyecto de Reglas denominado OMNIBusAlertDecisionService.

Figura 16. Creación de un nuevo Proyecto de Reglas
Creación de un nuevo Proyecto de Reglas

Seleccione Standard Rule Project y haga clic en Next.

Figura 17. Creación de un nuevo proyecto (Definir el nombre del proyecto)
Creación de un nuevo proyecto (Definir el nombre del proyecto)

Ingrese el nombre del proyecto y haga clic en Finish (Finalizar). Se mostrará el Proyecto de Reglas junto con el mapa del Proyecto de Reglas.

Cómo importar el XOM

Copie el esquema generado en el paso 3.1.1 a la raíz del proyecto. El proyecto deberá tener una apariencia como la que se muestra a continuación:

Figura 18. Importación de XOM
Importación de XOM

Seleccione el vínculo Import XOM para iniciar la definición del BOM.

Figura 19. Importación de XOM (en base a un esquema)
Importación de XOM (en base a un esquema)

Seleccione Dynamic Execution Object Model (XSD) y haga clic en OK.

Figura 20. Importación de XOM (selección del esquema)
Importación de XOM (selección del esquema)

Seleccione Add XSD... (Agregar XSD…)

Figura 21. Selección del XSD a agregar
Selección del XSD a agregar

Seleccione el esquema copiado a la raíz del proyecto y haga clic en OK.

Figura 22. Importación del XSD completo
Importación del XSD completo

Examine los paquetes y espacios de nombres que se usarán y haga clic en OK.

Cómo crear el BOM

En este momento hemos creado el XOM y estamos listos para crear el vocabulario que usarán los usuarios de negocios. El proyecto deberá tener esta apariencia:

Figura 23. Creación de un BOM
Creación de un BOM

El vínculo Create BOM se encuentra ahora activado. Selecciónelo.

Figura 24. Definición de una nueva entrada de BOM
Definición de una nueva entrada de BOM

Ingrese un nombre para el BOM (o acepte el predeterminado "model"), asegúrese de seleccionar Create a BOM Entry from a XOM. Haga clic en Next.

Figura 25. Navegación para seleccionar un XOM
Navegación para seleccionar un XOM

Haga clic en Browse XOM.

Figura 26. Elección del XOM previamente creado
Elección del XOM previamente creado

Seleccione el esquema al que se hizo referencia en el paso previo y haga clic en OK.

Figura 27. Selección de los tipos requeridos en el esquema
Selección de los tipos requeridos en el esquema

Seleccione los tres tipos definidos en el XOM y haga clic en Next.

Figura 28. Verbalización de la Entrada del BOM
Verbalización de la Entrada del BOM

Verifique que la verbalización predeterminada abarca lo necesario y haga clic en Finish. Si se debe modificar algo en el vocabulario, el BOM será visible en Rule Studio donde podrá modificarse desde dentro del BOM Editor.

Figura 29. Navegación del BOM para modificar la verbalización
Navegación del BOM para modificar la verbalización

Ya se han creado el BOM y el vocabulario predeterminado. El paso siguiente consiste en crear un conjunto inicial de reglas y generar el servicio de decisiones.

Materialización del Servicio de Deciciones de JRules

Esta sección identifica cómo se toma el esquema verbalizado y cómo se genera y verifica un servicio de decisiones de JRules con un conjunto inicial de reglas que pueden ser invocadas por Impact.

Cómo crear la firma y los parámetros del Servicio de Decisiones

En el BOM hemos definido ahora los parámetros de entrada y salida que deseamos usar en nuestro servicio de decisiones. El BOM define los tipos y la verbalización de los mismos, pero ahora debemos definir los parámetros de entrada y salida que se usarán en la comunicación con la Aplicación de Reglas.

Seleccione el vínculo Define Parameters en el mapa del Proyecto de Reglas. En el asistente que aparece, haga clic en el botón ADD (Agregar) y complete el nombre y la verbalización del argumento de entrada como se muestra a continuación. Fije la dirección en IN.

Figura 30. Definición de los parámetros del Servicio de Decisiones: Parámetro de entrada
Definición de los parámetros del Servicio de Decisiones: Parámetro de entrada

Seleccione el menú desplegable Type (Tipo).

Figura 31. Selección del tipo de parámetro
Selección del tipo de parámetro

Busque todos los tipos que comienzan con Alert y se visualizarán los tres tipos de BOM. Seleccione AlertEventInputType. Observe que en la parte inferior, la casilla de verificación permite a los usuarios indicar si el argumento es un único valor de este tipo o un array (colección). Como alternativa de recolección, se puede usar una clase java.util declarada en un XOM Java. Deje esta casilla sin marcar en el ejemplo. Haga clic en OK.

Repita el proceso para el parámetro alertOut (AlertEventOutputType) para obtener una visualización como la que se muestra a continuación.

Figura 32. Definición de los parámetros del Servicio de Decisiones: Parámetro de salida
Definición de los parámetros del Servicio de Decisiones: Parámetro de salida

Haga clic en OK.

Figura 33. Definición de los parámetros completes del Servicio de Decisiones
Definición de los parámetros completes del Servicio de Decisiones

Ahora se han definido los parámetros, que se agregarán a la firma de la invocación al servicio de decisiones.

Cómo crear un paquete de Reglas de Servicio de Decisiones

Ahora debemos crear un paquete que aloje algunas reglas. Comenzaremos con un paquete que aloje reglas de prueba simples. Esta tarea se podrá desarrollar aún más una vez que la integración básica esté en funcionamiento.

Seleccione el vínculo Add rule package en el mapa del Proyecto de Reglas. (O seleccione OMNIBusAlertDecisionService Rule Project y seleccione File > New > Rule Package en el menú).

Figura 34. Creación del paquete de reglas
Creación del paquete de reglas

Escriba el nombre del paquete AlertTestRules y haga clic en Finish.

Figura 35. Creación del paquete de reglas completo
Creación del paquete de reglas completo

Con esto se ha creado el paquete de reglas en la carpeta de reglas del servicio de decisiones.

Cómo crear un flujo de reglas para el Servicio de Decisiones

Esta sección describe cómo se crea un nuevo flujo de reglas que estarán expuestas en todo el servicio de decisiones. Seleccione el vínculo Add rule flow (o seleccione OMNIBusAlertDecisionService Rule Project y File > New > Ruleflow en el menú).

Figura 36. Creación de un flujo de reglas
Creación de un flujo de reglas

Escriba el nombre del flujo de reglas: "AlertRuleFlow". Haga clic en Finish. Se creará el flujo de reglas vacío AlertRuleFlow como se muestra a continuación.

Figura 37. Creación de Alert Rule Flow
Creación de Alert Rule Flow

Ahora debemos establecer el flujo.

  • Haga clic en el Nodo verde de inicio y luego en el diagrama AlertRuleFlow para crear un Nodo de inicio.
  • Haga clic en el nodo rojo de finalización y luego en el diagrama AlertRuleFlow para crear un Nodo de finalización.
  • Arrastre el paquete AlertTestRule desde el Explorador de Reglas hasta el diagrama AlertRuleFlow.
  • Conecte los tres nodos entre sí usando los vínculos "de transición" que se generan en un flujo de reglas como se muestra a continuación:
Figura 38. Establecimiento del flujo de reglas
Establecimiento del flujo de reglas

Con este procedimiento, cualquiera de las reglas incluidas en el paquete AlertTestRules podrá ser ejecutada cada vez que se invoque el servicio de decisiones.

En esta etapa, se deberá tomar un último paso a fin de evitar problemas posteriores. El parámetro de salida – alertOut no se crea de manera predeterminada, por lo que deberá ser iniciado en algún momento del flujo para permitir que las reglas hagan referencia al mismo. También pueden existir casos en los que no se brindan campos de parámetros de entrada, lo cual puede ocasionar excepciones de puntero nulo si una regla hiciera referencia a estos campos.

Para poder superar estas restricciones, a menudo es necesario incluir algunos pasos de inicio en la Initial Task (Tarea Inicial) del flujo. Para hacerlo, siga los pasos que se enumeran a continuación.

  • Paso 1. Seleccione la Initial Task en Outline o en el diagrama AlertRuleFlow.
  • Paso 2. Cree una Vista Propiedades: Seleccione Menú – Windows > Show View > Other...
Figura 39. Cómo crear el comportamiento de iniciación en las Initial Tasks
Cómo crear el comportamiento de iniciación en las Initial Tasks

Abra la carpeta General, seleccione la vista Properties (Propiedades) y haga clic en OK. Dispondrá ahora de una pestaña de propiedades, que deberá mover a un marco adecuado de Eclipse para luego seleccionar la casilla de verificación IRL. Paso 3. Ingrese el código de IRL para dar inicio a los parámetros de entrada y salida como se muestra a continuación

Figura 40. Código de inicio en la Acción Inicial
Código de inicio en la Acción Inicial

Este código se ocupa de tres pasos de inicio:

  • Crea una instancia de alertOut que puede pasar nuevamente a la aplicación que realiza la invocación.
  • Crea y completa el campo NewAlert de alertOut.
  • Si no se ha fijado el campo Type de alertIn, lo fija en 0.

Cómo crear un conjunto inicial de reglas

Ahora deseamos crear dentro de este paquete un conjunto inicial de reglas que usen la verbalización y los parámetros que pasarán al servicio de decisiones. Estableceremos tres reglas de prueba:

  • AlertTestUpdate: Actualiza una Alerta si se active la regla
  • AlertTestDelete: Elimina una Alerta si se active la regla
  • AlertTestCreate: Crea una nueva Alerta si se active la regla

En el Mapa del Proyecto de Reglas, seleccione el vínculo Add business Rule (o seleccione OMNIBusAlertDecisionService Rule Project y en el menú, seleccione File > New > Business Rule).

Figura 41. Creación de reglas: cómo crear y dar nombre a la regla
Creación de reglas: cómo crear y dar nombre a la regla

Navegue para seleccionar el paquete AlertTestRules y escriba el nombre de la regla: “AlertTestUpdate". Haga clic en Finish. Haga doble clic en la pestaña AlertTestUpdate resultante para expandir la regla en la vista Intellirule. En primer lugar, configuraremos una sección de definiciones.

  • Comience por escribir "definiciones": en cualquier momento escriba ctrl space y se harán visibles las opciones automáticas para completarlas.

Continúe usando la función auto complete para:

  • Seleceionar: set <Variable>
  • Escribir: inputAlert
  • Seleccionar: to <binding type>
  • Seleccionar: the main alert of <an alert event input type>
  • Seleccionar: alertIn
  • Seleccionar: ;

El resultado deberá ser la pantalla siguiente:

Figura 42. Creación de reglas: Editor Intellirule
Creación de reglas: Editor Intellirule

Esto provoca un error, debido a que falta la cláusula "then"(entonces) . Siga completando la regla con el editor Intellirule hasta lograr el código que aparece a continuación:

Figura 43. Creación de reglas: regla completa
Creación de reglas: regla completa

Haga clic con el botón derecho del mouse y haga clic en save (guardar). Esta regla verificará si el resumen no contiene ya el término "JRules Checked" y en ese caso, el mismo quedará previamente pendiente para el resumen. Luego, indica que esta alerta deberá ser actualizada hacienda que el campo "UpdateAlert" de respuesta corresponda a la alerta modificada. De hecho, cada resumen deberá incluir el prefijo "JRules Checked" a menos que el resumen ya lo incluya. Repita el proceso para las otras dos reglas como se muestra a continuación:

Figura 44. Creación de Alert Test Create Rule (regla de creación de la prueba de alerta)
Creación de Alert Test Create Rule (regla de creación de la prueba de alerta)

Esta regla creará una nueva alerta para cualquier alerta entrante con gravedad 4.

Figura 45. Creación de Alert Test Delete Rule (regla de eliminación de la prueba de alerta)
Creación de Alert Test Delete Rule (regla de eliminación de la prueba de alerta)

Con ella se eliminarán todas las alertas con gravedad 0 (Libres).

Cómo depurar el conjunto de reglas en Visual Studio

Esta sección describe cómo se prueba el conjunto de reglas dentro de Rule Studio de manera aislada de cualquier otro sistema o implementación. En el Menú seleccione Run > Open Run Dialog.

Figura 46. Depuración de reglas dentro de Rule Studio
Depuración de reglas dentro de Rule Studio

En la casilla de diálogo seleccione Rule Project, haga clic con el botón derecho del mouse y seleccione new.

Figura 47. Depuración de reglas (continuación)
Depuración de reglas (continuación)

Use el botón de navegación para seleccionar el proyecto de reglas OMNIBusAlertDecisionService y fije el nombre de la configuración correspondiente. Marque el casillero Stop at first rule statement (Detenerse después del enunciado de la primera regla). Y haga clic en Apply (Aplicar). Pase a la pestaña Parameters and arguments. Ahora ingresaremos algunos parámetros de prueba a pasar a las reglas que deberán activar la regla AlertTestUpdate. Seleccione el parámetro alertIn y haga clic en EditValue...

Figura 48. Valores para los parámetros de entrada
Valores para los parámetros de entrada

Seleccione la casilla de verificación Function body e ingrese el código para iniciar la alerta de entrada. Haga clic en OK.

Figura 49. Parámetros de entrada (continuación)
Parámetros de entrada (continuación)

Haga clic en Apply. A partir de este momento se puede ejecutar el conjunto de reglas. Haga clic en Run (Ejecutar). Se deberá visualizar el primer resultado de enunciado escrito de las reglas que se han activado en la ventana Console.

Figura 50. Ejecución de reglas en el Entorno de depuración
Ejecución de reglas en el Entorno de depuración

Si usted desea depurar el código, en el menú seleccione Run > Open Debug Dialog..., seleccione la configuración OMNIBUSAlertDecisionService y haga clic en Debug. Deberá recibir la alerta que confirma un cambio a la perspectiva de depuración.

Figura 51. Alerta de cambio de perspectiva
Alerta de cambio de perspectiva

Haga clic en Yes para ingresar en la perspectiva Debug (de depuración).

Figura 52. Ventana de depuración de reglas: depuración inicial de tareas
Ventana de depuración de reglas: depuración inicial de tareas

En la perspectiva de depuración el código se interrumpe en la primera parte del código de la regla, llevándose a cabo la iniciación como parte de Tarea Inicial. También se puede ver la inputAlert enla ventana de variables. Al seguir la secuencia del código en la sección de Contenidos (Body), se ejecutan/prueban las reglas y todas las reglas en las cuales las definiciones y la cláusula if evalúan a verdadero aparecen en la ventana de depuración como se muestra a continuación.

Figura 53. Ventana de depuración de reglas; depuración de reglas
Ventana de depuración de reglas; depuración de reglas

Se pueden probar las distintas reglas experimentando con las distintas configuraciones de parámetros de los Diálogos Run.

Cómo crear la Aplicación de Reglas y el Servicio de Decisiones

Antes de poder verificar este conjunto de reglas como un servicio de decisiones debemos crear una Aplicación de Reglas que lo contenga. En el mapa del Proyecto de Reglas seleccione el vínculo "Create RuleApp project" (o seleccione OMNIBusAlertDecisionService Rule Project y en el menú, seleccione File > New > Project... y luego RuleApp Project).

Figura 54. Creación de una Aplicación de Reglas
Creación de una Aplicación de Reglas

Escriba IMPACTRuleApp como nombre del proyecto y haga clic en next.

Figura 55. Creación de una Aplicación de Reglas; Agregado de proyectos de reglas
Creación de una Aplicación de Reglas; Agregado de proyectos de reglas

En la página siguiente, asegúrese de que el OMNIBusAlertDecisionService Rule Project esté seleccionado y haga clic en Finish. Se creará la RuleApp de manera tal que pueda ser implantada y verificada.

Figura 56. Aplicación de Reglas completa
Aplicación de Reglas completa

Cómo configurar el Rule Execution Server

Este escenario funcionará con una implementación predeterminada de RES y RTS en Tomcat en todo el servidor de muestras. Los escenarios más complejos requieren una implementación en el WebSphere Application Server. Este artículo no se ocupa de las diversas opciones de configuración e instalación para el Rule Execution Server y el Rule Team Server por lo cual las urls y los detalles de las configuraciones serán diferentes. Consulte la sección Installing (Instalación) del infocenter para ver más detalles.

La implementación más sencilla consiste en implementar la Aplicación de Reglas directamente en el Rule Execution server desde el Rule team server. Inicie el servidor de muestras (o el Rule Execution Server) para su instalación. Ahora debemos crear una configuración de Rule Execution Server que pueda reconocer Rule Studio. En el menú seleccione File > New > Other...

Figura 57. Configuración del Execution Server
Configuración del Execution Server

En la carpeta Rule Studio seleccione Rule Execution Server Configuration y haga clic en Next.

Figura 58. Creación de una nueva configuración de Execution Server
Creación de una nueva configuración de Execution Server

En la siguiente pantalla, haga clic en Create a new configuration project.

Figura 59. Nombre de la nueva configuración de Execution Server
Nombre de la nueva configuración de Execution Server

Deje los valores predeterminados seleccionados y haga clic en Finish.

Figura 60. Selección de la nueva configuración de Execution Server para este proyecto
Selección de la nueva configuración de Execution Server para este proyecto

Ahora, elija que este proyecto incluya la configuración y haga clic en Next.

Figura 61. Definición del entorno de hosting de Execution Server RES
Definición del entorno de hosting de Execution Server RES

En la siguiente pantalla seleccione el servidor de aplicaciones que aloja a RES (en este caso Tomcat) y haga clic en next.

Figura 62. Configuración del Execution Server: Definición de parámetros de hosting RES
Configuración del Execution Server: Definición de parámetros de hosting RES

En la configuración del Server navegue hasta el directorio Installation (como se mostró anteriormente): esta acción deberá establecer el directorio de implementación predeterminado para Tomcat. Además, establecerá la URL predeterminado para RES. El inicio de sesión y la contraseña son resAdmin de manera predeterminada. Haga clic en la conexión Test. Deberá obtener una respuesta de:

Figura 63. Conexión Test a la nueva Configuración del Execution Server
Conexión Test a la nueva Configuración del Execution Server

Si la conexión no tiene éxito, verifique que el servidor funcione y que se hayan ingresado correctamente las características. Los mensajes de fallas en la conexión por lo general indicarán la naturaleza del problema. Cuando la conexión tenga éxito, haga clic en Next.

Figura 64. Selección de implementación en la consola de RES
Selección de implementación en la consola de RES

En la pantalla final, asegúrese de seleccionar el botón de radio de implementación en la “ Rule Execution Server Console" y haga clic en Finish. Verifique que puede conectarse al Rule Execution Server siguiendo el vínculo "Open the Rule Execution Server " y conectándose con resAdmin/resAdmin. En este momento, estamos listos para implementar la RuleApp en RES.

Figura 65. Consola del Rule Execution Server
Consola del Rule Execution Server

Cómo implementar el Servicio de Decisiones

En Rule Studio, abra IMPACTRuleApp hacienda doble clic en el archivo archive.xml ubicado en el Proyecto IMPACTRuleApp.

Figura 66. Implementación del Servicio de Decisiones
Implementación del Servicio de Decisiones

Luego, seleccione el vínculo "Deploy a RuleApp to one or more Rule Execution Servers (Implementar una RuleApp a uno o más Rule Execution Servers)".

Figura 67. Implementación del Servicio de Decisiones: Definir estrategia de control de versiones
Implementación del Servicio de Decisiones: Definir estrategia de control de versiones

Seleccione el tipo de implementación en Replace RuleApp version: esto significa que la url usada para el servicio de decisiones no se modifica cuando se implanta una nueva versión.

Figura 68. Seleccione la configuración del Execution Server a implementar
Seleccione la configuración del Execution Server a implementar

Seleccione la configuración Tomcat (o la configuración previa) y haga clic en Finish. Los resultados de la implementación se visualizarán en el panel de la Consola: Navegue a la pestaña Rule Execution Server, abra el Explorador y observe el conjunto Ruleset. La estructura del servicio de decisiones se puede ahora visualizar, incluyendo los parámetros de entrada y salida.

Figura 69. Verificación de la implementación
Verificación de la implementación

Cómo probar el Servicio de Decisiones con el Explorador de Web Services

Debemos ahora probar el servicio web del Servicio de Decisiones provisto por el Rule Execution Server. Seleccione "Get HTDS WSDL for the ruleset version", haga clic con el botón derecho del mouse y seleccione Save as.

Figura 70. Recuperación de WSDL desde el Execution Server
Recuperación de WSDL desde el Execution Server

Navegue al directorio del servicio de decisiones en el espacio de trabajo de Rule Studio, seleccione Save as type: All Files e ingrese el nombre completo del archivo que se usará para el WSDL. Haga clic en Save. En Rule Studio seleccione el proyecto OMNIBusAlertDecisionService, haga clic con el botón derecho del mouse y seleccione refresh. Verifique que aparezca el archivo OMNIBusAlertDecisionService.wsdl. Cambie a la perspectiva Java e. Seleccione OMNIBusAlertDecisionService.wsdl, haga clic con el botón derecho del mouse y seleccione Web Services > Test with Web Services Explorer.

Figura 71. Prueba con Web Services Explorer
Prueba con Web Services Explorer

Seleccione el vínculo a "executeDecisionService". Esta es la operación del servicio web que invocará al conjunto de reglas.

Figura 72. Definición de parámetros de entrada a través del Explorer
Definición de parámetros de entrada a través del Explorer

Complete los parámetros usados anteriormente para probar la regla:
Node: Node
Severity: 3
Summary: Summary
Tally: 1

Observe que se debe fijar un valor para Tally ya que no es un campo opcional y de no proporcionar un valor fallará la validación del cliente del servicio web. Presioneel botón Go de la parte inferior del recuadro Actions.

Figura 73. Respuesta de los parámetros de salida del Explorer
Respuesta de los parámetros de salida del Explorer

La respuesta del servicio web se puede ver en la sección principal (Body). En este caso tenemos un conjunto UpdateAlert que copia los campos provistos agregando "JRules Checked" al comienzo del Resumen. Este enfoque de pruebas funciona bien siempre y cuando no se hayan generado excepciones en el Rule Execution Server Y el cliente sea el Web services Explorer.

Cómo probar el Servicio de Decisiones con TCP/IP Monitor

Cuando realizamos una integración con Netcool, se vuelve más difícil ver qué es lo que sucede. En este caso, vale la pena mientras se usa el TCP/IP Monitor que viene con Eclipse. Para configurar el TCP/IP Monitor navegue a su configuración eligiendo en el menú Tools > Preferences.

Figura 74. Configuración del TCP/IP Monitor
Configuración del TCP/IP Monitor

En el monitor agregue un proxy-ing de monitor localhost:8080 el cual es invocado a través del puerto local 8081. Reinicie el explorador del servicio web para que use localhost:8081.

Figura 75. Explorador de servicios web a través del TCP/IP Monitor
Explorador de servicios web a través del TCP/IP Monitor

Cuando se ejecute esta vez el explorador de servicios web, se podrá examinar el XML de la interacción.

Figura 76. Cómo examiner los datos de entrada / salida con TCP/IP Monitor
Cómo examiner los datos de entrada / salida con TCP/IP Monitor

Esto puede usarse para registrar cada una de las interacciones entre Impact y JRules. Además, observe que cada una de las interacciones está cronometrada de manera que al comparar esta cifra con las cifras de las estadísticas para el Servicio de Decisiones y el conjunto de reglas disponibles en el Rule Execution Server, se pueden comprender las latencias del procesamiento.

Cómo crear la regla Business Dependency (Dependencias de Negocios) para responder a los eventos de TI.

Esta sección analiza la extensión de las reglas necesarias para soportar el escenario 1. Esto implica el agregado de una regla que emita una alerta para cualquier aplicación de Fulfillment (Cumplimiento) en caso que el centro de datos que la aloja se desconecte.

La regla Business Dependency se agrega al paquete Alert Test Rules con la forma que se muestra a continuación.

definitions set 'datacenter' to the node of the main
alert of alertIn where the node of the main 
alert of alertIn contains "_Datacenter"
  and the alert key of the main alert of alertIn is 
  "Offline" ; set 'fulfillmentApp'
 to exchange + "_Trade_Fulfillment"; 
 set 'newAlert' to the new alert of alertOut ;
  then print "Creating predictive alert for Node:
  " + fulfillmentApp ; set the node of
  newAlert to exchange + "_Trade_Fulfillment" ;
  set the manager of newAlert to "JRules
Manager"; set the agent of newAlert to 
"JRules Predictive Agent"; set the alert
  group of newAlert to "Dependency" ; 
  set the alert key of newAlert to
                "DatacenterOffline" ;
set the identifier of newAlert to "Dependency:" +
                fulfillmentApp ; 
set the summary of newAlert to 
"Application impacted by " +
  datacenter + " going offline" 
; set the severity of the new alert of alertOut
 to 5 ;set the type of newAlert to 1; 
 set the new alert of alertOut to newAlert;

Esta regla usa la sección de definiciones para identificar cuándo se desconecta un centro de datos. Identifica que se trata de un centro de datos controlando si el nombre del nodo contiene la palabra “datacenter”. Se podrían haber utilizado otros mecanismos si se hubiera acordado la semántica de la alerta.

Esta regla introduce, además, la idea de conjuntos Rule Variables (Variables de reglas). Estas son variables que las reglas pueden compartir (como parte del flujo) pero que no pasan como parámetros. La variable de intercambio es una variable dentro del conjunto de variables Exchange Rule (Reglas de intercambio) definido en el paquete AlertTestRules Package. Se usa para contener la ubicación del centro de datos que además sería la ubicación de la aplicación de cumplimiento soportada por dicho centro de datos. Para iniciar esta variable, debemos agregar un código al IRL que introdujimos en la tarea Inicial del flujo de reglas. A continuación podemos visualizar esta enmienda.

Figura 77. Actualización de la tarea Inicial para identificar la variable de regla "Exchange"
Actualización de la tarea Inicial para identificar la variable de regla

Así se establece que el intercambio será la primera parte del nombre del centro de datos, dejándolo listo para usar en la regla cuando se haga referencia a la misma.

Integración de Impact y el Servicio de Decisiones de JRules

Esta sección describe cómo crear una política en Impact que pueda usar el servicio de decisiones que hemos desarrollado. Esta parte del escenario supone que usted tiene instalado Tivoli Netcool Impact en el mismo host que JRules con una instalación predeterminada y que el servidor de aplicaciones de Impact funciona y está conectado a un ObjectStore predeterminado de Netcool OMNIbus.

Cómo importar el archivo WSDL del servicio de decisiones

Netcool Impact viene con un asistente que automáticamente creará una política capaz de invocar un servicio web. En esta sección analizaremos los pasos para crear esta política e invocar el servicio de decisiones desde dentro de Impact.

El primer paso consiste en conectarse con la interfaz de usuario de Impact como se muestra a continuación.

Figura 78. Conexión a Impact Server
Conexión a Impact Server

El nombre de usuario y la contraseña predeterminada es admin/netcool.

Figura 79. Consola de Impact Server
Consola de Impact Server

Abra la sección Wizards (Asistentes) y seleccione Web Services.

Figura 80. Asistente de servicios web
Asistente de servicios web

Escriba el nombre de la política: en un principio, usaremos OMNIBusAlertDecisionServicePolicy como una política de prueba para la integración inicial. Haga clic en Next.

Figura 81. Paso 2 del asistente de servicios web
Paso 2 del asistente de servicios web

Ingrese la ruta al WSDL descargado del Rule Execution Server. Ingrese un nombre a utilizar para el paquete de códigos Java que se generará y al que por ende hará referencia la política. Haga clic en Next.

Figura 82. Paso 3 del asistente de servicios web
Paso 3 del asistente de servicios web

Controle los nombres del servicio web, del tipo de Puerto y del método. Los mismos deberán corresponder a los que se ven cuando se usa el explorador de servicios web. Haga clic en Next. El siguiente paso demora un poco más ya que Impact analiza el WSDL y compila el java para obtener el paquete que se puede invocar desde dentro de la política.

Figura 83. Definición del paso 4 para la muestra de datos de entrada
Definición del paso 4 para la muestra de datos de entrada

En la siguiente pantalla se brindan opciones para el código que se debe generar en la política. Si incluimos los mismos detalles que pusimos para las pruebas de Rule Studio, veremos rápidamente de qué manera invocaremos las mismas reglas desde Impact. Además, ingresamos una entrada “vigente” para obtener una ilustración de cómo se transfieren fechas y horarios, y ponemos una muestra de Related Alert (Alerta relacionada) para ver de qué manera se enviará la información asociada en todo el servicio de decisiones.

Figura 84. Paso 5 del asistente de servicios web
Paso 5 del asistente de servicios web

En la siguiente pantalla, seleccione el casillero de edición y cambie el Puerto de 8080 a 8081. De esta manera, se direccionará cualquier llamada al servicio de decisiones a través del monitor tcpip para que se puedan depurar todas las interacciones. Haga clic en Next.

Figura 85. Paso 6 del asistente de servicios web
Paso 6 del asistente de servicios web

Se obtiene una pantalla de resumen. Haga clic en Finish.

Figura 86. Muestra de política
Muestra de política

Se abrirá ahora la consola principal con una política que ha sido creada. Haga clic en el ícono Guardar para asegurarse de guardar el trabajo. La verdadera política generada se muestra a continuación:

//This policy generated by Impact Wizard. //This
policy is based on wsdl file at
 //C:\IBM\StudioWorkspace\OMNIBusAlertDecisionService\
OMNIBusAlertDecisionService.wsdl log
("Start policy 
'OMNIBusAlertDecisionServicePolicy'..."); 
	//Specify package name
  as defined when compiling WSDL in Impact
     WSSetDefaultPKGName('OMNIBusAlertDecisionService');
//Specify parameters
   DecisionServiceRequestDocument=WSNewObject
("com.ilog.www.rules.decisionservice.DecisionServiceRequestDocument");
  _DecisionServiceRequest=WSNewSubObject
    (DecisionServiceRequestDocument,"DecisionServiceRequest");
	_AlertIn =
    WSNewSubObject(_DecisionServiceRequest,"AlertIn"); 
	_AlertEventInput =
    WSNewSubObject(_AlertIn,"AlertEventInput"); 
	_MainAlert =
    WSNewSubObject(_AlertEventInput,"MainAlert");
	_MainAlert['Tally'] = 0;
    _MainAlert['Type'] = 0; 
	//Handle special calendar type... date =
    WSNewObject("java.util.GregorianCalendar"); 
	_MainAlert['FirstOccurrence'] = date;
     _MainAlert['Summary'] = 
'Summary'; _MainAlert['Severity'] = 3;
 _MainAlert['Node'] =
'Node'; WSParams = {DecisionServiceRequestDocument}; 
//Specify web service name, end
 point and method WSService =
 'DecisionServiceOMNIBusAlertDecisionService';
 WSEndPoint =
 'http://localhost:8081/DecisionService/ws/IMPACTRuleApp
/1.0/OMNIBusAlertDecisionService/1.0'; 
WSMethod = 'executeDecisionService';
log
("About to invoke Web Service call executeDecisionService ......");
WSInvokeDLResult = 
WSInvokeDL(WSService, WSEndPoint, WSMethod, WSParams);
 log("Web Service call 
 executeDecisionService return result: 
 " +WSInvokeDLResult);

Ahora intentaremos ejecutar la política. Habiéndola guardado, la política podrá visualizarse ahora en la sección Policies del navegador. Sin embargo, el archivo jar que se ha generado todavía no se encuentra en la ruta de la clase. Este archivo está situado en el directorio:

C:\IBM\Tivoli\Netcool\wslib\OMNIBusAlertDecisionService.jar

Cómo probar una política de Impact con un Servicio de Decisiones.

Esta es una prueba estática que se usa para verificar que al ejecutar la política usted podrá invocar JRules y obtener la respuesta que hemos generado en cada uno de los otros pasos. Navegue a la política en Impact.

Figura 87. Prueba de la política de Impact
Prueba de la política de Impact

Seleccione la fleche verde para ejecutar la política.

Figura 88. Ejecución de la política
Ejecución de la política

Presione el botón Execute.

Figura 89. Mensaje de error, en caso de errores
Mensaje de error, en caso de errores

En caso que surja un error, aparecerá un mensaje como éste y se deberá realizar una depuración. El primer paso consiste en buscar en e registro de políticas de Impact, que es donde aparecerán los enunciados del registro. Se puede hacer oprimiendo el botón “view” Log para el Policy Logger.

Figura 90. Registro de políticas
Registro de políticas

Muestra que se ha efectuado la llamada al servicio de decisiones sin obtener respuesta.

Se pueden ver más detalles en los registros de Netcool en los directorios:
C:\IBM\Tivoli\Netcool\log
C:\IBM\Tivoli\Netcool\impact\log

El análisis de los registros del monitor tcpip pueden indicar también qué es lo que está sucediendo.

Figura 91. Pruebas con TCP/IP Monitor
Pruebas con TCP/IP Monitor

En este caso, se obtiene la excepción debido a la ausencia de ciertos elementos obligatorios en el xml del servicio web para el parámetro alertIn. Se puede ver la misma información en los registros del Rule Execution Server para el servicio de decisiones.

Navegue al Ruleset del Rule Execution Server.

Figura 92. Verificación con los registros del Rule Execution Server
Verificación con los registros del Rule Execution Server

Seleccione View Execution Units (Visualizar unidades de ejecución) y expanda la lista de alertas.

Figura 93. Unidades de ejecución del Rule Execution Server
Unidades de ejecución del Rule Execution Server

Seleccione la unidad de ejecución localhost que muestra el error y expanda el mensaje de error relevante.

Figura 94. Mensajes de la Execution Unit
Mensajes de la Execution Unit

De esta manera se muestra el motivo de la excepción desde la perspectiva de JRules. Para remediarlo, modificaremos la política para establecer estos elementos. Los mismos se muestran a continuación en la política que figura en negrita.

//This policy generated by Impact Wizard. //This
  policy is based on wsdl file at
//C:\IBM\StudioWorkspace\OMNIBusAlertDecisionService\
OMNIBusAlertDecisionService.wsdl 
log
("Start policy 'OMNIBusAlertDecisionServicePolicy'...");
//Specify package name as 
defined when compiling WSDL in
Impact WSSetDefaultPKGName 
    ('OMNIBusAlertDecisionService');
	//Specify parameters
    DecisionServiceRequestDocument=
	WSNewObject("com.ilog.www.rules.decisionservice.DecisionServiceRequestDocument");
  _DecisionServiceRequest= 
  WSNewSubObject(DecisionServiceRequestDocument,"DecisionServiceRequest");
                _AlertIn =
	WSNewSubObject(_DecisionServiceRequest,"AlertIn");
   _AlertEventInput = 
   WSNewSubObject(_AlertIn,"AlertEventInput");
 _MainAlert = 
 WSNewSubObject(_AlertEventInput,"MainAlert");
_MainAlert['Tally'] = 0; _MainAlert['Type'] = 0;
 //Handle special calendar type...
date = WSNewObject
("java.util.GregorianCalendar");
 _MainAlert['FirstOccurrence'] = date;
 _MainAlert['Summary'] = 'Summary';
  _MainAlert['Severity'] = 3; _MainAlert['Node'] =
  'Node';_MainAlert['Manager']= 'Manager';
  _MainAlert['Agent']= 'Agent';
  _MainAlert['AlertGroup'] = 'AlertGroup'; 
  _MainAlert['AlertKey'] = 'AlertKey';
   _MainAlert['Identifier'] = 'Identifier';
    _MainAlert['Summary']='Summary';
	WSParams =
                {DecisionServiceRequestDocument};
//Specify web service name, end point and method
WSService = 'DecisionServiceOMNIBusAlertDecisionService';
 WSEndPoint ='http://localhost:8081/DecisionService/ws/
 IMPACTRuleApp/1.0/OMNIBusAlertDecisionService/1.0'; WSMethod =
  'executeDecisionService'; 
  log("About to invoke Web Service call
executeDecisionService ......"); 
WSInvokeDLResult = WSInvokeDL(WSService,
   WSEndPoint, WSMethod, WSParams);
log("About to invoke Web Service call
   executeDecisionService ...:
	" +WSInvokeDLResult);

Guarde y vuelva a ejecutar la política.

Figura 95. Re-ejecución de la política
Re-ejecución de la política

Así se muestra que la política se ha ejecutado con éxito. La vista tcpip muestra la interacción completa.

Figura 96. Validación con TCP/IP Monitor
Validación con TCP/IP Monitor

Y en el registro de la política se observa que la respuesta se encontraba realmente disponible para la política.

Figura 97. Registro de la política
Registro de la política

De esta manera se ha mostrado toda la interacción entre una política de Impact y una Aplicación de Reglas de JRules.

Cómo configurar políticas de Impact para responder a eventos de TI

La siguiente etapa consiste en crear una nueva política de Impact que responda a los eventos de TI provenientes de los detectores de Netcool OMNIbus para poder soportar el escenario 1. En primer lugar, creamos manualmente una política. En la pestaña Policies, seleccione la plantilla Custom y haga clic en el signo +.

Figura 98. Cómo crear una nueva política
Cómo crear una nueva política

Ingrese un nombre para la política (JRulesDecisonServicePolicy) y una conexión que se pueda verificar al invocarla. Guarde la política. En ese momento, vale la pena verificar que la política se ejecute y buscar el resultado esperado en el Policy logger. Ahora, debemos configurar un servicio en Impact para enviar los eventos de TI a esta política). Para hacerlo, creamos un servicio basado en un Event Reader de OMNIbus.

Expanda la pestaña Services en el navegador, seleccione un tipo de OMNIbusEventReader en el menú desplegable y haga clic en el símbolo+para iniciar el asistente.

Figura 99. Creación de un servicio de lector de eventos
Creación de un servicio de lector de eventos

En la primera pestaña proporcione un nombre y establezca el intervalo de polling que define al intervalo entre las consultas que realiza Impact. De hecho, esto define la frecuencia con la que Impact busca eventos nuevos o actualizados. Navegue a la pestaña EventMapping.

Figura 100. Creación del mapeo de eventos
Creación del mapeo de eventos

En esta pestaña, marque "Get updated events": esto significa que las actualizaciones a las alertas que cumplen con los criterios del filtro pasarán también por la política del servicio de decisiones. Observe que para que las eliminaciones de eventos también tengan significado para el servicio de decisiones de las reglas, deberá marcarse la casilla de verificación "Run policy on deletes". Así, será necesario definir una nueva política que indique a la Aplicación de Reglas que se está eliminando el evento. Esto no se ofrece en el ejemplo actual. Presione el botón New Mapping (Nuevo mapeo).

Figura 101. Creación del mapeo de eventos (continuación)
Creación del mapeo de eventos (continuación)

En esta pantalla, escriba una expresión de filtro que determine cuáles son los eventos que serán dirigidos a la Política. En este caso, usaremos el detector Simnet ( ver Referencia 11 ) para generar eventos de manera que todos los eventos de Simnet serán dirigidos a la política de JRules. En el campo "Policy to Run (política a ejecutar)", seleccione en el menú desplegable la JRulesDecisonServicePolicy que acabamos de crear.

Fije la política en activa. En este momento, será conveniente hacer clic en Analyze Filter para verificar que la sintaxis sea correcta y si existen otras políticas que se puedan superponer con esta condición de filtro. Haga clic en OK.

Figura 102. Asociación de la política a un filtro de eventos
Asociación de la política a un filtro de eventos

El filtro y el mapeo a la política son ahora visibles en la pestaña Event Mapping. Haga clic en OK para guardar la configuración de Event Reader. Para verificarlo, debemos seguir algunos otros pasos que a continuación se mencionan. Modifique la JRulesDecisionServicePolicy para obtener el Evento recibido.

log("Starting JRulesDecisionServicePolicy");
log("Event received: " + EventContainer); 
log("Finishing JRulesDecisionServicePolicy");

Inicie JRulesEventReader presionando la fleche de inicio verde en el cuadro Service status (Estado del servicio).

Inicie el detector SIMNET que genera los eventos. La configuración estándar del detector se modificará levemente para representar los escenarios que se usan en este caso. Esto afecta los Nodos y los eventos que se generan.

El archivo simnet.def define el escenario que se está representando, con 3 propiedades para cada entrada.

  1. El nombre del Nodo.
  2. El código que influye sobre Agent, AlertGroup, Summary y el procesamiento de alertas soportado por el nodo
    • 0. Link Up / Down – Usado para indicar los vínculos que entran o salen de línea
    • 1. Machine Up/Down – Usado para indicar los centros de datos que entran o salen de línea
    • 2. Disk space – Usado para indicar la utilización de aplicaciones
    • 3. Port Error – Usado para indicar un puerto que se reinicia en una aplicación o vínculo
  3. Porcentaje que indica la posibilidad de que se produzca una alerta.
Tabla 2. Definición de Simnet
Nombre del nodoCódigo del modeloPosibilidad de evento
London-Paris0 (Vínculo)1
Paris-NewYork0 (Vínculo)10
NewYork-London0 (Vínculo)5
London_Datacenter1 (Máquina)1
NewYork_Datacenter1 (Máquina)10
Paris_Datacenter1 (Máquina)5
London_Stock_Trading3 (Puerto)1
Paris_Stock_Trading3 (Puerto)5
NewYork_Stock_Trading3 (Puerto)5
London_Trade_Fulfillment2 (Espacio de disco)1
Paris_Trade_Fulfillmentt2 (Espacio de disco)10
NewYork_Trade_Fulfillment2 (Espacio de disco)5

Al observar el Policy logger en este momento, usted verá que se invoca JRulesDecisionServicePolicy para cada evento o actualización de SIMNET.

Figura 103. Registro de políticas para la política del servicio de decisiones
Registro de políticas para la política del servicio de decisiones

Aquí, el registro muestra tres eventos completes que son procesados por la política:
El vínculo NewYork_London sube
La aplicación Paris_Stock_Trading experimenta un reinicio del puerto
La aplicación NewYork_Stock_Trading experimenta un reinicio del puerto

Observe que el archivo simnet.rules ha sido modificado en esta situación para que corresponda de mejor manera al escenario; sin embargo, esto no es necesario para demostrar o probar la integración.

Desarrollo de políticas de Impact que invocan el Servicio de Decisiones de JRules

En este momento, podemos invocar al decision service de JRules desde una política de Impact y contamos con una política de Impact que es invocada por los eventos de Operaciones de TI. Esta sección describe cómo programar las políticas de Impact que invocan el decision service de JRules y cómo actuar ante las distintas respuestas que se pueden obtener.

Integración del servicio de decisiones de JRules a la Política de Impact

Esta sección se divide en una serie de sub-secciones que ofrecen distintos aspectos de la integración. Cada una de estas sub-secciones será una función de una política JRULES_LIBRARY. Estas funciones serán llamadas desde la política JRulesDecisionServicePolicy para brindar claridad de estructura. A continuación se muestra la estructura completa de esta política.

log("Starting JRulesDecisionServicePolicy");
 WSSetDefaultPKGName  ('OMNIBusAlertDecisionService');
//Specify Decision service parameters
DecisionServiceRequestDocument=
 WSNewObject 
 ("com.ilog.www.rules.decisionservice.DecisionServiceRequestDocument");
 _DecisionServiceRequest= 
 WSNewSubObject
 (DecisionServiceRequestDocument,"DecisionServiceRequest");
 _AlertIn = WSNewSubObject
 (_DecisionServiceRequest,"AlertIn");
  _AlertEventInput = WSNewSubObject
  (_AlertIn,"AlertEventInput");
   _MainAlert = WSNewSubObject
   (_AlertEventInput,"MainAlert");
 //Populate the Main event with the incoming alert
JRULES_LIBRARY.PopulateJRULESAlert(_MainAlert,EventContainer); 
//Populate the Related Events with other alerts from
 the same node node = @Node;
   JRULES_LIBRARY.PopulateJRULESRelatedAlerts
   (_AlertEventInput, node); 
   //Specify web service name, 
   end point and method WSParams = 
   {DecisionServiceRequestDocument};WSService = 
   'DecisionServiceOMNIBusAlertDecisionService';
   'http://localhost:8081/DecisionService/ws/
    IMPACTRuleApp/1.0/OMNIBusAlertDecisionService/1.0'; 
	WSMethod ='executeDecisionService'; 
	//Invoke the web service log("About to invoke Web Service
    call executeDecisionService ......"); WSInvokeDLResult
      = WSInvokeDL(WSService, WSEndPoint, WSMethod,
  WSParams); log
  ("Completed Web Service call executeDecisionService ...: "); 
//Get the returned Alerts and decide on actions to
take //UPDATE UpdatedAlert =
       WSInvokeDLResult.
DecisionServiceResponse.AlertOut.AlertEventOutput.UpdateAlert;
if(UpdatedAlert
!= null ) 
{ JRULES_LIBRARY.UpdateAlertFromJRULES
( UpdatedAlert ); } //DELETE
 DeletedAlert =
 WSInvokeDLResult.
DecisionServiceResponse.AlertOut.AlertEventOutput.DeleteAlert;
 if(DeletedAlert
!= null ) 
{ JRULES_LIBRARY.DeleteAlertFromJRULES( DeletedAlert ); 
} //CREATE
 NewAlert =
WSInvokeDLResult.
DecisionServiceResponse.
AlertOut.AlertEventOutput.NewAlert;
if (NewAlert
   != null 
   && NewAlert.Node != null 
   && NewAlert != "")
   { JRULES_LIBRARY.CreateAlertFromJRULES
   ( NewAlert ); 
	} log("Finishing
    JRulesDecisionServicePolicy");

Las acciones subsiguientes toman una función particular de la biblioteca y describen cómo funciona.

Envío de eventos al Servicio de Decisiones

El primer paso consiste en tomar el EventContainer provisto en el evento y mapearlo a la MainAlert provista al servicio de decisiones. El código de la Política se muestra a continuación, seguido por la función de la biblioteca.

			//Specify Decision service parameters
                    DecisionServiceRequestDocument= 
WSNewObject
("com.ilog.www.rules.decisionservice.DecisionServiceRequestDocument");
_DecisionServiceRequest= 
WSNewSubObject
(DecisionServiceRequestDocument,"DecisionServiceRequest");
      _AlertIn = WSNewSubObject
				(_DecisionServiceRequest,"AlertIn");
                _AlertEventInput = WSNewSubObject
				(_AlertIn,"AlertEventInput");
                _MainAlert = WSNewSubObject
				(_AlertEventInput,"MainAlert");
//Populate the Main event with the incoming alert
JRULES_LIBRARY.PopulateJRULESAlert(_MainAlert,EventContainer);

La solicitud principal definida en el WSDL es creada en primer lugar, y también se crea la jerarquía de subobjetos hasta llegar al alerta principal. Los campos de esta _MainAlert son completados luego desde el EventContainer por la función PopulateJRULESAlert que se muestra a continuación.

Function PopulateJRULESAlert( jrulesAlert, localAlert
                ) { //Identifier Information jrulesAlert['Serial'] = localAlert.Serial;
                jrulesAlert['Identifier'] = localAlert.Identifier; 
				//Alert Node / name
                jrulesAlert['Node'] = localAlert.Node; 
				//Alert Management and agent info
                jrulesAlert['Manager'] = localAlert.Manager; jrulesAlert['Agent'] =
                localAlert.Agent; jrulesAlert['AlertGroup'] = 
				localAlert.AlertGroup; //Alert Details
                jrulesAlert['AlertKey'] = localAlert.AlertKey; 
				jrulesAlert['Severity'] =
                localAlert.Severity; jrulesAlert['Summary'] = 
				localAlert.Summary; //Calendar fields
                date = WSNewObject("java.util.GregorianCalendar");
                time=localAlert.FirstOccurrence ; if 
				( time != null ) { if (time = 0) { time
                    = getDate() ; } JavaCall(null,date,"setTimeInMillis",
                {time*1000}); jrulesAlert['FirstOccurrence'] = date; }
                time=localAlert.LastOccurrence ; if ( time != null ) 
				{ if (time = 0)
				{ time =getDate() ; } 
				JavaCall(null,date,"setTimeInMillis",
                {time*1000}); jrulesAlert['LastOccurrence'] = date; }
				//Tally and Type
                jrulesAlert['Tally'] = localAlert.Tally; 
				jrulesAlert['Type'] = localAlert.Type;
                }

Observe que este enfoque fijará todos los campos requeridos en el XOM en un valor, evitando cualquier excepción en el análisis de los servicios web.

Agregado de las Related Alerts (Alertas relacionadas)

Las decisiones basadas en reglas a menudo requieren más información que la contenida en el evento, por lo cual este ejemplo también pasa todas las demás alertas que hay para el mismo Nodo. La política simplemente identifica el nombre del nodo y luego lo pasa junto con el _AlertEventInput (que contiene las RelatedAlerts) a la función PopulateJRULESRelatedAlerts.

//Populate the Related Events with other alerts from
                the same node node = @Node;
                JRULES_LIBRARY.PopulateJRULESRelatedAlerts(_AlertEventInput, node);

La función de la biblioteca busca cualquier alerta que use la fuente de datos Alerts, que es la configuración de fuente predeterminada en el Object Sotre NCOMS.

Function PopulateJRULESRelatedAlerts(alertEventInput,
                node) { RelatedAlerts =GetByFilter('Alerts', "(Node='" + node +
                "')", false); Num = length(RelatedAlerts); 
				log(" Found "+Num+" alerts"); if (Num
                > 0) { i=0; while(i < Num ) { //Get the alert Alert =
                RelatedAlerts[i]; //Check we dont double count the main alert if (
                EventContainer.Serial != Alert.Serial ) { RelatedAlert
                    = WSNewSubObject(alertEventInput,"RelatedAlert");
                JRULES_LIBRARY.PopulateJRULESAlert(RelatedAlert,Alert); } i = i + 1; } } }

Observe que la función excluye al evento que dispara la política, ya que la MainAlert se ocupará de ello. Cada Alert obtuvo resultados en un nuevo RelatedAlert que se completa usando la función PopulateJRULESAlert anteriormente descripta.

Cómo invocar el Servicio de Decisiones

Esta sección describe cómo se configuran verdaderamente los parámetros, los puntos finales, etc. y cómo se realiza la llamada al servicio de decisiones. El siguiente es el código que generó para nosotros el asistente del servicio web. Observe que aquí se deberá ingresar cualquiera de los cambios, a menos que se proporcionen como propiedades de la política.

//Specify web service name, end point and method
                WSParams = {DecisionServiceRequestDocument}; WSService =
                'DecisionServiceOMNIBusAlertDecisionService'; WSEndPoint =
                'http://localhost:8081/DecisionService/ws/
                IMPACTRuleApp/1.0/OMNIBusAlertDecisionService/1.0'; WSMethod =
                'executeDecisionService'; //Invoke the web service log
				("About to invoke Web Service
                call executeDecisionService ......"); WSInvokeDLResult
                = WSInvokeDL(WSService, WSEndPoint, WSMethod, WSParams);
                log("Completed Web Service call executeDecisionService ...: "
                +WSInvokeDLResult);

Cómo obtener la respuesta del Servicio de Decisiones

La siguiente sección muestra cómo se obtienen tres respuestas diferentes del servicio de decisiones como resultado, y cómo actuar en consecuencia.

//Get the returned Alerts and decide on actions to
 take UpdatedAlert =
WSInvokeDLResult.DecisionServiceResponse.AlertOut.
AlertEventOutput.UpdateAlert;
if(UpdatedAlert
 != null )
{ JRULES_LIBRARY.UpdateAlertFromJRULES
( UpdatedAlert ); } DeletedAlert =
  WSInvokeDLResult.DecisionServiceResponse.
AlertOut.AlertEventOutput.DeleteAlert;if(DeletedAlert
                != null )
{ JRULES_LIBRARY.DeleteAlertFromJRULES
( DeletedAlert ); } NewAlert =
                    WSInvokeDLResult.
DecisionServiceResponse.AlertOut.
AlertEventOutput.NewAlert;if(NewAlert
     != null && NewAlert.Node != null && NewAlert != "")
   { JRULES_LIBRARY.CreateAlertFromJRULES( NewAlert ); }

Cada una de las respuestas es manejada por una función de biblioteca independiente y se describe en las siguientes secciones.

Actualización de una Alerta

La función biblioteca que se muestra continuación ilustra cómo se actualiza una Alerta en Impact.

Function UpdateAlertFromJRULES( jrulesAlert ) {
                AlertsToUpdate = GetByFilter('Alerts', "(Identifier='" +
                jrulesAlert.Identifier + "')", false); Num
                Alert.EventReaderName = "JRulesEventReader"; //Copy the old fields over
                CopyAlert(Alert,oldAlert); //Transfer the updated fields
                PopulateAlertFromJRULES(jrulesAlert, Alert ); //Return the new
                    event log("Updateing alert: " + Alert.Identifier
                    ); ReturnEvent( Alert ); log("Finished Updateing
                alert: " + Alert.Identifier ); } }

Observe que el contenido original se recupera en primer lugar, para luego actualizarlo con lo recibido de JRules. Si el evento a actualizar se puede limitar al mainEvent, entonces se podrá usar EventContainer en lugar de Alert y no será necesaria ninguna consulta o copia. Aquí se usan dos funciones de biblioteca independientes.

La función Copy copia los campos del elemento de datos recuperados a la Alerta local:

			Function CopyAlert( toAlert, localAlert ) {
//Identifier Information toAlert.Serial = localAlert.Serial;
 toAlert.Identifier = localAlert.Identifier;
 //Alert Node / name toAlert.Node = localAlert.Node; 
 //Alert  Management and agent info toAlert.Manager = 
 localAlert.Manager; toAlert.Agent =
localAlert.Agent;
 toAlert.AlertGroup = localAlert.AlertGroup;
 //Alert Details toAlert.AlertKey = localAlert.AlertKey; 
 toAlert.Severity = localAlert.Severity;
  toAlert.Summary = localAlert.Summary; 
  //Calendar fields toAlert.FirstOccurrence =
 localAlert.FirstOccurrence; 
 toAlert.LastOccurrence = localAlert.LastOccurrence;
 //Tally and Type toAlert.Tally = localAlert.Tally; 
 toAlert.Type = localAlert.Type;
                }

Y la actualización desde JRules copia cualquiera de los campos provistos desde el servicio de decisiones.

			Function PopulateAlertFromJRULES( jrulesAlert,
 localAlert ) { //Identifier Information 
 if (jrulesAlert.Serial != null ) {
localAlert.Serial = jrulesAlert.Serial; }
 if (jrulesAlert.Identifier != null ) {
localAlert.Identifier = jrulesAlert.Identifier; }
 //Alert Node / name if
(jrulesAlert.Node != null ) 
{ localAlert.Node = jrulesAlert.Node; } //Alert
Management and agent info if (jrulesAlert.Manager != null ) 
{ localAlert.Manager =
 jrulesAlert.Manager; } 
 if (jrulesAlert.Agent != null ) { localAlert.Agent =
                jrulesAlert.Agent; } 
if (jrulesAlert.AlertGroup != null )
 { localAlert.AlertGroup =
jrulesAlert.AlertGroup; } //Alert Details
 if (jrulesAlert.AlertKey != null ) {
 localAlert.AlertKey = jrulesAlert.AlertKey; } 
if (jrulesAlert.Severity != null ) {
localAlert.Severity = jrulesAlert.Severity; }
 if (jrulesAlert.Summary != null ) {
localAlert.Summary = jrulesAlert.Summary; }
 //Calendar fields time=0 ; if (
jrulesAlert.FirstOccurrence != null )
 { time = JavaCall(null,
jrulesAlert.FirstOccurrence ,
 "getTimeInMillis", {}); localAlert.FirstOccurrence =
                time / 1000; } time=0 ; 
if ( jrulesAlert.LastOccurrence != null ) { time =
 JavaCall(null, jrulesAlert.LastOccurrence ,
 "getTimeInMillis", {});
localAlert.LastOccurrence = time / 1000; }
 //Tally and Type if (jrulesAlert.Tally !=
                null ) 
{ localAlert.Tally = jrulesAlert.Tally; } 
if (jrulesAlert.Type != null ) {
                localAlert.Type = jrulesAlert.Type; } }

Esta función sólo actualiza aquellos campos provistos desde JRules.

Eliminación de una Alerta

Este ejemplo muestra cómo eliminar una alerta indicada por el servicio de decisiones. En primer lugar, se asegura de que la IAlerta exista verificando el Identifier.

Function DeleteAlertFromJRULES( jrulesAlert ) { //Find
the alert based on serial AlertsToDelete =
 GetByFilter('Alerts', "(Identifier='" +
  jrulesAlert.Identifier + "')", false); Num = length(AlertsToDelete); 
  if ( Num
                > 0 ) { //Delete the first one that we find that matches Alert =
                AlertsToDelete[0]; log("Deleting alert: " + Alert.Identifier );
                DeleteDataItem(Alert); } }

Creación de una nueva Alerta

Por último, este ejemplo muestra cómo crear une nueva alerta según lo indicado por el servicio de decisiones.

			Function CreateAlertFromJRULES( jrulesAlert ) {
 newAlert= NewEvent("JRulesEventReader");
newAlert.EventReaderName = "JRulesEventReader";
 PopulateAlertFromJRULES(jrulesAlert,
newAlert ); //Set calendar fields if not set in Jrules if
 (jrulesAlert.FirstOccurrence == null ) { newAlert.FirstOccurrence
     = getDate(); } if (jrulesAlert.LastOccurrence == null ) {
     newAlert.LastOccurrence = getDate(); } log("Creating alert: " +
    newAlert.Identifier ); ReturnEvent( newAlert ); }

Aquí, también se usa la función PopulateAlertFromJRULES para completar los campos provistos por JRules.

Devoluciones de llamadas de la Aplicación de Reglas a Impact

Esta sección brinda generalidades de alto nivel sobre una aplicación de negocios que usa reglas que dependen de la información incluida en Netcool. Requiere la realización de una consulta en Impact. Así se describe el escenario anterior.

Aplicación y reglas de negocios

Una aplicación de compra venta proporciona una cantidad de reglas que incluyen a aquellas que dependen del estad de la alerta. Las mismas se resumen debajo del paquete de lista /nombre de la regla. Muchas son arbitrarias y se usan como muestras que pueden ser modificadas por el usuario de negocios usando un Rule Team server, pero sirven para demostrar el contexto de la aplicación de negocios. En cada una de las reglas se ofrece un estado de Pending (Pendiente)/Blocked (Bloqueado)/Rejected (Rechazado) junto con el motivo de dicho estado.

CheckAmount/Order Amount: proporciona reglas sobre el valor de la transacción.

Haga clic para ver la lista de códigos

siel monto de laordenes inferior a 100,000entoncesfijar el estado del informe en "Pending" ; fijar las razones del informe
                en "Customer Preferences" ;

CheckCurrency/CurrencyRestriction: proporciona reglas basadas en el campo de moneda de la orden.

sila moneda de la orden es "Euro"entoncesfijar el estado del informe en "Rejected" ; fijar las razones
                    del informe en "Customer Preferences" ;

CheckCustomerName/BadClients: proporciona reglas basadas en los clientes que solicitan la transacción.

Haga clic para ver la lista de códigos

siel nombre del cliente es "John Smith"entoncesfijar el estado del informe en "Rejected" ; fijar las razones
                    del informeen "Bad Client" ;

CheckStock/StockName: proporciona reglas basadas en las acciones que se comercializan.

Haga clic para ver la lista de códigos

siel stock de la orden es "Compañía X"entoncesfijar el estado del informe en "Blocked" ; fijar las razones
                    del informe en "Black Listed Stocks" ;

Reglas dependientes de TI

Esta sección presenta de qué manera es posible incorporar la dependencia de TI a estas reglas de negocios.

CheckFulfillmentRisk: verifica que la Aplicación de Cumplimiento asociada con el mercado donde ocurrirá la negociación no tenga alertas pendientes que puedan poner en peligro el cumplimiento de la negociación.

Haga clic para ver la lista de códigos

definitionsset exchange to the exchange
                of order;  risks to impact
                    client.queryAlerts("Node",exchange+"_FulfillmentApplication");sihay al menos una alerta de riesgo en los
                    riesgosdondela severidad de esta alerta de
                    riesgo es una de {"3","4","5", "6"},entoncesfijar el estado del informe en "Rejected" ;
                fijar las razones del informe en "Trade Fulfillment
                    Risk" ;

Esta regla, en primer lugar, extrae el mercado que usará la negociación y por ende identifica la aplicación de cumplimiento que se utilizará. Luego, realiza una consulta usando una clase java que se verbaliza usando el término "impact client" y expone un método estático denominado "queryAlerts". Este método toma dos propiedades.

  • El campo de la alerta a utilizar en la consulta - "Node"
  • El valor del campo a utilizar en la consulta -exchange+"_FulfillmentApplication"

Todas las alertas encontradas se colocan en la colecciónrisks.

La cláusula condicional (if) busca entonces cualquier alerta en la colección risks y si has hubiere, realice cualquiera con una gravedad superior a 3. Quizás pueda parecer una manera engorrosa de realizar la comparación de gravedad pero en este caso la gravedad ha sido mapeada a una cadena que contiene el código. Sería preferible que el usuario de negocios contara con una enumeración que estuviera verbalizada para indicar el significado de cada una de los códigos de gravedad, y esto se podría realizar fácilmente en el mapeo de XOM a BOM.

Si se cumple con las condiciones anteriormente definidas, entonces se active la regla y se rechaza la transacción debido a que existe un riesgo significativo de que no se pueda cumplir con ella.

XOM y BOM del Impact Client

El impact client invocado por las reglas es XOM java que invoca un servicio web de Impact. Se podría haber programado para que use cualquiera de los otros mecanismos anteriormente descriptos. Esto se muestra en la instantánea que aparece a continuación:

Figura 104. XOM y BOM java que forman IMPACT Client
XOM y BOM java que forman IMPACT Client

La clase ImpactClient brinda una implementación de este método que oculta los aspectos más complejos de la invocación de Impact mediante el servicio web.

public static RiskAlert[]
                queryAlerts(String queryField, String queryValue)
				{ ImpactClient client
                    = new ImpactClient();
					client.connect(); //set the fields up
                client.queryValue = queryValue; 
				client.queryField = queryField; //do the query
                client.queryAlerts(); //get back the results intn =
                client.alerts.size(); RiskAlert[] risks
                    = new RiskAlert[n]; for(inti =
                0; i < n; i++) { risks[i] =
                client.alerts.get(newInteger(i)); } return risks;
                }

Aquí, los dos pasos importantes son: client.connect(): establece una sesión con Impact conectándose mediante la operación de inicio de sesión en el servicio web.

public voidconnect()
                    { try{ listener
                =new ImpactWebServiceListenerDLIfcPortProxy();
                System. out.println("Attempting to login"); lid = listener.login(userId,
                password); System. out.println("Successfully logged in. Object id is " +
                lid.getClientId() + ":" + lid.getObjectId()); } catch(Exception ex)
                { ex.printStackTrace(System. out); } }

client.queryAlerts(): verdaderamente realiza la consulta usando valores en un cache local para el campo y el valor de la consulta.

public void queryAlerts() {
                ArrayList<WSPolicyUserParameter> wParams
                = new ArrayList<WSPolicyUserParameter>();
                WSPolicyUserParameter wParams0 = new     WSPolicyUserParameter();
                wParams0.setName("QUERYFIELD"); wParams0.setValue(this.queryField);
wParams0.setFormat("String");
 wParams.add(wParams0); 
WSPolicyUserParameter wParams1
                    = new WSPolicyUserParameter(); wParams1.setName("QUERYVALUE");
                    wParams1.setValue( this.queryValue);
                wParams1.setFormat("String"); wParams.add(wParams1);
                List<PolicyExecutionResult> results = null; try{
                results = listener.runPolicy (lid, "ExternalAlertQuery", wParams, true);
 System. out.println("Executed the policy"); for (int i = 0; i <
results.size(); i++) 
{ String propertyName = results.get(i).getName(); String
                propertyValue = results.get(i).getValue();

El código anterior muestra los parámetros del servicio web que se establecen para el campo de la consulta y el valor de la consulta que fueran especificados en la regla.

La llamada a listener.runPolicy pasa al token de sesión creado por el inicio de sesión (lid), al nombre de la política a ejecutar ("ExternalAlertQuery") y a los parámetros. Los resultados que se obtienen son una lista plana de pares de valores de nombres. Esta es una restricción del servicio web de Impact; el código se necesita entonces para identificar la cantidad de alertas y para verdaderamente asociar los campos de cada una de las alertas con el registro de alerta correcto antes de volver a pasar el array de RiskAlert a la Aplicación de Reglas.

Impact External Alert Query Policy (Política de consultas a alertas externas de Impact)

Cuando el servicio web de Impact es invocado por la Aplicación de Reglas, se ejecuta la política de Impact que se muestra. Esto es relativamente simple pero debe proporcionar la estructura aplanada para los resultados, como se muestra a continuación. Este es un enfoque muy simple que sólo soporta tres resultados.

log("****ExternalAlertQuery*****"); log
                ("Query: " + QUERYFIELD + " = " + QUERYVALUE ); Alerts
                =GetByFilter ('Alerts', "("+QUERYFIELD + "='" +QUERYVALUE + "')",
                false); NumAlerts = < blength/>( Alerts); log(" Found
                "+NumAlerts+" alerts");if( NumAlerts> 0 ) { WSListenerResult
                    = NewObject();
                    WSListenerResult.NUMBER_OF_ALERTS= String(NumAlerts);
                WSListenerResult.ALERT0_SEVERITY = String( Alerts[0].Severity ) ;
                WSListenerResult.ALERT0_SUMMARY = Alerts[0].Summary ;
                WSListenerResult.ALERT0_ALERTGROUP = Alerts[0].AlertGroup;
 WSListenerResult.ALERT0_ALERTKEY = Alerts[0].AlertKey;
 WSListenerResult.ALERT0_NODE
                = Alerts[0].Node; WSListenerResult.ALERT0_TYPE
                = String(Alerts[0].Type); } if( NumAlerts> 1
                ) { WSListenerResult.ALERT1_SEVERITY = String( Alerts[1].Severity )
                ; WSListenerResult.ALERT1_SUMMARY = Alerts[1].Summary ;
                WSListenerResult.ALERT1_ALERTGROUP = Alerts[1].AlertGroup;
WSListenerResult.ALERT1_ALERTKEY = Alerts[1].AlertKey;
				WSListenerResult.ALERT1_NODE
                = Alerts[1].Node; WSListenerResult.ALERT1_TYPE
                = String(Alerts[1].Type); } if( NumAlerts> 2
                ) { WSListenerResult.ALERT2_SEVERITY = String( Alerts[2].Severity )
                ; WSListenerResult.ALERT2_SUMMARY = Alerts[2].Summary ;
                WSListenerResult.ALERT2_ALERTGROUP = Alerts[2].AlertGroup;
WSListenerResult.ALERT2_ALERTKEY = 
Alerts[2].AlertKey; WSListenerResult.ALERT2_NODE
                = Alerts[2].Node; WSListenerResult.ALERT2_TYPE
                = String(Alerts[2].Type); }

Los dos parámetros definidos en el servicio web QUERYFIELD y QUERYVALUE se encuentran disponibles como parámetros denominados en la política.

La política realiza una consulta en la base de datos "Alerts" definida en función del ObjectStore NCOMS OMNIbus predeterminado. Si se devuelve cualquier resultado, crea entonces un registro de resultados y agrega un campo a los resultados correspondiente al número de alertas encontradas y a cada campo de cada una de las alertas. Luego, esto se vuelve a enviar a la Aplicación de Reglas que lo interpreta, como ya hemos observado.


Ejecución del escenario

Ahora que contamos con todos los aspectos de la integración completos, podemos configurar la simulación para que se ejecute con el detector Simnet y observar las interacciones que tienen lugar entre Impact y JRules para materializar las diversas situaciones del escenario.

Lista de eventos del escenario

El detector Simnet genera eventos de acuerdo con su configuración y los mismos se muestran en cualquier lista de eventos disponible en Netcool / Impact. La instantánea que se muestra a continuación ilustra la Lista de eventos de Netcool OMNIbus después de que el detector Simnet se ha ejecutado por un tiempo con JRulesEventReader apagado. TEsto significa que ni Impact ni JRules están procesando los eventos.

Figura 105. Lista de eventos del escenario sin procesamiento de las reglas
Lista de eventos del escenario sin procesamiento de las reglas

Luego se detiene el detector Simnet. Ahora, activamos JRulesEventReader para permitir que Impact procese los eventos, los canalice a JRules y ejecute las reglas. La lista de eventos tiene ahora la siguiente apariencia.

Figura 106. Lista de eventos del escenario después del procesamiento de las reglas
Lista de eventos del escenario después del procesamiento de las reglas

Podemos observar que cada uno de los eventos ha pasado por la regla TestUpdateAlert ya que cuenta con el prefijo “JRules Checked” en el resumen. Además, podemos ver que se han creado dos nuevos eventos debido a que los centros de datos han salido de línea, y que éstos han sido mapeados a las correspondientes aplicaciones de cumplimiento de las transacciones.

Aplicación de las reglas

Al observar el rastro de TCPIP y seleccionar las últimas interacciones podemos ver la respuesta de la Aplicación de Reglas cuando el Centro de datos de Londres sale de línea.

Figura 107. Rastro de TCP/IP
Rastro de TCP/IP

Para esto se activan dos reglas: la BusinessRule que crea una nueva alerta para la Aplicación London_Trade_Fulfillment y la TestUpdateAlert que anexa al principio del resumen la frase JRules Checked.

Política de Impact que integra la respuesta de las reglas

Al observar el registro de políticas de Impact podemos ver la política que respondió ante la caída del centro de datos de Londres y la respuesta generada.

Parser log: Starting JRulesDecisionServicePolicy
Parser log: About to invoke Web Service call executeDecisionService 
...... Parser
log: Completed Web Service call executeDecisionService
 ...: Parser log: Updateing
alert: London_DatacenterMachineMon4Systems MP.returnEven
 did eri.putEvent for
EventContainer: (Type=0, Tally=1,
 Manager=Simnet Probe, Summary=JRules Checked
London_Datacenter Offline, Agent=MachineMon, EventReaderName=JRulesEventReader,
AlertGroup=Systems, Serial=19660, FirstOccurrence=1.256026031E9,
Identifier=London_DatacenterMachineMon4Systems, AlertKey=Offline,
Node=London_Datacenter, Severity=4, LastOccurrence=1.256026031E9) 
Parser log:
Finished Updateing alert:
 London_DatacenterMachineMon4Systems Parser log: Creating
alert: Dependency:London_Trade_Fulfillment MP.returnEvent 
did eri.putEvent for
EventContainer:
(Type=1, Tally=0, Manager=JRules Manager,
 Summary=Application
 impacted by London_Datacenter going offline, 
 Agent=JRules Predictive Agent,
 EventReaderName=JRulesEventReader, 
 AlertGroup=Dependency, Serial=0,
 FirstOccurrence=1256026130, 
 Identifier=Dependency:London_Trade_Fulfillment,
AlertKey=DatacenterOffline, 
Node=London_Trade_Fulfillment, Severity=5,
LastOccurrence=1256026130)
 Parser log: Finishing JRulesDecisionServicePolicy

Esto muestra el evento que se actualizó y el nuevo evento que se creó cuando se cayó el centro de datos de Londres. Observe que los archivos del registro muestran el resultado de múltiples políticas que se ejecutan al mismo tiempo y el registro que se muestra anteriormente se ha obtenido a partir de la edición de las respectivas partes del registro.

Con esta nueva información ahora incluida en la suite Netcool, las aplicaciones de negocios podrán usar los mecanismos de acceso descriptos en el análisis inicial para expresar reglas en función del estado de las operaciones de TI.


Conclusión

Esta artículo ha repasado los pasos necesarios para integrar Tivoli Netcool Impact con WebSphere ILOG Business Rule Management System, permitiendo a los usuarios de negocios usar reglas de negocios con el fin de definir sus políticas para influir sobre las políticas de Operaciones de TI y para usar el estado de los Eventos de Operaciones de TI dentro de sus reglas de aplicaciones de negocios.

El análisis de la Sección 3 mostró todos los pasos de integración necesarios para materializar los escenarios descriptos en la Sección 2. Las demostraciones de estos escenarios funcionando con las políticas y las reglas descriptas en la sección 3 se ofrecen en la Sección 4.

El uso de este ejemplo ofrece un marco para que los lectores desarrollen sus propios Modelos y Reglas de Objetos de Negocios en BRMS y los asocien con los eventos, las estructuras de datos y las políticas de las Operaciones de TI de Tivoli Netcool Impact.

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=SOA y servicios web
ArticleID=491307
ArticleTitle=Integración de Tivoli Netcool Impact y WebSphere ILOG BRMS
publish-date=08052011