内容


集成 Tivoli Netcool Impact 和 WebSphere ILOG BRMS

场景及其实现

免费下载:IBM® WebSphere® ILOG JRules 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

执行摘要

本文描述可能需要同时使用 Tivoli Netcool/Impact 和 WebSphere ILOG Business Rule Managements System (JRules) 的业务场景,以及如何快速地集成产品以为这些场景实现解决方案。

现代的业务解决方案涉及到处理大量事件,包括业务事件和基础架构事件,如下图所示。

图 1. 业务和基础架构决策制定需求
业务和基础架构决策制定需求
业务和基础架构决策制定需求

业务用户需要及时发现可操作的业务模式并做出响应,以对业务的执行产生有利影响。解决方案需要关联来自物联化资产和系统的业务事件中的复杂模式,从而做出管理业务活动和绩效所需的业务决策。

IT Operations 用户需要了解并确保关键服务、流程和基础架构的健全。解决方案需要在所有物联化资产和系统中关联与基础架构相关的事件,使之能够理解事件对业务的影响,并为管理服务、流程和基础架构的健全做出决策。

不过这些领域并非孤立存在的,因此在现代的解决方案中,两种用户角色都需要理解可操作业务模式之间如何相互影响,以及复杂服务、流程和基础架构的健全状况。

IBM 提供 WebSphere Business Process Management 产品来支持业务用户,并提供 Tivoli Service Management 产品来支持 IT Operations,如下图所示。

图 2. 针对业务用户和基础架构用户的产品支持
针对业务用户和基础架构用户的产品支持
针对业务用户和基础架构用户的产品支持

从该图可以看出,需要集成这些产品系列来支持共享洞察和决策。本文主要描述如何使用 WebSphere ILOG Business Rule Management System 和 Tivoli Netcool Impact 来实现业务与基础架构之间的共享决策,如下图所示。

图 3. Netcool Impact 和 ILOG BRMS 集成概览
Netcool Impact 和 ILOG BRMS 集成概览
Netcool Impact 和 ILOG BRMS 集成概览

第 1 小节概述了 Tivoli Netcool Impact 和 WebSphere ILOG BRMS (JRules),使用户熟悉这两款产品的产品角色和业务主张。

下面描述两个关键的交易场景。

图 4. 场景 1 - IT 事件影响业务决策
IT 事件影响业务决策
IT 事件影响业务决策

在这个场景中发生了一个 IT 事件(交易系统不堪重负或数据中心离线)。在本例中,IT Operations 角色必须决定该事件是否对业务产生严重影响,如果确定为产生严重影响,则通知企业采取必要的措施。但是需要由业务用户(Business User)或自动化决策过程的规则来确定 IT 事件是否给业务造成严重影响。在 2.2 小节中将描述这一场景,并且在 3.1 至 3.4 小节中将详细描述如何实现该场景。

图 5. 场景 2 – 业务事件需要基础架构响应
场景 2 – 业务事件需要基础架构响应
场景 2 – 业务事件需要基础架构响应

在第二个场景中 ,业务用户知道出现了什么情况,并且需要知道来自 IT Operations 方面的信息以有效地做出决策。在本例中,可能由许多 IT 原因之一导致了完成时间推迟,比如数据中心故障或应用程序的承受能力已达到极限。风险的大小取决于事件的延续时间,因此在做出决策之前要获得该信息。如果 IT Operations 未觉察到这一业务情况,还可以展开调查并纠正问题。2.3 小节将详述该场景,并在 3.5 小节中描述集成过程。

第 4 小节是本文的结尾部分,它将概述这些场景并演示集成的实际过程。

简介

概述

本文描述可能需要同时使用 Tivoli Netcool/Impact 和 WebSphere ILOG Business Rule Managements System (JRules) 的业务场景,以及如何快速地集成产品以为这些场景实现解决方案。

概述小节描述了 Tivoli Netcool Impact 和 WebSphere ILOG BRMS (JRules),使用户熟悉这两款产品的产品角色和业务主张。

在下一个小节中将讨论一组场景,通过这些场景了解集成 Impact 和 JRules 如何为 IT Operations 和业务用户之间的通信提供便利,以及由此带来的商业价值。

本文提供了集成这两款产品和实现相关场景的所有步骤。除了提供集成过程中的产品屏幕截图之外,还提供开发和测试集成产品的指南。

在本文的最后小节中概述了所有场景,并为集成人员提供了一些相关的参考资料。

Netcool / Impact 概述

Netcool/Impact 提供 IT 事件管理和 IT 数据集成功能。Impact 为集成不同来源的数据提供了方法,比如来自数据库、LDAP 和第三方源的数据。请查看图 3 了解 Impact 的简略架构。

Tivoli Netcool/Impact 提供一组相互关联的、可运行的服务器组件。这些组件是:

  • Impact Server
  • GUI Server

Netcool/Impact 服务器

Netcool/Impact 服务器是该系统的主要软件组件。这个组件负责 Netcool/Impact 的核心功能,包括管理 Netcool/Impact 数据模型、运行服务和执行策略。您可以运行 Netcool/Impact 服务器的一个实例,也可以作为服务器集群的一部分运行多个实例,具体情况取决于您使用该产品的方式。使用 Netcool/Impact 执行的大多数任务都需要用到这个服务器组件。

Netcool GUI 服务器

Netcool GUI 服务器是负责驻留 Netcool/Impact GUI 并为之提供服务的组件。通常情况下,只需为在环境中运行的所有兼容 Netcool 产品安装一个 GUI 服务器。

Netcool/Impact 用例

您可以根据环境的需求以多种方式使用 Netcool/Impact。确定使用 Netcool/Impact 为您做什么的方法之一是分析它的核心特性,看看如何组建一个能够提升 Netcool 的价值的解决方案。另一种方法是查看其他 Netcool 用户实现的典型解决方案,然后看看如何根据您的环境需求修改它们。最后,您还可以查看网络环境中的工作流,看看该流程的哪些部分可以使用 Netcool/Impact 加以改善。

图 6. Netcool Impact 用例
Netcool Impact 用例
Netcool Impact 用例

核心的 Netcool/Impact 特性

如上所述,确定使用 Netcool/Impact 为您做什么的方法之一是分析它的核心特性,看看如何将它们应用到您的环境中。下面的几个小节将讨论 Netcool/Impact 的最重要特性中的一些,以及它们与事件管理之间的关系,尤其是它们与 Netcool 产品套件的关系。

Netcool/Impact 的核心特性为:

  • 自动化
  • 事件源访问
  • 数据访问
  • 与第三方应用程序集成
  • 预定义行为

自动化

从总体上看,自动化是 Netcool/Impact 的最重要特性。Netcool/Impact 能够自动化原本需要手动完成或者甚至无法完成的事件管理任务。这些任务包括事件监视、事件丰富和事件通知。然而,自动化实际上是 Netcool/Impact 的基础。自动化的工作方式是设置一个任务,使之在特定时间或满足特定条件时自动执行。

和产品装配线一样,自动化某些流程有益于网络运营环境。例如,当警报的严重性达到一定的级别时通知技术人员或系统管理员,或者更新事件以包含相关的业务数据,从而节省一个或多个网络管理员的时间或精力。

这个例子表明,使用自动化的事件管理环境的成本比手动事件管理环境低,并且不容易出现人为错误。Netcool/Impact 为自动化提供的框架由策略引擎、策略脚本语言和各种触发器组成,其中触发器的作用是让 Netcool/Impact 在不同的条件下启动策略。策略引擎是执行需要自动化的任务的 Netcool/Impact 特性。使用策略脚本语言来指定这些任务,该语言是语法与 C/C++ 和 Java 类似的编程语言。

事件访问

事件访问是 Netcool/Impact 除了自动化之外的最重要特性。事件访问特性允许 Netcool/Impact 充分利用从 Netcool 探测器和监视器进入 Netcool/OMNIbus ObjectServer 的事件流。这个特性是该产品的大部分实现的关键部分。

要了解事件访问为什么如此重要,您首先需要了解 Netcool 事件流及其生成方式。Netcool 事件流是从 Netcool 探测器和监视器进入 ObjectServer 的一系列警告。每个警告都表示网络上的一些状态或活动,并且可以由数百种系统、设备或应用程序之一生成。一般而言,警告的目的是通知网络运营员网络环境中的某些地方出现错误。警告还可以用来传递其他类型的状态或事件信息。

警告本身是由名为探测器或监视器的软件组件生成的,探测器或监视器监控系统、设备或应用程序,并且在发生各种情况时生成警告。探测器和监视器生成了警告之后便将其发送到 ObjectServer,网络运营员可在此处通过 Netcool/OMNIbus 事件列表查看警告。

如前面小节所述,网络管理环境受益于自动化事件管理任务。自动化依赖于 Netcool/Impact 能够充分利用 Netcool 事件流。Netcool/Impact 为事件访问提供的框架包含三个特性:事件阅读器、事件侦听器和事件处理器。这些都是可以通过 Netcool/Impact 控制的可运行服务。

OMNIbus 事件阅读器通过监视 ObjectServer 的一个实例进行工作。当它发现新的或更新的事件或事件被删除时,就会捕捉该事件并传回给 Netcool/Impact 进行处理。

类似地,事件侦听器监视其他非 ObjectServer 源事件,比如 SQL 数据库。与事件阅读器一样,它仅探测新的或更新的事件并将其传回给 Netcool/Impact。

事件处理器负责获取到事件之后的处理工作。在创建事件阅读器和或事件侦听器时,可以定义一个或多个策略,并在事件满足特定的条件时执行它们。如前面小节所述,策略是为 Netcool/Impact 设置的一组指令,它指定需要自动化的任务。将策略与事件阅读器或事件侦听器结合起来之后,就可以使用一个策略来指定希望 Netcool/Impact 自动执行的一组任务。当 ObjectServer 中出现某种警告或其他事件源中出现某些事件时这组任务将自动执行。

事件访问和自动化功能的结合使您能够创建各种不同的事件管理解决方案。这些解决方案包括事件丰富、Y 时间段中的 X 事件、事件通知和事件网关,如本小节的后面部分所述。

数据访问

与自动化和事件访问一样,数据访问也是 Netcool/Impact 的重要特性。数据访问是允许 Netcool/Impact 连接到外部数据源(比如 SQL 数据库和 LDAP 服务器)的特性。

要了解为什么这个特性很重要,您可以想想在网络管理环境中使用外部数据(相对于 Netcool/OMNIbus)的所有方式。您可能使用一个数据库来存储网络库存信息,而使用另一个数据库来储存账单和客户服务信息。此外,您可能还使用一个 LDAP 目录来存储关于公司人事的信息。

在未使用 Netcool/Impact 的环境中,网络管理员可能需要手动地从一个或多个这些数据源获取数据,并使用该信息来推断事件的重要性或确定处理事件的方式。有了 Netcool/Impact 之后,您可以将这种类型的数据直接集成到 ObjectServer 级别的警告中,或者使用该数据来执行各种分析,从而了解警告的严重性或各个警告之间的相关度。

Netcool/Impact 用来访问数据的机制由数据源适配器(DSA)和 Netcool/Impact 数据模型组成。在软件组件级别,DSA 使 Netcool/Impact 能够连接到各种 SQL 数据库、LDAP 服务器和其他数据源。在解决方案级别,数据模型是环境中的数据的抽象表示。Netcool/Impact 从数据源获取、添加、更新和删除数据时,将在策略内部使用数据模型。

第三方集成

与第三方应用程序集成是 Tivoli Netcool/Impact 的又一个重要特性。在许多网络运营环境中,您可能使用由一个以上的软件供应商开发的系统。例如,除了 Netcool 产品套件之外,您还可能使用其他第三方应用程序来管理网络库存、账单、问题跟踪、客户服务和前台服务。

Tivoli Netcool/Impact 为大量诸如此类的第三方应用程序提供了接口,包括 GE Smallworld、Portal Infranet 和 TIBCO TIB/Rendezvous。Tivoli Netcool/Impact 能够直接与大量第三方应用程序的底层数据库通信,从而实现与这些应用程序的交互。

ILOG / JRules 概述

IBM WebSphere ILOG Business Rule Management System (JRules) 提供创作、测试、模拟、部署、执行和管理业务规则支持,并且同时支持业务和技术用户。

技术用户(比如开发人员和 IT Operations 人员)需要定义应用程序的结构和用于调用规则系统的接口。这反过来定义词汇表,业务用户可以使用词汇表来表达业务中重要方面的需求和策略。凭借这种方式,用户能够快速改变业务应用程序规则和行为,以响应不断变化的市场环境。

在前一小节中,我们了解了 Tivoli Netcool/Impact 如何能够监视来自各种探测器和系统的警告,以及如何使用事件访问机制来帮助增强这些事件。本文还将演示如何将 JRules 与 Netcool/Impact 结合使用,以允许业务用户定义(和维护)用于将业务透视图信息添加到 IT 事件处理中的规则。

WebSphere ILOG Business Rule Management System 架构

下图描绘了 BRMS 及其对各种角色的支持。

图 7. ILOG BRMS System 架构
ILOG BRMS System 架构
ILOG BRMS System 架构

下面描述了各个组件:

  • Rule Studio:为开发人员和技术用户提供的基于 Eclipse 的集成开发环境(ODE),它支持 Rule Application 开发和调试。
  • Rule Team Server:一个基于 Web 的规则管理服务器和存储库,它为用户提供一种方式来创作、管理、验证和部署决定 Rule Application 的行为的业务规则。Rule Team Server 还允许访问共享 Rule Repository,从而实现集中地管理规则。
  • Rule Execution Server:一个遵从 J2SE 或 J2EE 的规则执行环境,Business Applications 可以使用同步、异步或基于 web 服务的调用来调用它来执行规则。
  • Decision Validation Services (DVS):用于测试、验证规则的正确性和模拟业务策略变更的集成环境。

Business Rule Application 架构

为了在应用程序上下文中使用 Business Rules,读者需要理解 Rule Application 的术语和架构以及 Business Applications 如何调用它。下图显示了 Rule Application 的架构。下一小节将详细介绍所有这些概念。

图 8. Business Rule Application 架构
Business Rule Application 架构
Business Rule Application 架构

Business Application 通过受支持的众多 Rule Invocation 机制之一调用 Rule Application。本文主要讨论用来调用规则的 Decision Service。Business Application 也有一个用来表示由规则推断出的对象的 Information Model。 每个模型都可以用 Java 来表示,或表示为 XML 模式,它们都被称为 Execution Object Models (XOM)。

Rule Execution Server 在其内部托管 Rule ApplicationRule Sets,可以从 Rule Studio(针对技术用户)和 Rule Team Server(针对业务用户)部署或更新它们。Rule Application 由技术用户创建,用于包含所需的规则集。每个规则集都有一个词汇表或 Business Object Model (BOM),它们使用术语或适合业务用户的 “词汇” 来表达规则。每个 BOM 条目最初都可以从 Business Application 中使用的 XOM 衍生得到。技术用户使用 Rule Studio 来定义 BOM 条目和将为业务用户提供的词汇。

技术用户还需要了解应该在 Business Applications 中的什么地方应用规则(Rule Invocation)。每个 Rule Invocation 将被映射到规则集中(因此也在 Rule Application 中)定义的规则流中。规则流有一个使用参数定义的签名,这些参数来自被 Business Application 调用的 Information Model (XOM),并在经过规则处理之后映射到 Business Object Model。当规则流被调用时,就可以配置并运行一系列规则包和/或规则。如果将一个规则包插入到流中,那么在该包中定义的所有规则都将可能被执行。如果指定了特定的规则,那么规则流在该点仅执行指定的规则。

每个规则都有如下图所示的结构。

图 9. 样例规则
样例规则
样例规则

规则的第一部分定义 “触发” 规则的条件。

  • 定义部分由许多语句集组成,这些语句集根据规则可用的信息定义新的变量(通常以参数的形式传递到它将在其中运行的流中)。在某些情况下信息可能不可用,此时将不触发规则。如果信息可用,那么规则将在条件得到满足时被触发。
  • 条件部分由一个 “if” 子句组成。如果这个子句的值为 true,那么将执行动作部分的 “then” 子句,如果它的值为 false,将执行 “else” 子句(如果有的话)。
  • 动作部分定义根据条件子句的结果执行的子句。

注意,规则中的词汇和所有变量的类型都在 BOM 中定义,BOM 反过来关联到通过 XOM 与 Business Application 交换的参数。

场景

这个小节将确认本文介绍的集成支持的关键业务场景。

使用 Impact 为 Business Rule Management System 提供 IT Operations 数据访问

本文描述的主要场景是为业务用户提供 IT Operations 数据,从而使他们能够更好地管理业务应用程序,并向 IT Operations 提供反馈以获得更好的支持。在这个场景中 Impact 管理并增强 IT Operations 数据并提供对 BRMS (JRules) 的访问,使业务用户能够表达其策略和规则。

本文介绍了两种数据访问模式 —— 在下面的场景小节中将更加详细地描述它们。

  1. 启动 Impact – 在本例中,一个 IT 事件触发对 BRMS 的调用以及随后对 Business User 规则的应用。这将导致为与业务上下文相关的 IT Operations 数据增加信息。
  2. 启动 BRMS – 在本例中,一个 Business 事件或事务发生,它需要访问 IT Operations 数据以做出有效的业务决策。

尽管有许多集成选项可供选择(见下一节),但是在 Impact 中这两种模式都使用相似的配置。

在任意集成场景中,BRMS 软件都可以在规则处理过程中使用 Impact Servers 访问来自不同数据源的不同数据。了解这些数据源是什么以及 BRMS 以什么方式获取它们非常重要。

在集成过程中需要执行许多步骤:

  • 在 Impact Server 中定义一个数据源。这决定了事件和 IT Operations 数据的出处。数据源通常是 Netcool / OMNIbus 表,但也可能包含其他可以通过 Impact 访问的数据库和系统。
  • 在 Impact Server 中定义一个数据类型。这决定了规则中的业务用户可以使用的业务词汇。
  • 在 Impact Server 中定义一个策略,用于运行查询和返回数据。在需要访问数据时将调用策略,并提供正确形式的信息以便在 Impact 和 BRMS 之间传递。
  • 定义何时发生数据访问。这就是各个场景的不同之处:
    • 调用策略场景以响应可以在 Impact 中配置的 IT 事件。然后策略增强 IT Operations 数据并将其传递到 BRMS。Impact 可以使用从 BRMS 传递回来的信息。
    • BRMS 场景使用 Impact Server 提供的 Web Services 接口来执行策略和获取用于其业务规则的 IT Operations 数据。

Impact Server 还通过 Restful API 公开数据。Restful API 提供一种方式来从已配置的数据源和数据类型获取数据。在这个场景中,终端用户不需要定义策略来获取数据。他们可以使用自己喜欢的 HTTP 客户端来获取数据。数据的返回格式可以是 JSON 或 XML。下一节将不介绍这种可选模式。

使用 BRMS 扩展 Impact 策略

这个场景反映了这样一种情况,业务用户对由受 Tivoli Netcool/Impact 支持的 IT Operations 管理的警告和事件感兴趣。下图描绘了该场景。

图 10. 场景 1 - IT 事件影响业务决策
场景 1 - IT 事件影响业务决策
场景 1 - IT 事件影响业务决策

业务用户有许多用于库存交易的业务应用程序。这些业务应用程序由以下部分组成:

  • 一个允许交易商代替其客户售出库存的库存交易应用程序
  • 在交易方之间结算款项的交易履行过程。

业务用户通过业务规则管理业务应用程序,而业务规则通过运用策略决定谁可以进行哪些交易并保证维护平衡的投资组合。这些应用程序集成了 Rule Execution 服务器,使业务用户能够根据需求快速地修改规则。

  • 用来收集和比较来自 IT 基础架构和已安装应用程序的警告的 Tivoli Netcool OMNIbus
  • 用来为报告、问题根源分析和前台帮助定义策略的 Netcool Impact。

在这个场景中,当数据中心发生故障时要给业务用户发出通知,从而让他了解故障是否会影响到交易履行过程。下图中用红色箭头来表示该场景中采取的步骤。

  1. 在 Netcool OMNIbus 探测器监视下的数据中心离线时将导致生成一个新的警告。
  2. Netcool OMNIbus Object Stores 将警告发送给 Impact,警告将在此处触发表明需要采取什么行动的策略。
  3. 在这个场景中将通过扩展 Impact Policy 来调用部署在 Rule Execution Server 中的 Decision Service。它还从其他与数据中心关联的警告添加信息。
  4. 然后,Rule Execution Server 调用这些由业务用户定义的规则。这将定义任何指定的数据中心上的交易履行过程的依赖项,并且规则将根据警告的严重性决定是否需要向 Trade Fulfillment Process 发出新的警告。
  5. 如果需要发出新的警告(或者更新现有的警告),这将被发送回到 Impact 服务器,然后策略会将这一新信息添加到警告中并处理它。
  6. 然后,Impact 在 OMNIbus 储存库中为 Fulfillment Process 生成新的警告,该警告将向支持人员和 Fulfillment Process 用户发出发现业务问题的通知。

使用 BRMS 改善 IT 与业务之间的互操作性

在这个场景中,业务用户不希望依赖来自 IT Operations 的支持来考虑重要的警告,而是想要在业务应用程序中自动化该操作。如下图所示。

图 11. 场景 2 – 业务事件需要基础架构响应
场景 2 – 业务事件需要基础架构响应
场景 2 – 业务事件需要基础架构响应

在这个场景中,业务用户创建一条规则来确保将不接受任何存在未能完成的风险的交易。下图中用红色箭头来表示该场景中采取的步骤。

  1. 在交易应用程序中发生一桩交易,业务应用程序调用规则执行服务器来传入关于客户和买卖的库存的详细信息。
  2. 调用大量业务规则来评估客户或库存订单。此外,还触发一个规则来查找交易期间与 Trade Fulfillment Process 相关联的警告。可以从订单确定交易,以及调用一个在 BOM 中定义的方法来查询与该 Trade Fulfillment Process 相关联的警告。
  3. 通过 BOM 方法调用的 XOM 代码调用执行查询的 Impact 策略。
  4. 策略获取关于 Trade Fulfillment Process 的所有警告(包括在场景 1 中生成的任何警告)。这还可能包括流程直接提供的任何性能警告。
  5. 规则以获取到的警告为依据识别到交易可能会导致不可接受的风险,并将该结果传递给规则执行服务器。
  6. 然后,规则执行服务器将该规则(以及其他已触发的规则)的结果传回给应用程序,应用程序将该结果与用户关联起来,说明为什么交易不能继续进行;因为存在交易不能在可接受时间内完成的风险。

集成步骤介绍

这个小节解释如何通过集成 Impact 和 JRules 来实现前面小节所描述的场景。本小节的目标是允许业务用户定义规则,这些规则对来自 Tivoli Netcool 的 IT 事件起作用,从而使事件能够反映出对自身重要的情况。这样做还允许 IT Operations 更好地对业务用户的需求作出响应,以及持久化和管理业务用户在业务应用程序中使用的信息。下图使用绿色展示了第一个场景,使用蓝色展示了第二场景。

图 12. 实现场景的集成概览
实现场景的集成概览
实现场景的集成概览

本小节分步骤说明如何开发并调试有效的 Tivoli Netcool Impact 和 WebSphere ILOG BRMS 集成。首先要求用户已安装这两款产品。下面是需要经过的步骤:

  • 信息模型设计 – 如何基于来自 Netcool 的可用信息模型在规则中实现对业务用户公开的词汇表。
  • JRules Decision Service Realization – 如何实现可以从 Netcool/Impact Web Service DSA 调用的决策服务(HTDS),以及允许业务用户使用已定义词汇来表达规则。
  • 集成 Impact 和 JRules 决策服务 – 如何从 JRules Decision Service WSDL 生成 Web Service DSA 和 Impact 策略,然后根据 OMNIBus 调用 JRules 决策服务并获取响应。
  • Impact Policy Development 调用 JRules 决策服务 – 在调用 JRules 决策服务时提供 Impact 策略中所需的常见模式的例子。
  • 规则应用程序回调到 Impact – 描述 JRules 规则应用程序如何通过其 web 服务侦听器调用 Impact 策略,从而获得用于其业务规则中的警告信息。

信息模型设计

这个小节确认如何选择和指定模式。对于规则将要对其进行推断的 Netcool 警告和事件,JRules 将使用模式把它们转换为词汇。这个小节将设计用作本场景的基础的 XOM。

表结构

Netcool OMNIbus 和 Impact 使用的主要概念是警告。警告的定义在 ObjectServer 数据库中的 alerts.status 表进行。这个表的列或字段数超过 50 个。所有这些字段都可以在 XOM 中定义,这里将关注一些常用的基础字段。下表列出了一些重要的字段。

表 1. 警告状态表字段
列名类型字段描述及解释
SerialInteger由 OMNIbus 维护,用作特定服务器上的惟一密钥。它会自动更新。
IdentifierString用于识别特定的警告,以及用于消除针对同一状况的重复警告。
NodeString识别用于生成警告的受控实体。这可以是主机或设备的名称、服务名或其他惟一地标识受控实体的名称。
ManagerString收集和转发警告的探测器的名称。
AgentString探测器中的子管理器的名称。
AlertGroupString警告表示的失败类型的名称。
AlertKeyString警告表示的节点内部的受控对象的名称。
SeverityInteger表示警告的严重性的整数枚举。在 Netcool 事件显示中,这通常是彩色数字警告。
0: 清除(绿色)
1: 未确定
2: 警告
3: 小
4: 大
5: 严重(红色)
FirstOccurenceInteger警告创建的时间,以秒为单位(从 1970 年 1 月 1 日午夜开始)。
LastOccurenceInteger警告在探测器上的最后更新时间,以秒为单位(从 1970 年 1 月 1 日午夜开始)。
TypeInteger对警告的类型进行划分的整数枚举:
0: 未设置类型
1: 问题
2: 分辨率
........
11: 更加严重
12: 稍微严重
13: 信息
TallyInteger更新次数的计数,以及合并去除重复后的警告。

为了在可用于 Impact 和 JRules 的 XOM 中表示该表,我们需要决定将要使用的 XOM 的类型,以及考虑将要使用的调用机制。由于我们将要使用决策服务,因此需要定义一个 XML 模式来表示 XOM。这将是一个动态的 XOM。

在设计模式时还需要考虑字段的基数,因为将决定在 Impact 和 JRules 之间交换警告时是否通常需要一个值。在表中,除了日历字段(FirstOccurence,Last Occurrence)、Type 和 Serial 是可选的,所有其他字段都需要使用有效值。注意,对于字符串 "" 或空字符串都是可接受的值。

图 13. 警告的模式表示
警告的模式表示
警告的模式表示

除了考虑如何表示警告之外,我们还需要考虑任何将要传递给 Rule Application 的其他信息以对规则进行计算,以及将从规则获取到什么信息以确定响应内容。

规则的输入不仅包括更新的警告,还包括任何其他与同一节点相关联的警告。因此我们定义如下所示的 AlertEventInput 结构。

图 14. 用于规则处理的一组警告的模式表示
用于规则处理的一组警告的模式表示
用于规则处理的一组警告的模式表示

以类似的方式,我们获得的是一组需要创建、更新或删除的警告。

图 15. 规则处理返回的警告的模式表示
规则处理返回的警告的模式表示
规则处理返回的警告的模式表示

为了让场景保持简单,这些仅作为一个可选警告提供,但是在更加复杂的场景中,一个调用可能导致多个响应事件。

创建规则项目

下一个步骤是创建定义规则集的规则项目。在 Rule studio 中创建名为 OMNIBusAlertDecisionService 的规则项目。

图 16. 创建新的规则项目
创建新的规则项目
创建新的规则项目

选择 Standard Rule Project 并单击 Next。

图 17. 创建新项目(定义项目名)
创建新项目(定义项目名)
创建新项目(定义项目名)

输入项目名并按 Finish。规则项目和 Rule Project Map 一起显示。

导入 XOM

将步骤 3.1.1 中生成的模式导入到项目的根目录中。现在项目应该如下图所示:

图 18. 导入 XOM
导入 XOM
导入 XOM

选择 Import XOM 链接开始 BOM 定义。

图 19. 导入 XOM(基于模式)
导入 XOM(基于模式)

选择 Dynamic Execution Object Model (XSD) 并按 OK。

图 20. 导入 XOM(选择模式)
导入 XOM(选择模式)
导入 XOM(选择模式)

选择 Add XSD...

图 21. 选择 XSD 进行添加
选择 XSD 进行添加
选择 XSD 进行添加

选择复制到项目根目录下的模式并按 OK。

图 22. 导入 XSD 完成
导入 XSD 完成
导入 XSD 完成

检查将要使用的包和名称空间并按 OK。

创建 BOM

现在已经创建了 XOM,并且已准备好创建业务用户将要使用的词汇。现在的项目如下图所示:

图 23. 创建 BOM
创建 BOM
创建 BOM

现在启用了 Create BOM 链接。选择该链接。

图 24. 定义新的 BOM 条目
定义新的 BOM 条目
定义新的 BOM 条目

为 BOM 输入名称(或接受默认的名称 “model”),确保选择了 Create a BOM entry from a XOM,然后按 Next。

图 25. 浏览选择 XOM
浏览选择 XOM
浏览选择 XOM

按下 Browse XOM。

图 26. 选择先前创建的 XOM
选择先前创建的 XOM
选择先前创建的 XOM

选择在前一步骤中引用的模式并按 OK。

图 27. 从模式选择所需的类型
从模式选择所需的类型
从模式选择所需的类型

选择在 XOM 中定义的三种类型并按 Next。

图 28. 将 BOM 条目转变成词汇
将 BOM 条目转变成词汇
将 BOM 条目转变成词汇

检查默认的词汇包含哪些所需的内容并按 Finish。如果需要更改词汇,那么 BOM 在 Rule Studio 中是可见的,并且可以从 BOM 编辑器进行修改。

图 29. 浏览 BOM 以修改词汇
浏览 BOM 以修改词汇
浏览 BOM 以修改词汇

现在已经创建了 BOM 和默认的词汇。下一个步骤是创建一组初始规则并生成决策服务。

JRules 决策服务实现

这个小节阐述如何选择词汇化模式,以及使用可由 Impact 调用的初始规则集生成和测试 JRules 决策服务。

创建决策服务签名和参数

我们已经在 BOM 中定义了需要在决策服务中使用的输入和输出参数。BOM 定义类型和这些类型的词汇化,但是现在我们需要定义将用于与 Rule Application 通信的输入和输出参数。

在 Rule Project Map 中选择 Define parameters 链接。在出现的向导中按 Add 按钮并为如下所示的输入参数填充名词和词汇。将 Direction 设置为 IN。

图 30. 决策服务参数的定义 – 输入参数
决策服务参数的定义 – 输入参数
决策服务参数的定义 – 输入参数

选择 Type 下拉列表。

图 31. 选择参数的类型
选择参数的类型
选择参数的类型

查找所有以 Alert 开始的类型,将看到有三个 BOM 类型是可见的。选择 AlertEventInputType。注意,底部的 Array 复选框允许用户表明参数是这种类型的一个值还是数组(集合)。可选的集合形式是使用在 Java XOM 中声明的 java.util 类。在本例中不要选择该复选框。按 OK。

对 alertOut 参数 (AlertEventOutputType) 重复该过程,最后得到的结果如下图所示。

图 32. 决策服务参数的定义 - 输出参数
决策服务参数的定义 - 输出参数
决策服务参数的定义 - 输出参数

按 OK。

图 33. 决策服务参数定义完成
决策服务参数定义完成
决策服务参数定义完成

现在参数已经定义完成,它们将被添加到决策服务调用签名中。

创建决策服务规则包

现在我们需要创建一些包来存储规则。我们首先创建一个用来储存简单测试规则的包。可以在基础的集成完成之后再进一步发展该包。

在 Project Map 中选择 Add rule package 链接(或者选择 OMNIBusAlertDecisionService Rule Project 并从菜单选择 File > New > Rule Package)。

图 34. 创建规则包
创建规则包
创建规则包

输入包 AlertTestRules 的名称并按 FInish。

图 35. 规则包创建完成
规则包创建完成
规则包创建完成

现在已经在决策服务的 rules 文件夹创建了规则包。

创建决策服务规则流

这个小节将描述如何创建一个通过决策服务公开的新规则流。选择 Add rule flow 链接(或者选择 OMNIBusAlertDecisionService Rule Project,并从菜单选择 File > New > Ruleflow)。

图 36. 创建规则流
创建规则流
创建规则流

输入规则流的名称:“AlertRuleFlow”。按 Finish。 现在已经创建了空的 AlertRuleFlow 规则流,如下图所示。

图 37. 警告规则流创建完成
警告规则流创建完成
警告规则流创建完成

现在我们必须设置规则流。

  • 单击绿色的开始节点,然后单击 AlertRuleFlow 图创建一个开始节点。
  • 单击红色的 “结束” 节点,然后单击 AlertRuleFlow 图创建一个结束节点。
  • 从 Rule Explorer 将 AlertTestRule 包拖放到 AlertRuleFlow 图上。
  • 使用 “Transition” 链接将三个节点连接起来,这将得到一个如下图所示的规则流:
图 38. 建立规则流
建立规则流
建立规则流

这将导致在调用决策服务时可能执行包含在 AlertTestRules 包中的任意规则之一。

在这个阶段还需要完成最后一个步骤,以避免以后出现问题。输出参数 -alertOut 在默认情况下没有创建,因此需要在规则流的某个点上初始化它,这样规则才能引用它。此外,还可能出现未提供输入参数字段的情况,如果规则引用这些字段将导致 null 指针异常。

为了克服这些限制,通常需要在流的 Initial Task 部分添加一些初始化步骤。为此,请遵循以下步骤。

  • 步骤 1. 从 Outline 或 AlertRuleFlow 选择 Initial Task。
  • 步骤 2. 创建一个属性视图 - 选择 Menu – Windows > Show View > Other...
图 39. 在 Initial Tasks 中创建初始化行为
在 Initial Tasks 中创建初始化行为
在 Initial Tasks 中创建初始化行为

打开 General Folder 并选择 Properties View,然后按 OK。现在属性选项卡已经可用 - 将该选项卡移动到 Eclipse 内部的合适框架中并选择 IRL 复选框。

  • 步骤 3. 输入 IRL 代码初始化输入和输出参数,如下图所示。
图 40. Initial Action 中的初始化代码
Initial Action 中的初始化代码
Initial Action 中的初始化代码

这些代码执行三个初始化步骤:

  • 它创建一个可以传递回到调用应用程序的 alertOut 实例。
  • 它创建并填充 alertOut 的 NewAlert 字段。
  • 如果 alertIn 的 Type 字段未设置,则将其设置为 0。

创建初始的规则集

现在,我们希望在包中创建初始的规则集,该规则集使用将传递给决策服务的词汇和参数。我们将创建三个测试规则:

  • AlertTestUpdate – 在规则被触发时更新警告
  • AlertTestDelete – 在规则被触发时删除警告
  • AlertTestCreate – 在规则被触发时创建新的警告

在 Rule Project Map 中选择 Add business Rule 链接(或选择 OMNIBusAlertDecisionService Rule Project 并从菜单选择 File > New > Business Rule)。

图 41. 创建规则 - 创建并命名规则
创建规则 - 创建并命名规则
创建规则 - 创建并命名规则

浏览并选择 AlertTestRules 包,然后输入规则的名称:“AlertTestUpdate”。然后按 Finish。双击生成的 AlertTestUpdate 选项卡,在 Intellirule 视图中展开规则。首先,我们将设置定义部分。

  • 先输入 “definitions” - 在输入过程中按 ctrl + 空格将出现自动完成选项。

继续使用自动完成选项:

  • Select: set <Variable>
  • Type: inputAlert
  • Select: to <binding type>
  • Select: the main alert of <an alert event input type>
  • Select: alertIn
  • Select: ;

这将导致出现以下界面:

图 42. 规则创建 – Intellirule 编辑器
规则创建 – Intellirule 编辑器
规则创建 – Intellirule 编辑器

由于 “then” 子句缺失,这导致一个错误。继续使用 Intellirule 编辑器填充规则,直至得到如下所示的代码:

图 43. 规则创建 – 规则完成
规则创建 – 规则完成
规则创建 – 规则完成

右键单击并按 save。该规则将检查摘要是否尚未包含词汇 “JRules Checked”,如果是这样,它将把该词汇作为前缀附加到摘要。然后它表示应该通过设置相应的 “UpdateAlert” 字段来更新警告,以匹配修改之后的警告。这将为每条尚未包含 “JRules Checked” 的摘要附加该词汇。对其他两条规则重复该过程,如下图所示:

图 44. 创建 Alert Test Create 规则
创建 Alert Test Create 规则
创建 Alert Test Create 规则

这条规则将为严重性为 4 的所有传入警告创建新的警告。

图 45. 创建 Alert Test Delete 规则
创建 Alert Test Delete 规则
创建 Alert Test Delete 规则

这将删除任何严重性为 0 的警告(已清除)。

在 Visual Studio 中调试规则集

这个小节描述如何在与其他系统或部署隔离的情况下在 Rule Studio 中测试规则集。从 Menu 选择 Run > Open Run Dialog。

图 46. 在 Rule Studio 中调试规则
在 Rule Studio 中调试规则
在 Rule Studio 中调试规则

在对话框中选择 Rule Project - 右键单击并选择 new。

图 47. 调试规则(续)
调试规则(续)
调试规则(续)

使用 browse 按钮选择 OMNIBusAlertDecisionService 规则项目,并设置匹配的配置名。勾选 stop at first rule statement 复选框。然后按 Apply。浏览到 Parameters and arguments 选项卡。现在我们将输入一些测试参数,并将其传递给触发 AlertTestUpdate 规则的规则。选择 alertIn parameter 并按 EditValue...

图 48. 为输入参数提供值
为输入参数提供值
为输入参数提供值

选择 Function body 复选框并输入代码初始化输入警告。按 OK。

图 49. 输入参数(续)
输入参数(续)
输入参数(续)

按下 Apply。从这里开始可以运行规则集了。按下 Run。这将在 Console 窗口中显示已触发的规则的打印语句输出。

图 50. 在调试环境中的规则执行
在调试环境中的规则执行
在调试环境中的规则执行

如果您想要调试代码,请从菜单选择 Run > Open Debug Dialog...,然后选择 OMNIBUSAlertDecisionService 配置并按 Debug。随后您将收到关于确认切换到调试透视图的警告。

图 51. 透视图切换警告
透视图切换警告
透视图切换警告

按 Yes 进入 Debug 透视图。

图 52. 规则调试窗口 - 最初的任务调试
规则调试窗口 - 最初的任务调试
规则调试窗口 - 最初的任务调试

在调试透视图中代码将在规则代码的第一部分停止 - 这是最初任务中执行的初始化部分。inputAlert 在 variables 窗口中也是可见的。随着运行至代码主体,规则将被执行/测试,并且其定义和 if 子句的值为 true 的任何规则将出现在如下图所示的调试窗口中。

图 53. 规则调试窗口 - 规则调试
规则调试窗口 - 规则调试
规则调试窗口 - 规则调试

可以在 Run Dialogs 中输入不同的参数来测试不同的规则。

创建 Rule Application 和决策服务

在以决策服务的形式测试规则集之前,我们必须先创建一个 Rule Application 来包含它。在 Rule Project Map 中选择 “Create RuleApp project” 链接(或选择 OMNIBusAlertDecisionService Rule Project 并从菜单选择 File > New > Project...,然后选择 RuleApp Project)。

图 54. 创建 Rule Application
创建 Rule Application
创建 Rule Application

在 Project name 字段输入 IMPACTRuleApp 并按 next。

图 55. 创建 Rule Application - 添加规则项目
创建 Rule Application - 添加规则项目
创建 Rule Application - 添加规则项目

在下一个界面中确保选择了 OMNIBusAlertDecisionService Rule 项目并按 Finish。现在创建了可部署和测试的 RuleApp。

图 56. Rule Application 完成
Rule Application 完成
Rule Application 完成

配置 Rule Execution Server

这个场景将在样例服务器中 Tomcat 上使用默认的 RES 和 RTS 部署,对于更加复杂的场景则需要部署到 WebSphere Application Server。本文不讨论 Rule Execution Server 和 Rule Team server 的各种安装和配置选项,因此 url 和细节配置将不相同。查看信息中心的 安装 部分获取更多信息。

最简单的部署是将 Rule Application 从 Rule team server 直接部署到 Rule Execution server。启动样例服务器(或 Rule Execution Server)。现在我们需要创建 Rule Studio 能够识别的 Rule Execution Server 配置。在菜单中选择 File > New > Other...

图 57. Execution Server 配置
Execution Server 配置
Execution Server 配置

在 Rule Studio 文件夹选择 Rule Execution Server Configuration 并按 Next。

图 58. 创建新的 Execution Server Configuration
创建新的 Execution Server Configuration
创建新的 Execution Server Configuration

在下一个界面中按 Create a new configuration project。

图 59. 命名新的 Execution Server Configuration
命名新的 Execution Server Configuration
命名新的 Execution Server Configuration

保留选中默认选择不变并按 Finish。

图 60. 为项目选择新的 Execution Server Configuration
为项目选择新的 Execution Server Configuration
为项目选择新的 Execution Server Configuration

现在选择该项目以包含配置,然后按 Next。

图 61. 定义 Execution Server RES 驻留环境
定义 Execution Server RES 驻留环境
定义 Execution Server RES 驻留环境

在下一个界面中选择 application server hosting RES(在本例中为 Tomcat)并按 next。

图 62. Execution Server Configuration - 定义 RES 驻留参数
Execution Server Configuration - 定义 RES 驻留参数
Execution Server Configuration - 定义 RES 驻留参数

在 Server configuration 中导航到 Installation 目录(见上图)- 在这里为 Tomcat 设置默认的部署目录。它将为 RES 创建默认的 URL。登录名和密码都默认为 resAdmin。按 Test connection。您将收到以下响应:

图 63. 测试到新的 Execution Server Configuration 的连接
测试到新的 Execution Server Configuration 的连接

如果连接不成功,请检查服务器是否运行,并且输入了正确的字符。连接失败消息通常能够反映出问题的根源。如果连接成功,按 Next。

图 64. 选择部署到 RES 控制台
选择部署到 RES 控制台
选择部署到 RES 控制台

在最后的界面中确保选择了 “to the Rule Execution Server Console” 单选按钮并按 Finish。检查是否能够通过 “Open the Rule Execution Server link” 登录 Rule 执行服务器,并使用 resAdmin/resAdmin 登录。现在已经准备好将 RuleApp 部署到 RES。

图 65. Rule Execution Server 控制台
Rule Execution Server 控制台
Rule Execution Server 控制台

部署决策服务

在 Rule Studio 中通过双击 MPACTRuleApp Project 的 archive.xml 文件打开 IMPACTRuleApp。

图 66. 部署决策服务
部署决策服务
部署决策服务

然后选择 “Deploy a RuleApp to one or more Rule Execution Servers” 链接。

图 67. 部署决策服务 - 定义版本策略
部署决策服务 - 定义版本策略
部署决策服务 - 定义版本策略

选择 Replace RuleApp version 部署类型 - 这意味着在部署新的版本时不需要改变用于决策服务的 url。

图 68. 选择需要部署的 Execution Server Configuration
选择需要部署的 Execution Server Configuration
选择需要部署的 Execution Server Configuration

选择 Tomcat 配置(或先前的配置设置)并按 Finish。部署结果显示在 Console 面板中。导航到 Rule Execution Server 选项卡,打开 Explorer 查看规则集。现在可以看到决策服务的结构包含了输入和输出参数。

图 69. 验证部署
验证部署
验证部署

使用 Web Services Explorer 测试决策服务

我们需要测试 Rule Execution Server 提供的决策服务 web 服务。选择 “Get HTDS WSDL for the ruleset version”,右键单击并选择 Save as。

图 70. 从 Execution Server 获取 WSDL
从 Execution Server 获取 WSDL
从 Execution Server 获取 WSDL

在 Rule Studio 工作区中导航到 decision service 目录,选择 Save as 类型:All Files,并输入用于 WSDL 的完整文件名。在 Rule studio 中选择 OMNIBusAlertDecisionService 项目,然后右键单击并选择 refresh。确认出现 OMNIBusAlertDecisionService.wsdl 文件。切换到 Java Perspective。选择 OMNIBusAlertDecisionService.wsdl,然后右键单击并选择 Web Services > Test with Web Services Explorer。

图 71. 使用 Web services explorer 进行测试
使用 Web services explorer 进行测试
使用 Web services explorer 进行测试

选择 “executeDecisionService”。这是 web 服务中将调用规则集的操作。

图 72. 通过 Explorer 定义输入参数
通过 Explorer 定义输入参数
通过 Explorer 定义输入参数

输入之前用来测试规则的参数:
Node: Node
Severity: 3
Summary: Summary
Tally: 1

注意,需要设置 Tally,因为它不是可选字段。如果未为该字段提供值,客户端验证将失败。在 Actions Pane 的底部按 Go 按钮。

图 73. 来自 Explorer 的输出参数响应
来自 Explorer 的输出参数响应
来自 Explorer 的输出参数响应

可以在主体部分看到来自 web 服务的响应。在本例中,我们将 UpdateAlert 设置为复制提供的字段,但将 “JRules Checked” 附加到 Summary 的开头。这种测试方法能够正常工作,因为 Rule Execution Server 没有生成异常,并且客户端为 Web services Explorer。

使用 TCP/IP Monitor 测试决策服务

与 Netcool 集成使得内部运行更加难以观察。在本例中值得尝试使用 Eclipse 提供的 TCP/IP Monitor。要设置 TCP/IP Monitor,通过菜单 Tools > Preferences 导航到它的配置。

图 74. TCP/IP Monitor 设置
TCP/IP Monitor 设置
TCP/IP Monitor 设置

在监视器中添加一个监视器代理 localhost:8080,它是通过本地端口 8081 进行调用的。重新设置 web service explorer 以使用 localhost:8081。

图 75. 通过 TCP/IP Monitor 的 Web services Explorer
通过 TCP/IP Monitor 的 Web services Explorer
通过 TCP/IP Monitor 的 Web services Explorer

此次在运行 Web service explorer 时可以检查交互 XML。

图 76. 使用 TCP/IP monitor 检查 Input / Output
使用 TCP/IP monitor 检查 Input / Output
使用 TCP/IP monitor 检查 Input / Output

这可用于记录 Impact 和 JRules 之间的每次交互。此外还需要注意,每次交互的时间也被记录下来,通过将该数据与来自 Rule Execution Server 的可用决策服务和规则集统计数据相比较可以了解处理延迟。

创建响应 IT 事件的 Business Dependency 规则

这个小节将介绍如何扩展支持场景 1 所需的规则。这涉及到添加一个规则,以在驻留 Fulfillment 应用程序的数据中心离线时为每个 Fulfillment 应用程序发出一个新的警告。

将 Business Dependency 规则添加到 Alert Test Rules 包中,其形式如下所示。

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;

这个规则使用定义部分来识别数据中心什么时候离线。它通过检查节点名是否包含数据中心来识别它是不是数据中心。如果警告语义被认可,将可使用其他机制。

这个规则还引入了规则变量集的概念。它们是可以在规则之间共享的变量(作为流的一部分),并不会作为参数传入。交换变量是在 AlertTestRules Package 中定义的 Exchange Rule 变量集中的变量。它的作用是存储数据中心的位置,该位置也可能是数据中心支持的 Fulfillment 应用程序的位置。为了初始化该变量,我们需要向在规则流的初始任务中引入的 IRL 添加一些代码。这一修改如下所示。

图 77. 更新初始任务以识别 “Exchange” 规则变量
更新初始任务以识别 “Exchange” 规则变量
更新初始任务以识别 “Exchange” 规则变量

这将把 Exchange 创建为数据中心名称的第一部分,从而在引用它时可随时用于规则中。

集成 Impact 和 JRules 决策服务

这个小节描述如何创建一个能够使用我们已开发的决策服务的 Impact 策略。本场景的这一部分假设我们已经将 Tivoli Netcool Impact 安装在 JRules 所在的主机上并使用默认设置,并且 Impact 应用服务器已经运行并连接到默认的 Netcool OMNIbus ObjectStore。

导入决策服务 WSDL 文件

Netcool Impact 提供一个向导来自动创建一个调用 web 服务的策略。在这个小节中,我们将描述创建该策略的步骤,并从 Impact 内部调用决策服务。

第一步是登录到 Impact 用户界面,如下图所示。

图 78. 登录到 Impact Server
登录到 Impact Server
登录到 Impact Server

默认的用户名和密码为 admin/netcool。

图 79. Impact Server 控制台
Impact Server 控制台
Impact Server 控制台

打开向导部分并选择 Web Services。

图 80. Web services 向导
Web services 向导
Web services 向导

输入策略的名称 - 我们最初使用 OMNIBusAlertDecisionServicePolicy 作为最初集成的测试策略。按 Next。

图 81. Web Services 向导步骤 2
Web Services 向导步骤 2
Web Services 向导步骤 2

输入到 WSDL 的路径,该 WSDL 可从 Rule Execution server 下载。为将要生成以供策略引用的 Java 代码包输入名称。按 Next。

图 82. Web Services 向导步骤 3
Web Services 向导步骤 3
Web Services 向导步骤 3

检查 web 服务的名称、端口类型和方法,它们必须与使用 web service explorer 时看到的名称、端口类型和方法匹配。按 Next。下一个步骤要长一些,因为 Impact 将解析 WSDL 并编译 Java 以生成一个可以从策略内部调用的包。

图 83. 定义样例输入步骤 4
定义样例输入步骤 4
定义样例输入步骤 4

下一个界面为需要在策略中生成的代码提供选项。如果我们输入与在 Rule Studio 中测试所用的相同细节,将很快能够看到如何从 Impact 调用相同的规则。此外,我们输入一个 “current” 条目来获取如何转换日期和时间的说明,并为相关的警告提供样例,以了解如何将相关联的信息发送给决策服务。

图 84. Web Services 向导步骤 5
Web Services 向导步骤 5
Web Services 向导步骤 5

在下一个界面中选择编辑框并将端口从 8080 更改为 8081。这将通过 tcpip 监视器路由任何决策服务调用,从而调试到每个交互。按 Next。

图 85. Web Services 向导步骤 6
Web Services 向导步骤 6
Web Services 向导步骤 6

这时将出现一个汇总界面。按 Finish。

图 86. 样例策略
样例策略
样例策略

现在主控制台打开了一个已创建的策略。按 Save 图标确保保存策略。下面显示了生成的策略:

//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);

现在我们尝试运行该策略。由于保存了策略,它现在出现在导航栏的 Policies 部分。但是已生成的 jar 文件还未在类路径中。这个文件位于以下目录中:

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

使用决策服务测试 Impact 策略。

这是一个静态测试,用于检查通过运行策略可以调用 Rules,并获得我们在其他步骤中完成的响应。在 Impact 中导航到策略。

图 87. 测试 Impact 策略
测试 Impact 策略
测试 Impact 策略

选择绿色箭头运行策略。

图 88. 执行策略
执行策略
执行策略

按 Execute 按钮。

图 89. 出现错误时的错误消息
出现错误时的错误消息
出现错误时的错误消息

如果像此处一样发生错误,则需要进行调试。第一步是查看 Impact 中的策略日志 - 这里提供来自策略的日志说明。要查看策略日志,单击 Policy Logger 的 view Log 按钮。

图 90. 策略日志
策略日志
策略日志

这表明已经发出对决策服务的调用,但未发现任何响应。

可以在以下目录的 Netcool 日志中看到更多细节:
C:\IBM\Tivoli\Netcool\log
C:\IBM\Tivoli\Netcool\impact\log

查看 tcpip 监视器日志也可能了解到出现了什么问题。

图 91. 使用 TCP/IP Monitor 进行检查
使用 TCP/IP Monitor 进行检查
使用 TCP/IP Monitor 进行检查

在本例中将抛出异常,因为 web service xml 中未出现一些对 alertIn 而言是必要的元素。在针对决策服务的 Rule Execution server 日志中也可以看到一样的信息。

在 Rule Execution server 中导航到 Ruleset。

图 92. 使用 Rule Execution Server 日志进行检查
使用 Rule Execution Server 日志进行检查
使用 Rule Execution Server 日志进行检查

选择 View Execution Units 并展开警告列表。

图 93. Rule Execution Server – 执行单元
Rule Execution Server – 执行单元
Rule Execution Server – 执行单元

选择显示错误的 localhost 执行单元并展开相关的错误消息。

图 94. Execution Unit 消息
Execution Unit 消息
Execution Unit 消息

然后将显示来自 JRules 透视图的异常的原因。要修复问题我们将通过修改策略来设置这些元素。下面的策略中用黑体显示了这些元素。

//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);

保存并重新执行策略。

图 95. 重新执行策略
重新执行策略
重新执行策略

这显示策略正确执行。查看 tcpip 显示完整的交互。

图 96. 使用 TCP/IP Monitor 进行验证
使用 TCP/IP Monitor 进行验证
使用 TCP/IP Monitor 进行验证

查看策略日志显示响应对策略可用。

图 97. 策略日志
策略日志
策略日志

这完整地显示了 Impact 策略和 JRules Rule Application 之间的交互。

将 Impact 策略配置为响应 IT 事件

下一个步骤是创建一个新的 Impact 策略来响应来自 Netcool OMNIbus Probes 的 IT 事件,从而实现对场景 1 的支持。我们首先手动创建一个策略。在 Policies 选项卡中,选择 Custom 模板并按 + 号。

图 98. 创建新的策略
创建新的策略
创建新的策略

为策略输入名称(JRulesDecisonServicePolicy)并通过一些日志记录来检查什么时候调用它。保存策略。然后最好检查策略的运行情况并查看 Policy logger 查找预期的输出。现在我们需要在 Impact 中设置服务来将 IT 事件发送给该策略。为此我们需要基于 OMNIbus Event 创建服务。

在导航器中展开 Services 选项卡,并从下拉列表中选择 Type: of OMNIbusEventReader 并按 + 号开始向导。

图 99. 创建事件阅读器服务
创建事件阅读器服务
创建事件阅读器服务

在第一个选项卡中提供一个名称并设置轮询时间间隔,该时间间隔定义 Impact 执行查询之间的时差。这将定义 Impact 查找新的或更新的事件的频率。导航到 EventMapping 选项卡。

图 100. 创建事件映射
创建事件映射
创建事件映射

在这个选项卡中勾选 “Get updated events” - 这意味着对满足过滤器标准的警告的更新也将传递给决策服务策略。注意,如果事件删除对规则决策服务影响重大,那么应该勾选 “Run policy on deletes” 复选框。这将需要定义新的策略来向 Rule Application 表明事件已被删除。这未包含在当前的例子中。按 New Mapping 按钮。

图 101. 创建事件映射(续)
创建事件映射(续)
创建事件映射(续)

在这个界面中,输入一个过滤器表达式来确定将哪些事件发送给策略。在本例中,我们将使用 Simnet 探测器(见参考资料 11)来生成事件,从而将所有 Simnet 事件都发送给 JRules 策略。在 “Policy to Run” 字段中,通过下拉列表选择刚才创建的 JRulesDecisonServicePolicy。

将策略设置为 active。此时,有必要按 Analyze Filter 来检查语法是否正确,并看看是否有其他策略会与该过滤器条件重叠。按 OK。

图 102. 将策略关联到事件过滤器
将策略关联到事件过滤器
将策略关联到事件过滤器

现在可以在 Event Mapping Tab 中看到过滤器和策略映射。按 OK 保存 Event Reader 配置。为了进行测试,我们还需要执行几个步骤,这里将简要进行描述。修改 RulesDecisionServicePolicy 打印出接收到的 Event。

log("Starting JRulesDecisionServicePolicy");

log("Event received: " + EventContainer);

log("Finishing JRulesDecisionServicePolicy");

按 Service 状态面板上的绿色箭头开始 JRulesEventReader。

启动用于生成事件的 SIMNET 探测器。为了反映这里使用的场景,我们对探测器的标准配置稍微作了改动。这将影响到生成的节点和事件。

simnet.def 文件定义将要反映的场景。这将为每个条目定义 3 个属性。

  1. 节点的名称。
  2. 影响受节点支持的 Agent、AlertGroup、Summary 和警告处理的代码。
    • 0. Link Up / Down - 用于表示链接的在线/离线
    • 1. Machine Up/Down - 用于表示数据中心的在线/离线
    • 2. Disk space - 用于表示 Application 空间利用
    • 3. Port Error - 用于表示在应用程序或链接上重置的端口
  3. 百分号表明可能发出警告。
表 2. Simnet 定义
节点名模型代码事件可能性
London-Paris0 (Link)1
Paris-NewYork0 (Link)10
NewYork-London0 (Link)5
London_Datacenter1 (Machine)1
NewYork_Datacenter1 (Machine)10
Paris_Datacenter1 (Machine)5
London_Stock_Trading3 (Port)1
Paris_Stock_Trading3 (Port)5
NewYork_Stock_Trading 3 (Port)5
London_Trade_Fulfillment2 (Disk Space)1
Paris_Trade_Fulfillmentt2 (Disk Space)10
NewYork_Trade_Fulfillment2 (Disk Space)5

现在查看策略日志应该会看到为每个 SIMNET 事件或更新调用了 JRulesDecisionServicePolicy。

图 103. 决策服务策略的策略日志
决策服务策略的策略日志
决策服务策略的策略日志

这里的日志显示策略处理了三个完整的事件:
NewYork_London Link 出现
Paris_Stock_Trading 应用程序经过端口重置
NewYork_Stock_Trading 应用程序经过端口重置

注意,在本例中修改了 simnet.rules 文件以更好地与场景匹配,但不需要这样做也能演示或测试集成。

调用 JRules 决策服务的 Impact 策略开发

现在我们已经具备从 Impact 策略调用 JRules 决策服务的能力,并且拥有一个由 IT Operations 事件调用的 Impact 策略。这个小节描述如何编写调用 JRules 决策服务的 Impact 策略,以及如何响应可能发生的不同响应。

将 JRules 决策服务集成到 Impact 策略中

这个小节将划分成许多更小的小节,它们分别介绍集成的各个方面。划分出来的每个小节都是 JRULES_LIBRARY 策略中的一个函数。将从 JRulesDecisionServicePolicy 策略调用这些函数以提供清晰的结构。下面给出了该策略的完整结构。

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';
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 ...: "); 
//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");

随后的小节将采用特定的库函数,并描述它是如何工作的。

将事件发送给决策服务

第一步是接受事件中提供的 EventContainer,并将其映射到提供给决策服务的 MainAlert。下面给出了策略中的代码以及库函数。

//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);

首先创建用 WSDL 定义的主要请求,并且等到获得主要警告之后才创建子对象的结构。这个 _MainAlert 中的字段然后由 PopulateJRULESAlert 通过 EventContainer 进行填充,如下所示。

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;
}

注意,这种方法将把 XOM 中所需的所有字段设置为一个值,从而避免任何 web 服务解析异常。

添加相关的警告

基于规则的决策需要的信息通常比包含在事件中的信息还要多,因此本例还传入针对相同节点的任意其他警告。策略仅识别节点名,然后将它和 _AlertEventInput(包含 RelatedAlerts)传递给 PopulateJRULESRelatedAlerts 函数。

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

库函数使用 Alerts 数据源(NCOMS Object Store 上的默认源设置)搜索任何警告。

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;
        }
    }
}

注意,该函数将排除触发策略的事件,因为它已通过 MainAlert 提供。查找到的每个警告都导致生成一个使用 PopulateJRULESAlert 函数(如前所述)进行填充的新 RelatedAlert。

调用决策服务

这个小节描述如何实际地设置参数和端点等,并对决策服务进行调用。这是 Web Service 向导为我们生成的代码。注意,对端点的任何更改都要从这里输入,除非它们被作为策略属性提供。

//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);

获取来自决策服务的响应

下一个小节演示如何获得来自决策服务的三种不同响应。

 //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 );
}

每个响应都由独立的库函数处理,下面的几个小节对它们进行介绍。

更新警告

下面给出的库函数显示了如何在 Impact 中更新警告。

Function UpdateAlertFromJRULES( jrulesAlert ) {
    AlertsToUpdate = GetByFilter('Alerts', 
        "(Identifier='" + jrulesAlert.Identifier + "')", false);
    Num = length(AlertsToUpdate); 
    if ( Num > 0 ) {
        oldAlert = AlertsToUpdate[0];
        Alert = NewEvent("JRulesEventReader");
        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 );
    }
}

注意,首先获取原始内容,然后使用从 JRules 返回的内容进行更新。如果能够将需要更新的事件限制为 mainEvent,那么可以使用 EventContainer 代替 Alert,并且不需要执行任何查询或复制。这里使用了两个独立的库函数。

Copy 函数将字段从获取到的数据项复制到本地 Alert:

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;
}

来自 JRules 的更新从决策服务复制所有提供的字段。

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; }
}

这个函数仅更新从 JRules 提供的字段。

删除警告

这个例子展示如何删除决策服务指示出的警告。它首先通过检查标识符确保警告存在。

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);
    }
}

创建新的警告

这个例子展示如何创建一个的新警告,使之类似于决策服务指示出的警告。

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 );
}

这也使用 PopulateAlertFromJRULES 函数来填充通过 JRules 提供的字段。

Rule Application 回调至 Impact

这个小节从高级层面概述使用基于 Netcool 内部信息的规则的业务应用程序。这需要对 Impact 执行查询。下面描述了以上场景。

业务应用程序和规则

交易应用程序提供许多规则,其中包括依赖于警告状态的规则。下面对这些规则进行了总结,其中列出了包/规则名。许多规则是任意的并用作样例,使用 Rule Team 服务器的业务用户可以更改它们,但它们在此处的目的是演示业务应用程序上下文。在每个规则中都提供 Pending/Blocked/Rejected 状态之一及其原因。

CheckAmount/Order Amount – 提供关于交易价值的规则。

	the amount of order is less than 100,000 

	set the status of report to "Pending" ;
	set the reasons of report to "Customer Preferences" ;

CheckCurrency/CurrencyRestriction – 提供基于订单的 currency 字段的规则。

	the currency of order is "Euro" 

	set the status of report to "Rejected" ;
	set the reasons of report to "Customer Preferences" ;

CheckCustomerName/BadClients – 提供基于请求交易的客户的规则。

	the name of customer is "John Smith" 

	set the status of report to "Rejected" ;
	set the reasons of report to "Bad Client" ;

CheckStock/StockName – 提供基于交易库存的规则。

    the stock of order is "Company X" 

	set the status of report to "Blocked" ;
	set the reasons of report to "Black Listed Stocks" ;

IT 依赖项规则

这个小节介绍如何将 IT 依赖项引入到业务规则中。

CheckFulfillmentRisk - 检查确保 Fulfillment Application 与交易相关联,其中将要进行的交易未出现任何可能损害交易完成的警告。

set exchange to the exchange of order ;
   set risks to 
    impact client.queryAlerts("Node", exchange+"_FulfillmentApplication");   
there is at least one risk alert 
    in risks where the severity of this risk alert is one of { "3","4","5", "6" },	  
 
	set the status of report to "Rejected" ;
	set the reasons of report to "Trade Fulfillment Risk"  ;

这个规则首先提取交易将要使用的汇率,从而识别将要使用的特定实现应用程序。然后,规则使用通过 “impact client” 进行词汇化的 Java 类执行查询,并公开名为 “queryAlerts” 的静态方法。这个方法有两个属性。

  • 警告的字段将用于查询中 - “Node
  • 在查询中使用的字段的值 - exchange+"_FulfillmentApplication"

找到的任何警告都放入到 risks 集合中。

然后,条件句(if)在 risks 集合中查看是否出现警告,如果出现,看是否有严重性级别大于 3 的警告。以这种方式执行严重性比较可能比较笨重,但是在本例中严重性被映射到包含代码的字符串中。业务用户最好有一个词汇化的枚举,它能表明严重性代码的意思,并且这很容易在 XOM 到 BOM 的映射中执行。

如果以上定义的条件得到满足,将触发规则并拒绝交易,因为存在不能完成交易的巨大风险。

Impact 客户端 XOM 和 BOM

规则调用的 Impact 客户端是一个调用 Impact web 服务的 Java XOM。它可能被编写为使用上述的任何其他机制。请看下面的屏幕截图:

图 104. 构成 Impact 客户端的 Java XoM 和 BOM
构成 Impact 客户端的 Java XoM 和 BOM
构成 Impact 客户端的 Java XoM 和 BOM

ImpactClient 类提供该方法的一个实现来隐藏通过 web 服务调用 Impact 的更加复杂方面。

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
		int n = client.alerts.size();
		RiskAlert[] risks = new RiskAlert[n];
		for (int i = 0; i < n; i++) {
			risks[i] = client.alerts.get(new Integer(i));
		}
		return risks;
	}

在这里,两个重要的步骤是:client.connect() – 这通过使用 web 服务登录操作进行登录来与 Impact 建立会话。

public void connect() {
		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() – 对查询字段和值使用本地缓存值来实际执行查询。

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();

以上的代码显示了为在规则中指定的查询字段和查询值设置的 web 服务参数。

listener.runPolicy 调用传入通过登录(lid)创建的会话令牌、要运行的 Impact 策略的名称(“ExternalAlertQuery”)和参数。获得的结果是一个名值队列表。这是 Impact web 服务的局限性,因此需要使用代码来识别警告的数量,以及在把 RiskAlert 数组传回给 Rule Application 之前将每个警告的字段与正确的警告记录相关联。

Impact 外部警告查询策略

当 Impact web 服务被 Rule Application 调用时,显示的 Impact 策略正在运行。这相对简单,但确实需要为结果提供如下所示的简化结构。这是一种非常简单的方法,它仅支持 3 个结果。

log("****ExternalAlertQuery*****");
log("Query:  " + QUERYFIELD + " = " + QUERYVALUE  );

Alerts = GetByFilter('Alerts', "("+QUERYFIELD + "='" +QUERYVALUE + "')", false);

NumAlerts = length( 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); 
}

在 web 服务中定义的两个参数 QUERYFIELD 和 QUERYVALUE 在策略中作为已命名参数使用。

策略对根据默认的 NCOMS OMNIbus ObjectStore 定义的 “Alerts” 数据库执行查询。如果返回任何结果,它将创建一个结果记录,并为结果添加一个显示已找到的警告数的字段。然后,它被发送回给 Rule Application 进行解析,如前所述。

运行场景

至此我们完成了集成的所有方面,可以通过 Simnet 探测器运行模拟,然后观察 Impact 和 JRules 之间的交互以了解各种不同的场景情况。

场景事件列表

Simnet 探测器根据配置生成事件,并且这些事件可以显示在 Netcool / Impact 可用的事件列表中。下面的屏幕截图显示了在关闭 JRulesEventReader 之后 Simnet 运行一小段时间得到的 Netcool OMNIbus 事件列表。这表明 Impact 和 JRules 都未处理事件。

图 105. 没有规则处理的场景事件列表
没有规则处理的场景事件列表
没有规则处理的场景事件列表

然后停止 Simnet 探测器。现在我们启用 JRulesEventReader 以允许 Impact 处理事件、将它们发送给 JRules 以及执行规则。现在的事件列表如下所示。

图 106. 使用规则处理之后的场景事件列表
使用规则处理之后的场景事件列表
使用规则处理之后的场景事件列表

我们可以看到每个事件都经过 TestUpdateAlert 规则的处理,因为在摘要前面附加了前缀 “JRules Checked”。此外,还可以看到因为数据中心离线而创建了两个新的事件,并且这已被映射到对应的交易履行应用程序。

应用规则

通过查看 TCPIP 的轨迹和选择最后的交互可以看到在 London Datacenter 离线时 Rule Application 作出的响应。

图 107. TCP/IP 轨迹
TCP/IP 轨迹
TCP/IP 轨迹

这里触发了两条规则:为 London_Trade_Fulfillment Application 创建新的警告的 BusinessRule 和将 JRules Checked 附加到摘要前面的 TestUpdateAlert。

Impact 策略集成规则响应

通过查看 Impact 策略日志可以看到响应 London 数据中心离线的策略和作出的响应。

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.returnEvent 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

这段代码显示了被更新的事件和在 London 数据中心离线时创建的新事件。注意,日志文件显示了同时运行的多个策略的输出,以上显示的日志是通过编辑日志的各个部分得到的。

通过使用现在持久化到 Netcool 套件中的新信息,业务应用程序能够根据 IT 运营状态使用本文描述的访问机制来表达规则。

结束语

本文逐一介绍了集成 Tivoli Netcool Impact 和 WebSphere ILOG Business Rule Management System 所需的步骤,从而允许业务用户使用业务规则来定义影响 IT 运营的策略,以及在业务应用程序规则内部使用 IT 运营事件的状态。

本文的第 3 小节展示了实现第 2 小节中描述的场景所需的所有步骤。第 4 小节展示了如何将这些场景与第 3 小节中描述的策略和规则一起使用。

这个例子为读者提供了一个框架,使他们能够开发自己的 BRMS 业务对象模型和规则,并将它们与 Tivoli Netcool Impact IT Operations 事件、数据结构和策略关联起来。


相关主题

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=656946
ArticleTitle=集成 Tivoli Netcool Impact 和 WebSphere ILOG BRMS
publish-date=05052011