Executive summary

This article describes the business situations (scenarios) where you would want to use Tivoli Netcool/Impact and WebSphere ILOG Business Rule Managements System (JRules) together and how you can quickly integrate the products to realize a solution for those scenarios.

Modern business solutions involve the processing of large numbers of events covering both the business and Infrastructure events as shown below.

Business users need to detect and respond to actionable business patterns in time to affect business execution. The solutions need to correlate complex patterns in business events from instrumented assets and systems to make the necessary business decisions to manage business activity and performance.

IT Operations users need to understand and assure the health of critical services, processes and infrastructure. The solutions need to correlate infrastructure-related events across instrumented assets and systems, so they can understand the impact on the business and make the decisions to manage service, process and infrastructure health.

These domains are however not independent so in these modern solutions both user roles need to understand how actionable business patterns affect each other, and the health of complex services, processes and infrastructure.

IBM provides WebSphere Business Process Management products to support business users and Tivoli Service Management products to support IT Operations as shown below.

This demonstrates the need for integration between these product families in order to support the shared insight and decision making. This article concentrates on how to achieve shared decisions between business and Infrastructure using the WebSphere ILOG Business Rule Management System and Tivoli Netcool Impact as illustrated below.

Section 1 provides an overview of Tivoli Netcool Impact and WebSphere ILOG BRMS (JRules) to allow readers to familiarize themselves with the respective products roles and business propositions.

Two key trading scenarios are described below.

In this first scenario, an IT event occurs, (trading system capacity or datacenter offline). On this case the IT Operations role has to decide if this has a significant impact to the business and if so, inform the business so they can take necessary action. However the decision about whether the IT event is significant to the business needs to be made by the Business User or by rules that automate that decision. This scenario is described in section 2.2 and a detailed walkthrough of how it is achieved in section 3.1 to 3.4.

In the second scenario the business user becomes aware of situations and needs to know information from the IT Operations domain in order to effectively make those decisions. In the example slow fulfillment times could be down to a number of IT reasons such as data centers being down or capacity limits being met on the applications themselves. The risk however is based on how long the situation is likely to last so this information needs to be requested before making the decision. If IT Operations are not aware of the business situation the communication can also initiate an investigation and rectification of the problem. This scenario is described in more detail in section 2.3 and the integration is described in section 3.5.

The article finishes by walking through the scenarios in section 4 to show how the integration is actually manifested.

Back to top

Introduction

Overview

This article describes the business situations (scenarios) where you would want to use Tivoli Netcool/Impact and WebSphere ILOG Business Rule Managements System (JRules) together and how you can quickly integrate the products to realize a solution for those scenarios.

The overview in section provides a description of Tivoli Netcool/Impact and WebSphere ILOG BRMS (JRules) to allow readers to familiarize themselves with the respective products roles and business propositions.

A set of scenarios are then discussed in the next section that show the business value of integrating Impact and JRules to allow better communication between IT Operations and Business users.

A technical walkthrough of all the steps needed to integrate the two products and realize the scenarios is also provided. This provides screenshots of the products as the integration proceeds and includes guidance on development and testing on the integration.

An overview of the scenarios working is then provided in the final section and the paper concludes with some relevant references for integrators.

Netcool / Impact Overview

Netcool/Impact provides functionality to do IT event management and integrating IT data. Impact provides a way to integrate the data from various different sources, like databases, LDAP and third party sources. Refer to Figure 3, for the simple Impact Architecture.

Tivoli Netcool/Impact provides a set of interrelated, run-able server components. These components are:

• Impact Server
• GUI Server

Netcool/Impact server

The Netcool/Impact server is the primary software component of the system. This component is responsible for the core functionality of Netcool/Impact, including managing the Netcool/Impact data model, running services, and executing policies. Depending on how you use the product, you can run a single instance of the Netcool/Impact server or run multiple instances as part of a server cluster. Most of the tasks you perform with Netcool/Impact require you to work with this server component.

Netcool GUI server

The Netcool GUI server is the component responsible for hosting and serving the Netcool/Impact GUI. Typically, you have a single installation of the GUI server for all compatible Netcool products running in your environment.

Netcool/Impact Use cases

You can use Netcool/Impact in a wide variety of ways, depending on the needs of your environment. One way to determine what you can do with Netcool/Impact is to analyze its core features and see how you can put together a solution that enhances the value of your Netcool installation. Another way is to look at typical solutions implemented by other Netcool users and see how you can adapt them for use in your environment. Finally, you can also examine the workflow in your network environment and see what parts of the process can be improved using Netcool/Impact.

Core Netcool/Impact features

As noted above, one way to determine what you can do with Netcool/Impact is to analyze its core features and see how you can put them to use in your environment. The sections below cover some of the most important features of Netcool/Impact, and how they relate to event management as a whole and to the Netcool suite of products in particular.

The core features of Netcool/Impact are:

• Automation
• Event source access
• Data access
• Integration with third-party applications
• Predefined actions

Automation

In a general sense, automation is Netcool/Impact’s most important feature. Netcool/Impact allows you to automate event management tasks that you would otherwise have to accomplish manually, or would not be able to accomplish at all. These tasks include event monitoring, event enrichment, and event notification. Automation, however, is really the foundation of what Netcool/Impact does. Automation is the act of setting up a task so that it is performed automatically at certain times or when certain conditions are met.

Like the assembly line, the network operations environment can benefit from automating certain processes. For example, tasks like notifying technicians or system administrators when an alert reaches a certain severity, or updating an event to include related business data can require time and effort on the part of one or more network operators.

This example translates into an event management environment that is less costly than a manual one and less prone to human error. The framework that Netcool/Impact provides for automations consists of the policy engine, the policy scripting language and various triggers that you can use to ″program″ Netcool/Impact to start the policies under different conditions. The policy engine is the feature of Netcool/Impact that performs the tasks you want to automate. These tasks are specified the policy scripting language, which is a programming language similar in syntax to C/C++ and Java.

Event access

After automation, event access is the next most important feature of Netcool/Impact. Event access is the feature that allows Netcool/Impact to tap into the event stream that flows from Netcool probes and monitors into the Netcool/OMNIbus ObjectServer. This feature is an essential part of most implementations of the product.

In order to see how and why event access is important, you must first understand the Netcool event stream and how it is generated. The Netcool event stream is the flow of alerts from Netcool probes and monitors into the ObjectServer. Each alert represents some status or activity on the network and can originate from any of hundreds of different kinds of systems, devices, or applications. Typically, alerts are designed to inform network operators that a fault condition has occurred somewhere in the environment. They can be used to communicate other types of status or event information as well.

Alerts themselves are generated by software components called probes and monitors, which watch the systems, devices or applications and generate the alerts when various conditions occur. After the probes and monitors generate the alerts, they are sent to the ObjectServer, where they can be viewed by network operators through the Netcool/OMNIbus event list.

As noted in the previous section, the network management environment benefits from automated event management tasks. This automation relies on Netcool/Impact’s ability to tap into the Netcool event stream. The framework that Netcool/Impact provides for event access consists of three features: the event reader, the event listener, and the event processor. These are run-able services that you control from within Netcool/Impact.

The OMNIbus event reader works by monitoring an instance of the ObjectServer. When it discovers new or updated events, or discovers that an event has been deleted, it takes the event and pulls it back into Netcool/Impact for processing.

Similarly, the event listener monitors other, non-ObjectServer sources of events, such as SQL databases. As with the event reader, it takes new or updated events when it discovers them and pulls them back to Netcool/Impact.

The event processor is responsible for what happens after the events have been retrieved. When you set up an event reader or event listener, you define one or more policies that are to be executed when an event matches specified criteria. As noted in the previous section, a policy is a set of instructions for Netcool/Impact that specifies the tasks that you want to automate. When coupled with the event reader or event listener, you can use a policy to specify a set of tasks that you want Netcool/Impact to perform automatically when certain kinds of alerts appear in the ObjectServer or other events appear in other event sources.

This combination of event access and automation functionality allows you to create a wide variety of event management solutions. These solutions include event enrichment, X events in Y time, event notification, and event gateways, as described later in this chapter.

Data access

Like automation and event access, data access is also an important feature of Netcool/Impact. Data access is the feature that allows Netcool/Impact to connect to external data sources, such as SQL databases and LDAP servers.

To understand how this feature is important, you can think about all the ways you use data that is external to Netcool/OMNIbus in your network management environment. You might have one database that contains network inventory information and another database that contains information about billing and customer service. In addition, you might have an LDAP directory that you use to store information about the company personnel.

In an environment without Netcool/Impact, it is possible for network operators to be responsible for manually retrieving data from one or more of these data sources and using that information to deduce the importance of events or to decide how events must be handled. With Netcool/Impact, you can integrate this type of data directly into alerts at the ObjectServer level or use this data to perform various types of analysis on the severity or relevance of individual alerts.

The mechanism for accessing data used by Netcool/Impact consists of data source adaptors (DSAs) and Netcool/Impact data models. At the software component level, DSAs provide the means for Netcool/Impact to connect to a wide variety of SQL databases, LDAP servers, and other data sources. At the solution level, the data model is an abstract representation of the data in your environment. Netcool/Impact uses the data model within policies when it retrieves, adds, updates, and deletes data from the data sources.

Third-party integration

The ability to integrate with third-party applications is another important feature of Tivoli Netcool/Impact. In many network operations environments, you have systems in place that have been created by more than one software provider. For example, in addition to the Netcool suite of products, you might have separate third-party applications for network inventory management, billing, problem tracking, customer service, and help desk.

Tivoli Netcool/Impact provides interfaces to a wide array of such third-party applications, including GE Smallworld, Portal Infranet, and TIBCO TIB/Rendezvous. Tivoli Netcool/Impact can interface with a wide variety of other applications by interfacing directly with their underlying databases.

ILOG / JRules Overview

IBM WebSphere ILOG Business Rule Management System (JRules) provides support for authoring, testing, simulating, deploying, executing and managing business rules supporting both Business and Technical users.

Technical Users such as developers and IT Operations staff will need to define the structure of the applications and the interfaces used to invoke the rules systems. This in turn will define the vocabulary that the Business Users can use to express their requirements and policies for what is important in the business. In this way they can rapidly change the business application rules and behavior to react to changing market conditions.

In the previous section we saw how Tivoli Netcool/Impact can monitor alerts from a wide variety of probes and systems and helps augment those events using data access mechanisms. This article will show how we can use JRules in conjunction with Netcool/Impact to allow Business Users to define (and maintain) rules that adds business perspective information into the IT event processing.

WebSphere ILOG Business Rule Management System Architecture

The components of the BRMS and their support for various roles are illustrated in the diagram below.

The components are describes below:

• Rule Studio: An Eclipse-based integrated development environment (ODE) for developers and Technical Users supporting Rule Application development and debugging.
• Rule Team Server: A Web based rule management server and repository providing Business Users a way of authoring, managing, validating and deploying the business rules that determine the behavior of the Rule Application. Rule Team Server also provides access to a shared Rule Repository allowing the rules to be managed centrally.
• Rule Execution Server: A J2SE or J2EE-compliant rule execution environment that can be called by Business Applications to execute the rules using synchronous, asynchronous or web service based invocations.
• Decision Validation Services (DVS): An integrated environment for testing, verifying correctness of rules and simulating changes in business policies.

Business Rule Application Architecture

In order to use Business Rules in an application context, readers need to understand the terminology and architecture of a Rule Application and how it is invoked by Business Applications. The architecture of a Rule Application is shown in the figure below. Each of these concepts will be elaborated in the walkthrough in the next section.

The Business Application invokes the Rule Application through one of a number of Rule Invocation mechanisms that are supported. This paper will concentrate on the Decision Service approach to invoking rules. The Business Application will also have an Information Model that it uses to represent the objects that will be reasoned about by the rules. Each of these can be represented in Java or in XML as a schema and are called Execution Object Models (XOMs).

The Rule Execution Server hosts the Rule Application and the Rule Sets within it. These can be deployed or updated from Rule Studio (for Technical Users) or Rule Team Server for Business Users. The Rule Application is established by Technical Users to contain the required Rule Sets. Each Rule Set has a vocabulary or Business Object Model (BOM) that is used to express the rules using terminology or “verbalization” that is appropriate to Business Users. Each BOM Entry can be initially derived from an existing XOM that is in use in the Business Application. Technical Users use Rule Studio to define these BOM entries and the verbalization that will be available to the Business Users.

Technical Users also have to identify the situations (Rule Invocations) in the Business Applications where a rule may need to be applied. Each Rule Invocation will be mapped to a Rule flow defined in the Rule Set (and thus in the Rule Application). The Rule Flow has a signature defined in terms of parameters which are taken from the Information Model (XOM) when called by the Business Application and mapped to the Business Object Model when being processed by the Rules. When a rule flow is called a sequence of rule packages and /or rules can be configured to be run. If a Rule package is inserted in a flow, all rules defined within that package are candidates for execution. If a specific rule is specified then only that rule will execute at that point in the flow.

Each Rule then has the structure shown below.

The first part of a rule defines the conditions under which the rule "fires".

• The definitions section consists of a number of set statements which define new variables according to information available to the rule (usually passed in as parameters to the flow in which it is running). In some cases the information may not be available in which case the rule will not fire. If the information is available the rule MAY fire as long as the conditions are met.
• The conditions section consists of an “if” clause. If this clause evaluates to true the "then" clause in the actions section is executed, If the clause evaluates to false, the "else" clause (if present) is executed.
• The actions section defines the clauses to be executed according to the result of the conditions clause.

Note that the verbalization and types of all variables in the rule are defined in the BOM which in turn will be related to those parameters exchanged with the Business Application through the XOM.

Back to top

Scenarios

This section identifies key business scenarios that the integration described in this article supports.

Using Impact to provide IT Operations data access to a Business Rule Management System

The main scenario described in this paper is the provision of IT Operations data to Business Users so that they can better manage their business applications and provide guidance back to IT Operations on how best to support them. In the scenario Impact manages and augments that IT Operations data and provides access to the BRMS (JRules) to allow the Business Users to express their policies and rules.

Two data access patterns are described in this paper - each of which is described in more detail in the following scenario sections.

1. Impact Initiated – In this case an IT Event initiates the call to the BRMS and the subsequent application of Business User rules. This may result in adding information to the IT Operations data that is relevant from the Business Context.
2. BRMS initiated – In this case a Business Event or transactions occurs which needs access to the IT Operations data in order to make a valid business decision.

These two patterns require similar configurations in Impact although a wide variety of integration options are available as discussed in the next section.

In any integration scenario BRMS software can use the Impact Servers to access different sets of data from different data sources during the rule processing. It is important to understand what these sources are and how they may be exposed to the BRMS.

A number of steps need to be undertaken when integrating:

• Define a Data source in the Impact Server. This determines where the event and IT Operations data will come from. This will typically be Netcool / OMNIbus tables but may equally include other databases and systems that can be accessed through Impact.
• Define a Data type in the Impact Server. This determines the business vocabulary that may be exposed to the Business Users in the Rules.
• Define a policy in the Impact Server to run the query and return the data. This is invoked when the data needs to be accessed and provides the information in the correct form for communicating between Impact and the BRMS.
• Defining when the data access occurs. This is where the scenarios differ -
  • The policy scenario is invoked in response to an IT Event that can be configured in Impact. The policy then augments the IT Operations data and passes it to the BRMS. Information passed back from the BRMS can be used by Impact in its processing.
  • The BRMS scenario uses the Web Services interface provided by the Impact Server to execute the policy and retrieve the IT Operations data to use in its business rules.

The Impact server also exposes the data through Restful APIs. This Restful API provides a way to retrieve the data from the configured Data source and Data type. In this scenario the end user does not have to define a policy to retrieve the data. They could use their favourite HTTP Client to retrieve the data. The data can be returned as JSON format or XML format. This alternative access pattern has not been included in the walkthrough in the next section.

Using a BRMS to extend Impact policies

This scenario represents the situation where a business user has an interest in alerts and events that are managed as part of the IT Operations domain supported by Tivoli Netcool/Impact. The scenario is illustrated below.

The Business User has a number of Business Applications for stock trading. The business applications consist of:

• A stock trading application which allows traders to order sales on behalf of their customers and
• A trade fulfillment process which actually transfers the money between parties.

The business applications are managed by the Business user through business rules which impose policies on who can make what trades and ensure that balanced portfolios are maintained. The Rule Execution server has been integrated into these applications to allow the Business User to modify these rules quickly according to market needs.

• Tivoli Netcool OMNIbus to collect and collate alerts coming from the IT infrastructure and installed applications and
• Netcool Impact to define policies for reporting, root cause analysis and support helpdesks.

In this scenario the Business User need to be made aware if a datacenter goes down so that he can work out if any of his Trade fulfillment processes would be impacted. The steps undertaken in the scenario are shown in the diagram with red arrows.

1. A datacenter goes offline and is monitored by a probe in Netcool OMNIbus resulting in a new alert being generated.
2. The Netcool OMNIbus Object Stores route the alert through to Impact where it triggers policies indicating what actions should be undertaken.
3. The Impact Policy is extended in this scenario to invoke a Decision Service deployed in the Rule Execution Server. It also adds information from other alerts associated with the Datacenter.
4. The Rule Execution Server then invokes those rules defined by the Business User. This defines the dependencies of the Trade Fulfillment processes on any given datacenter and according to the severity of the alert, the rule determines if a new alert needs to be raised for the Trade Fulfillment Process.
5. If a new Alert is required (or an update to an existing alert), this is sent back to the Impact server and the policy then adds this new information into the alerts and processes it is supporting.
6. Impact then generates the new alert for the Fulfillment Process into the OMNIbus store and IT Operations can then alert support staff and users of the Fulfillment Process to the Business Issue identified.

Using a BRMS to improve interoperability between IT and Business

In this scenario the Business User does not want to rely on support from IT Operations to take account of significant alerts, but actually wants to automate the actions as part of their business application. This is shown below.

In this scenario the Business User sets up a rule to ensure that no trades can be accepted if there is a risk that they cannot be fulfilled. The steps undertaken in the scenario are shown in the diagram with red arrows.

1. A trade occurs in the trading application and the business application invokes the Rule execution server passing in the details of the customer and stock being bought or sold.
2. A number of Business rules are invoked assessing the customer or stock order. In addition a rule is fired that looks for alerts associated with the Trade Fulfillment process associated with the exchange. The exchange can be determined from the order and a method defined in the BOM is invoked to query for alerts associated with that Trade Fulfillment Process.
3. The XOM code invoked from the BOM method call invokes an Impact policy that performs a query.
4. The policy retrieves all alerts for the Trade Fulfillment Process (including any of the alerts generated in scenario 1) This could also include any performance alerts provided directly from the process.
5. Based on the alerts received the rule identifies that the trade would constitute an unacceptable risk and passes the result to the rule execution server.
6. The Rule Execution server then passes back the result of this rule (and any other rules that have fired) back to the application which can then relate these back to the user indicating why the trade cannot co ahead; There is a risk that the trade cannot be fulfilled within an acceptable time.

Back to top

Integration walkthrough

This section explains how to go about integrating Impact and JRules to realize the scenarios described in the previous section. The objective is to allow a Business User to define rules that operate on the IT events provided from Tivoli Netcool such that they can indicate the situations that are important to them. This then allows IT operations to react better to the Business Users needs and persist and manage the information that the Business Users use in their business applications. This is illustrated below with the first scenario shown in green and the second scenario shown in blue.

The walkthrough consists of step by step instructions for developing and debugging a working integration between Tivoli Netcool Impact and WebSphere ILOG BRMS. It is assumed that the user has installed both these products. The stages that the walkthrough goes through are:

• Information Model Design – how to implement the vocabulary exposed to the business user in the rules based on the information model available from Netcool.
• JRules Decision Service Realization – how to implement a decision service (HTDS) that can be called from Netcool/Impact Web Service DSA and allows business users to express their rules in terms of the defined vocabulary.
• Integration of Impact and JRules Decision Service – how to generate the Web Service DSA and Impact policy from JRules Decision Service WSDL and invoke the JRules decision service according to OMNIBus events and obtain the response.
• Impact Policy Development invoking JRules Decision Service – provides examples of the common patterns required in an Impact policy when invoking a JRules decision service.
• Rule Application Callbacks into Impact – describes how a JRules rule application can invoke Impact policies through its web service Listener to obtain alert information to use in its business rules.

Information Model Design

This section identifies how to select and specify the schema that will be used in JRules to verbalize the Netcool alerts and events that the rules are going to reason about. This section designs the XOM that will form the basis for the scenarios.

Table Structure

The main concept used within Netcool OMNIbus and Impact is the Alert. This is defined in the alerts.status table in an ObjectServer database. This has over 50 columns or fields within it and while all of these could be defined in the XOM, it was decide to focus on a few fundamental fields in constant use. These are summarized in the table below.

To represent this table in a XOM that can be used in Impact and JRules, we need to decide on the type of XOM that is going to be used taking account of the invocation mechanism that will be used. Since we are going to use a Decision service, we need to define an XMLSchema to represent the XOM. This is then a Dynamic XOM.

When designing the schema, the cardinality of fields must also be considered as this will determine whether a value is always required when exchanging the alerts between Impact and JRules. In the table, the calendar fields (FirstOccurence , Last Occurrence), Type and Serial have been made optional, all other fields will require so valid value to be present. Note that for strings a "" or empty string is an acceptable value.

This results in an AlertType type in the schema OMNIBus.xsd as shown below.

As well as considering how we represent an alert we need to consider any other information that will be passed to the Rule Application in order for rules to be evaluated and what information we will get back from the rules to determine the response.

The input to the rules includes not only the updated alert but also any other alerts associated with the same node. So we define an AlertEventInput structure as shown below.

In a similar manner what we get back is a selection of alerts that need to be created, updated or deleted.

To keep the scenario simple these have simply been provided as single optional Alerts but in a more sophisticated scenario, a single invocation could result in multiple response events.

Creating the Rule Project

The next step is to create the Rule project that defines the rule set. In Rule studio create a new Rule project called OMNIBusAlertDecisionService.

Select Standard Rule Project and press Next.

Enter the project name and press Finish. The Rule project is shown together with the Rule Project Map.

Importing the XOM

Copy the schema generated in step 3.1.1 into the project root. The project should look as shown below:

Select the Import XOM link to start the BOM definition.

Select the Dynamic Execution Object Model (XSD) and press OK.

Select Add XSD...

Select the schema copied into the project root and press OK.

Examine the packages and namespaces that will be used and press OK.

Creating the BOM

We now have the XOM created and are ready to create the vocabulary that the business users will use. The project should now look as shown below:

The Create BOM link is now enabled. Select this link.

Enter a name for the BOM (or accept the default of "model"), ensure that Create a BOM entry from a XOM is selected. Press Next.

Press Browse XOM.

Select the schema referenced in the previous step and press OK.

Select the three types defined in the XOM and press Next.

Check that the default verbalization covers what is required and press Finish. If any of the vocabulary needs to be changed, the BOM is visible in Rule Studio and can be altered from within the BOM Editor.

The BOM and default vocabulary has now been created. The next step is to create an initial set of rules and generate the decision service.

JRules Decision Service Realization

This section identifies how to take the verbalized schema and generate and test a JRules decision service with an initial set of rules that can be invoked by Impact.

Creating the Decision Service signature and parameters

In the BOM we have now defined the input and output parameters that we wish to use in our decision service. The BOM defines the types and verbalization of those types but we now need to define the input and output parameters that will be used to communicate with the Rule Application.

Select the Define parameters link in the Rule Project Map. In the wizard that appears press the Add Button and fill in the name and verbalization for the input argument as show below. Set the direction to IN.

Select the Type dropdown.

Search for all types starting with Alert and the three BOM types are visible. Select the AlertEventInputType. Note that at the bottom the Array checkbox allows users to indicate if the argument is a single value of this type or an array (collection). The alternative form of collection is to use a java.util class declared in a Java XOM. Leave this box unchecked in this example. Press OK.

Repeat the process for the alertOut parameter (AlertEventOutputType) so you end up with a display as shown below.

Press OK.

The parameters have now been defined and will be added to the decision service invocation signature.

Creating a Decision Service Rule package

We now need to create a package to hold some rules. We will start with a package that holds simple test rules. This can be developed further once the basic integration is working.

Select the Add rule package link in the Rule Project Map. (Or Select the OMNIBusAlertDecisionService Rule Project and from the menu select File > New > Rule Package).

Type the name of the package AlertTestRules and press Finish.

This has created the rule package in the rules folder of the decision service.

Creating a Decision Service Rule flow

This section describes how to create a new rule flow that will be exposed through the decision service. Select the Add rule flow link (or Select the OMNIBusAlertDecisionService Rule Project and from the menu select File > New > Ruleflow).

Type in the name of the rule flow: "AlertRuleFlow". Press Finish. The empty AlertRuleFlow rule flow is created as shown below.

We now have to establish the flow.

• Click on the Green Start Node and then click in the AlertRuleFlow diagram to create a start Node.
• Click on the Red "End" Node and then click in the AlertRuleFlow diagram to create an end Node.
• Drag the AlertTestRule package from the Rule Explorer onto the AlertRuleFlow diagram.
• Connect the three nodes together using "Transition" links resulting in a Rule flow as shown below:

This will result in any rules included in the AlertTestRules package being candidates for execution whenever the decision service is invoked.

There is one final step that needs to be undertaken at this stage to avoid problems later on. The output parameter – alertOut is not created by default and needs to be initialized at some point in the flow to allow the rules to reference it. There may also be cases where input parameter fields are not provided and this can cause null pointer exceptions if a rule references these fields.

To overcome these restrictions it is often necessary to put some initialization steps into the Initial Task of the flow. To do this, follow the steps below.

• Step 1. Select the Initial Task either from the Outline or from the AlertRuleFlow diagram.
• Step 2. Create a Properties View – Select the Menu – Windows > Show View > Other...

Open the General Folder and select the Properties View and press OK. A properties Tab is now available – move this to a suitable frame in Eclipse and select the IRL checkbox. Step 3. Enter IRL code to initialize the input and output parameters as shown below.

This code performs three initialization steps:

• It creates an instance of alertOut that can be passed back to the invoking application.
• It creates and populates the NewAlert field of alertOut.
• If the Type field of alertIn has not been set it sets it to 0.

Creating an initial set of Rules

We now want to create an initial set of rules within this package that use the verbalization and parameters that will be passed into the decision service. We will establish three test rules:

• AlertTestUpdate – updates an Alert if the Rule fires
• AlertTestDelete – deletes an Alert if the rule fires
• AlertTestCreate – creates a new Alert if the rule fires

In the Rule Project Map select the Add business Rule link (or Select the OMNIBusAlertDecisionService Rule Project and from the menu select File > New > Business Rule).

Browse to select the AlertTestRules package and type in the name of the rule: "AlertTestUpdate". Press Finish. Double click the resulting AlertTestUpdate tab to expand the rule in the Intellirule view. First we will setup a definitions section.

• Start typing "definitions" – at any point type ctrl space and the auto complete options are presented.

Continue using auto complete to:

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

This should result in the screen below:

This results in an error as the "then" clause is missing. Continue to fill in the rule using the Intellirule editor until the code below is achieved:

Right click and press save. This rule will check to see if the summary does not already contain the term "JRules Checked" and if so it will pre-pend it to the summary. It then indicates that this alert should be updated by setting the "UpdateAlert" field of the response to match the modified alert. Effectively this should prefix each summary with "JRules Checked" unless the summary already contains this. Repeat this process for the other two rules as shown below:

This rule will create a new alert for any incoming alerts with a severity of 4.

This will delete any alerts with a severity of 0 (Cleared).

Debugging the Rule set in Visual Studio

This section describes how to test the rule set within Rule Studio in isolation from any other systems or deployments. From the Menu select Run > Open Run Dialog.

In the dialog select Rule Project - right-click and select new.

Use the browse button to select the OMNIBusAlertDecisionService rule project and set the name of the configuration to match. Check the stop at first rule statement. And press Apply. Move to the Parameters and arguments tab. We will now enter some test parameters to pas into the rules that should make the AlertTestUpdate rule fire. Select the alertIn parameter and press EditValue...

Select the Function body checkbox and enter code to initialize the input alert. Press OK.

Press Apply. From this point the Rules set can be run. Press Run. This should show the print statement output from the rules that have fired in the Console window.

If you want to debug the code, from the menu select Run > Open Debug Dialog..., select the OMNIBUSAlertDecisionService configuration and press Debug. You should then receive the alert confirming a switch to debug perspective.

Press Yes to enter the Debug perspective.

In debug perspective the code halts at the first part of the rule code – the initialization undertaken as part of the Initial Task. The inputAlert is also visible in the variables window. By stepping through the code into the Body, the rules get executed / tested and any rules where the definitions and if clause evaluate to true appear in the debug window as shown below.

By experimenting with different parameter settings in the Run Dialogs the different rules can be tested.

Creating the Rule Application and Decision Service

Before we can test this rules set as a decision service we have to create a Rule Application to contain it. In the Rule Project Map select the "Create RuleApp project" link (or Select the OMNIBusAlertDecisionService Rule Project and from the menu select File > New > Project... and then select RuleApp Project).

Type IMPACTRuleApp for the Project name and press next.

On the next page ensure the OMNIBusAlertDecisionService Rule project is selected and press Finish. The RuleApp is created in a form that can be deployed and tested.

Configuring the Rule Execution Server

This scenario will work with a default deployment of RES and RTS on Tomcat thorough the samples server. More complex scenarios require a deployment onto WebSphere Application Server. This article does not cover the various installation and configuration options for the Rule Execution Server and Rule Team server so the urls and details of configurations will be different. See the Installing section in the infocenter for more details.

The simplest deployment is to deploy the Rule Application straight to the Rule Execution server from Rule team server. Start the sample server (or Rule Execution Server) for your installation. Now we need to create a Rule Execution Server configuration that Rule Studio can recognize. In the menu select File > New > Other...

In the Rule Studio folder select Rule Execution Server Configuration and press Next.

In the next screen press Create a new configuration project.

Leave the defaults selected and press Finish.

Now select this project to contain the configuration and press Next.

In the next screen select the application server hosting RES (in this case Tomcat) and press next.

In the Server configuration navigate to the Installation directory (as shown above) – this should set the default deployment directory for Tomcat. It will also establish the default URL for RES. The login and password are both resAdmin by default. Press the Test connection. You should get a response of:

If connection is not successful, check the server is running and the characteristics have been entered correctly. The connection failure messages will usually indicate the nature of the problem. When the connection is successful press Next.

In the final screen make sure that the Deployment "to the Rule Execution Server Console" radio button is selected and press Finish. Check that you can log into the Rule execution server by following the "Open the Rule Execution Server link" and logging in with resAdmin/resAdmin. We are now ready to deploy the RuleApp to RES.

Deploying the Decision Service

In Rule Studio open the IMPACTRuleApp by double clicking on the archive.xml file in the IMPACTRuleApp Project.

Then select the "Deploy a RuleApp to one or more Rule Execution Servers" link.

Select the Replace RuleApp version deployment type – this means that the url used for the decision service does not change when deploying a new version.

Select the Tomcat configuration (or configuration setup previously) and press Finish. The deployment results are displayed in the Console panel. Navigate to the Rule Execution Server tab, open the Explorer and look at the Rule set. The structure of the decision service can now be seen including the input and output parameters.

Testing the Decision Service using Web Services Explorer

We now need to test the Decision service web service being provided by the Rule Execution Server. Select the "Get HTDS WSDL for the ruleset version", right click and select Save as.

Navigate to the decision service directory in the Rule Studio workspace, Select Save as type: All Files and enter the full filename to be used for the WSDL. Press Save. In Rule studio select the OMNIBusAlertDecisionService project right click and select refresh. Verify that the OMNIBusAlertDecisionService.wsdl file appears. Switch to a Java Perspective. Select the OMNIBusAlertDecisionService.wsdl, right click and select Web Services > Test with Web Services Explorer.

Select the link to "executeDecisionService". This is the operation in the web service that will invoke the Rule set.

Fill in the parameters used to test the rule previously:
Node: Node
Severity: 3
Summary: Summary
Tally: 1

Note that Tally needs to be set as it is not an optional field and the web service client validation will fail if a value is not provided. Press the Go button at the bottom of the Actions Pane.

The response from the web service can be seen in the body. In this case we have UpdateAlert set copying the fields provided but adding "JRules Checked" to the beginning of the Summary. This approach to testing works well as long as there are no exceptions generated from the Rule Execution Server AND the client is the web services Explorer.

Testing the Decision Service using TCP/IP Monitor

When we integrate with Netcool, it becomes more difficult to see what is going on. In this case it is worthwhile using the TCP/IP Monitor provided in Eclipse. To setup the TCP/IP Monitor navigate to the its configuration through the menu Tools > Preferences.

In the monitor add a monitor proxy-ing localhost:8080 which is invoked through local port 8081. Reset the web service explorer to use localhost:8081.

When the web service explorer is run this time the interaction XML can be examined.

This can be used to log each interaction between Impact and JRules. Note also that each interaction is also timed so by comparing this figure with the statistics figures for the Decision service and the rules set available from the Rule Execution Server, an understanding of the processing latencies can be obtained.

Creating the Business Dependency Rule to react to IT events

This section now looks at extending the rules needed to support scenario 1. This involves adding a rule that will raise a new alert for any Fulfillment applications if the datacenter that is hosting them goes offline.

The Business Dependency rule is added to the Alert Test Rules package and has the form shown below.

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;

This rule uses the definitions section to identify when a datacenter goes offline. It identifies that it is a datacenter by checking if the node name contains datacenter. Other mechanisms could have been used if the alert semantics had been agreed.

This rule also introduces the idea of Rule Variable sets. These are variables that can be shared between rules (as part of the flow) but do not get passed in as parameters. The exchange variable is a variable in an Exchange Rule variable set defined in the AlertTestRules Package. It is used to hold the location of the datacenter which would also be the location of the fulfillment application that is supported by that datacenter. To initialize this variable we need to add some code to the IRL we introduced to the Initial task in the rule flow. This amendment can be seen below.

This will establish the exchange to be the first part of the datacenter name and thus make it ready for use in the rule when it is referenced.

Integration of Impact and JRules Decision Service

This section describes how to create an Impact policy that can use the decision service we have developed. This part of the scenario assumes that we have Tivoli Netcool Impact installed on the same host as JRules with a default install and that the Impact application server is running and connected to a default Netcool OMNIbus ObjectStore.

Importing the decision service WSDL file

Netcool Impact provides a wizard that will automatically create a policy that can invoke a web service. In this section we will walk through the steps of creating this policy and invoking the decision service from within Impact.

The first step is to login into the Impact userinterface as shown below.

The default username and password is admin/netcool.

Open the Wizards section and select Web Services.

Type the name of the policy – we will use OMNIBusAlertDecisionServicePolicy initially as a test policy for initial integration. Press Next.

Enter the path to the WSDL that was downloaded from the Rule Execution server. Enter a name to be used for the package of java code that will be generated and thus referenced by the policy. Press Next.

Check the names of the web service, port type and method. These should match those seen while using the web service explorer. Press Next. The next step takes a bit longer as Impact parses the WSDL and compiles the java to end up with the package that can be invoked from within the policy.

The next screen provides options for the code that needs to be generated in the policy. If we put in the same details as we did for testing in Rule Studio we can quickly see how we would invoke the same rules from Impact. In addition we put in a "current" entry to get an illustration of how to transfer dates and times, and put a sample in for 1 Related alert to see how we would send the associated information across to the decision service.

In the next screen select the edit box and change the port from 8080 to 8081. This will route any decision service calls through the tcpip monitor so that each interaction can be debugged. Press Next.

A summary screen results. Press Finish.

The main console now opens with a policy that has been created. Press the Save Icon to make sure that this is saved. The actual policy generated is shown below:

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

We will now try and run this policy. Having saved the policy, it is now visible in the Policies section in the navigator. However the jar file that has been generated is not yet on the class path. This file is situated in the directory:

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

Testing an Impact Policy with a Decision Service.

This is a static test to check that by running the policy you can invoke JRules and get back the response we have done in each of the other steps. Navigate to the policy in Impact.

Select the green arrow to run the policy.

Press the Execute button.

In the possible case of an error a message like this will appear and debugging will need to occur. The first step is to look in the policy log in Impact – this is where the log statements appear from the policy. This can be found by clicking the view Log button for the Policy Logger.

This shows that the call to the decision service was made but that no response was found.

More details can be seen in the Netcool logs in directories:
C:\IBM\Tivoli\Netcool\log
C:\IBM\Tivoli\Netcool\impact\log

Examination of the tcpip monitor logs can also indicate what is happening.

In this case the exception is being thrown because certain mandatory elements are not present in the web service xml for the alertIn parameter. The same information can also be seen in the Rule Execution server logs for the decision service.

Navigate to the Ruleset in Rule Execution server.

Select View Execution units and expand the list of alerts.

Select the localhost execution unit showing the error and expand the error message that is relevant.

This then shows the reason for the exception from the JRules perspective. To remedy this we will modify the policy to set these elements. These are shown below in the policy in bold.

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

Save and re-execute the policy.

This shows that the policy executed correctly. Looking in the tcpip display shows the complete interaction.

And looking in the policy log shows that the response was actually available to the policy.

This has now shown the full interaction between an Impact policy and a JRules Rule Application.

Configuring Impact policies to respond to IT Events

The next stage is to create a new Impact policy that will respond to IT events coming from the Netcool OMNIbus Probes and thus be able to support scenario 1. We first create a policy manually. In the Policies tab, select the Custom template and press the + sign.

Enter a name for the policy (JRulesDecisonServicePolicy) and some logging to check when it is invoked. Save the policy. It is then worthwhile just checking that the policy runs and looking in the Policy logger for the expected output. Now we need to setup a service in Impact to send IT events to this policy). To do this we create a service based on an OMNIbus Event Reader.

Expand the Services tab in the navigator, select a Type: of OMNIbusEventReader from the dropdown and press the + symbol to start the wizard.

In the first tab provide a name and set the polling interval which defines the interval between the queries Impact performs. Effectively this defines how often Impact looks for new or updated events. Navigate to the EventMapping tab.

In this tab check "Get updated events" – this means that updates to the alerts that satisfy the filter criteria will also be passed through to the decision service policy. Note that if event deletes are also significant to the rules decision service, the "Run policy on deletes" checkbox should be selected. This would need a new policy defined that indicated to the Rule Application that the event was being deleted. This is not provided in the current example. Press the New Mapping button.

In this screen type a filter expression that determines what events will be routed to the Policy. In this case we will use the Simnet probe (See reference 11) to generate events so all Simnet events will be routed to the JRules policy. In the "Policy to Run" field, pull-down select the JRulesDecisonServicePolicy that we have just created.

Set the policy to active. At this point is worth pressing the Analyze Filter to check that the syntax is correct and see if any other policies would overlap with this filter condition. Press OK.

The filter and mapping to the policy are now visible in the Event Mapping Tab. Press OK to save the Event Reader configuration. To test this we need to undertake a few more steps that are outlined briefly here. Modify the JRulesDecisionServicePolicy to printout the Event received.

       
log("Starting JRulesDecisionServicePolicy");

log("Event received: " + EventContainer);

log("Finishing JRulesDecisionServicePolicy");

Start the JRulesEventReader by pressing its green start arrow in the Service status pane.

Start the SIMNET probe generating events. The standard configuration of the probe is modified slightly to represent the scenarios being used here. This affects the Nodes and events that are generated.

The simnet.def file defines the scenario being represented. This defines 3 properties for each entry.

1. The name of the Node.
2. Code influencing the Agent, AlertGroup, Summary and alert processing supported by the node
   • 0. Link Up / Down - Used to indicate links going on / off line
   • 1. Machine Up/Down - Used to indicate datacenters going on /off line
   • 2. Disk space - Used to indicate Application utilization
   • 3. Port Error - Use to indicate a port being reset on an application or link
3. Percentage indicating the likelihood of an alert occurring.

When looking at the Policy logger now you should see that the JRulesDecisionServicePolicy is being invoked for each SIMNET event or update.

The log here shows three complete events being processed by the policy:
The NewYork_London Link going up
Paris_Stock_Trading application undergoing a port reset
NewYork_Stock_Trading application undergoing a port reset

Note that the simnet.rules file has been modified in this situation to better match the scenario but this is not required to demonstrate or test the integration.

Impact policy development invoking JRules Decision Service

Now we have the ability to invoke the JRules decision service from an Impact policy and we have an Impact policy being invoked by IT Operations events. This section describes how to write the Impact policies that invoke the JRules decision service and how to respond to the different responses that can occur.

Integrating the JRules decision service into the Impact Policy

This section will be divided up into a number of sections that provide different aspects of the integration. Each of these sections will be a function in a JRULES_LIBRARY policy. These functions will be called from the JRulesDecisionServicePolicy policy to provide clarity of structure. The complete structure of this policy is shown below.

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

Subsequent sections take a particular library function and describe how it works.

Sending Events to the Decision Service

The first step is to take the EventContainer provided in the event and map it into the MainAlert provided to the decision service. The code in the Policy is shown below and the library function follows.

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

The main request defined in the WSDL is first created and the hierarchy of subobjects created until we get to the main alert. The fields in this _MainAlert are then populated from the EventContainer by the PopulateJRULESAlert function shown below.

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

Note that this approach will set all the required fields in the XOM to a value, avoiding any web services parsing exceptions.

Adding in Related Alerts

Rules based decisions often need more information than is contained in the event so this example also passes in any other alerts that are for the same Node. The policy simply identifies the node name and then passes it and the _AlertEventInput (which contains the RelatedAlerts) to the PopulateJRULESRelatedAlerts function.

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

The library function searches for any alerts using the Alerts data source which is a default source setup on the 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;
        }
    }
}

Note that the function excludes the event that triggers the policy as that will already be supplied through the MainAlert. Each Alert found results in a new RelatedAlert which is populated using the PopulateJRULESAlert function already described.

Invoking the Decision Service

This section describes how to actually setup the parameters; the endpoints etc and make the call to the decision service. This was the code that was generated for us by the Web Service wizard. Note that any changes in endpoint would need to be entered here unless they were provided as policy properties.

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

Getting responses from the Decision Service

The next section shows how to get the three different responses from the decision service out of the result and action them.

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

Each of the responses is handled by a separate library function and is described in the following sections.

Updating an Alert

The library function shown below shows how to update an alert in 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 );
    }
}

Note that the original content is first retrieved and then updated by what came back from JRules. If the event to be updated can be constrained to be the mainEvent then the EventContainer can be used instead of Alert and no query or copy need be performed. Two separate library functions are used here.

The Copy function copies fields from the retrieved data item to the local 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;
}

And the update from JRules which copies any fields provided from the decision service.

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

This function only updates those fields that are provided from JRules.

Deleting an Alert

This example shows how to delete an alert indicated by the decision service. It first ensures that the Alert does exist by checking the 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);
    }
}

Creating a new Alert

This example finally shows how to create a new alert as indicated by the decision service.

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

This also uses the PopulateAlertFromJRULES function to fill in the fields supplied from JRules.

Rule Application Callbacks into Impact

This section provides a high level overview of a business application that uses rules that depend on information contained within Netcool. This requires a query to be performed against Impact. This describes the scenario above.

The Business Application and Rules

A trading application provides a number of rules including those that depend on the alert status. These are summarized below listing package/rule name. Many are arbitrary and are intended as samples that can be changed by the Business User using Rule Team server but they serve the purpose of demonstrating the context of the business application. In each rule a status of Pending/Blocked/Rejected is provided together with a reason.

CheckAmount/Order Amount – provides rules about the trade value.

  
if
	the amount of order is less than 100,000 
then
	set the status of report to "Pending" ;
	set the reasons of report to "Customer Preferences" ;

CheckCurrency/CurrencyRestriction – provides rules based around the order currency field.

  
if
	the currency of order is "Euro" 
then
	set the status of report to "Rejected" ;
	set the reasons of report to "Customer Preferences" ;

CheckCustomerName/BadClients – provides rules based around the clients requesting the trade.

  
if
	the name of customer is "John Smith" 
then
	set the status of report to "Rejected" ;
	set the reasons of report to "Bad Client" ;

CheckStock/StockName – provides rules based on the stock being traded.

  
if
    the stock of order is "Company X" 
then
	set the status of report to "Blocked" ;
	set the reasons of report to "Black Listed Stocks" ;

The IT dependant Rules

This section now introduces how the IT dependency can be brought into these business rules.

CheckFulfillmentRisk - checks to ensure that the Fulfillment Application associated with the exchange where the trade is to occur does not have any alerts outstanding that may jeapordise the trade being fulfilled.

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

This rule first of all extracts the exchange that the trade will use and thus identifies the particular fulfillment application that will be used. The rule then performs a query using a java class that is verbalized using the term "impact client" and exposes a static method called "queryAlerts". This method takes two properties.

• The field of the alert to be used in the query - "Node"
• The value of the field to be used in the query - exchange+"_FulfillmentApplication"

Any alerts that are found are put into the risks collection.

The condition clause (if) then looks to see if there are any alerts in the risks collection and if there are, do any have a severity of greater than 3. This may seem a clumsy way of performing the severity comparison but in this case the severity has been mapped to a string containing the code. It would be preferable for a Business User to have an enumeration that was verbalized to indicate the meaning of each of the severity codes and this could easily be undertaken in the XOM to BOM mapping.

If the conditions defined above are met, then the rule fires and the trade is rejected because there is a significant risk that it cannot be fulfilled.

The Impact Client XOM and BOM

The impact client invoked by the rules is a java XOM that invokes an Impact web service. It could have been written to use any of the other mechanisms described above. This is shown in the screenshot below:

The ImpactClient class provides an implementation of this method that hides the more complex aspects of invoking Impact through the web service.

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

The two important steps in this are: client.connect() – This establishes a session with Impact by logging in using the web service login operation.

 
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() – actually performs the query using locally cached values for the query field and value.

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

The code above shows the web service parameters being set to the query field and query value that were specified in the rule.

The listener.runPolicy call passes in the session token created by the login(lid), the name of the Impact policy to run ("ExternalAlertQuery") and the parameters. The results that come back are a flat list of name value pairs. This is a restriction of the Impact web service and code is then needed to identify the number of alerts and to actually associate the fields of each alert with the correct alert record before passing the RiskAlert array back to the Rule Application.

The Impact External Alert Query Policy

When the Impact web service is invoked by the Rule Application, the Impact policy shown is run. This is relatively simple but does need to provide the flattened structure for the results as shown below. This is a very simple approach that only supports 3 results.

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

The two parameters defined in the web service QUERYFIELD and QUERYVALUE are available as named parameters in the policy.

The policy performs a query against the "Alerts" database defined against the default NCOMS OMNIbus ObjectStore. If any results are returned it then creates a result record and adds a field to the results for the number of alerts found and for each field in each alert. This is then sent back to the Rule Application which interprets it as we have seen.

Back to top

Running the scenario

Now we have all aspects of the integration complete we can set the simulation running with the Simnet probe and observe the interactions between Impact and JRules taking place to realize various scenario situations.

The Scenario Event List

The Simnet probe generates events according to its configuration and these can be shown in any event list available to Netcool / Impact. The screenshot below shows the Netcool OMNIbus Event List after the the Simnet probe has been running for a while with the JRulesEventReader turned off. This means that neither Impact nor JRules are processing the events.

The Simnet probe is then stopped. We now enable the JRulesEventReader to allow Impact to process the events, route them to JRules and execute the rules. The event list now looks like this.

We can see that each of the events has been through the TestUpdateAlert rule as it has the “JRules Checked” prefix to the summary. We can also see that two new events have been created due to the Datacenters going offline and these have been mapped to the corresponding trade fulfillment applications.

Applying the Rules

Looking in the TCPIP trace and selecting the last interaction we can see the response from the Rule Application to the London Datacenter going offline.

Two rules fire for this: The BusinessRule that creates a new alert for the London_Trade_Fulfillment Application and the TestUpdateAlert which prepends the JRules Checked phrase onto the summary.

Impact Policy integrating the Rule response

Looking in the Impact policy log we can see the policy that responded to the London datacenter going down and the response being actioned.

    
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

This shows the event being updated and the new event being created when the London datacenter went down. Note that the log files are showing the output of multiple policies running concurrently and the log shown above has been obtained by editing the respective pieces of the log.

With this new information now persisted in the Netcool suite, Business Applications can now use the access mechanisms described of the walkthrough to express rules in terms of IT operations status.

Back to top

Conclusion

This article has walked through the steps needed to integrate Tivoli Netcool Impact with WebSphere ILOG Business Rule Management System allowing Business Users to use business rules to define their policies for influencing IT Operations policies and to use the status of IT Operations Events within their Business Application rules.

The walkthrough in section 3 has show all the integration steps needed to realize the scenarios described in section 2. Demonstrations of these scenarios working with the policies and rules described in section 3 have been provided in section 4.

Using this example should provide a framework for readers to develop their own BRMS Business Object Models and Rules and associate them with Tivoli Netcool Impact IT Operations events, data structures and policies.

Resources

Learn

• WebSphere ILOG JRules Version 7.0 Information Center.
  
  
• Learn how to install JRules 7.0.
  
  
• Rule Execution Server product documentation.
  
  
• JRules Decision Service tutorial.
  
  
• Rule Team Server product documentation.
  
  
• Rule Studio product documentation.
  
  
• Netcool / Impact administration guide.
  
  
• Netcool / Impact policy reference guide.
  
  
• Netcool / Impact DSA reference guide.
  
  
• Netcool / OMNIbus information center.
  
  
• Netcool / OMNIbus Simnet probe.
  
  
• In the SOA and web services area on developerWorks, get the resources you need to advance your skills.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download IBM product evaluation versions or explore the online trials in the IBM SOA Sandbox and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Executive summary
• Introduction
• Scenarios
• Integration walkthrough
• Running the scenario
• Conclusion
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into SOA and Web services on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers