Enhance IBM Intelligent Operations Center-based applications

How to handle activities

The IBM Intelligent Operations Center supports standard operating procedures. When an incident occurs an activity is created for each step defined in a procedure. This article describes how architects and developers can modify existing artifacts, and develop new ones, to present data to and collect data from a user as a part of an activity, then record both presented data and collected data, and propagate it to a later activity as part of the same incident.


Aidan Clarke (aidan_clarke@ie.ibm.com), IT Architect, IBM

Photo of Aidan ClarkeAidan is an IT Architect with IBM Software Group. He has over 30 years IT industry experience, primarily in software development roles. He is currently part of the Industry Solutions organization working with the IBM i2 Intelligence Analysis product portfolio.

Brian Daly (briandal@ie.ibm.com), Software Developer, IBM

Photo of Brian DalyBrian Daly is a Software Developer and a member of IBM Industry Solutions Development group at the Technology Campus at Mulhuddart, Ireland. He develops new content that extends the Industry Solutions offerings.

Artur Grzenkowicz (agrzenko@ie.ibm.com), Senior Java Designer, IBM

Photo of Artur GrzenkowiczArtur Grzenkowicz is a Senior Java Designer and a member of IBM Industry Solutions Development group at the IBM Technology Campus at Mulhuddart, Ireland. Currently, he is working with the IBM i2 Intelligence Analysis product portfolio.

Kevin Keating (kevinati@ie.ibm.com), Software Engineer, IBM

Photo of Kevin KeatingKevin Keating is a software engineer and member of IBM Software Group, Industry Products. He has developed public safety demos using Intelligent Operations Center.

Vincent Kelly (Vincent_Kelly@ie.ibm.com), Development Manager, IBM

Photo of Vincent KellyVincent Kelly is a Development Manager working out of the Ireland Lab within the Industry Solutions Group. He is currently focused on the newly acquired i2 products within Public Safety. Previous to this role he held various managerial roles within Development and Test across IM and Lotus.

Jamie O'Leary (joleary@ie.ibm.com), Software Engineer, IBM

Photo of Jamie O'LearyAfter a long period of working within the Lotus Connections family of products developing web front-ends and social search tools in Java 2 Platform, Enterprise Edition (J2EE), Jamie moved into the Industry Solutions division where he developed back end integration between native platform applications and J2EE services. Currently Jamie is developing prototype extensions to the Intelligent Operations Center.

17 July 2012

Also available in Chinese Russian Portuguese


Different business domains require different solutions for their operational supervision and coordination needs. For example, the precise needs of a major construction project differ radically from those of an emergency response command center, or a sports stadium's operation center.

However, there are many basic structural requirements common across these domains:

  • Alerts come from the field
  • Response teams need to be organized
  • Standard operating procedures need to be supported
  • Performance needs to be tracked through key indicators
  • Improvements need to be made

The IBM Intelligent Operation Center is a software environment that supports the implementation of such solutions by providing an architecture supporting these features. It provides multiple integration points through which solution delivery organizations can provide domain accelerators. The IBM Intelligent Operations Center V1.5 United States Software Announcement 212 – 250, July 3, 2012 (see Resources) provides more detail.

Standard operating procedures

A standard operating procedure, or SOP, is a collection of predetermined steps designed to ensure an effective response to an incident through the coordination of people, products, properties, and processes. Steps can be further defined as a series of activities; they can begin with no feedback requirement, or they can require some level of feedback before the SOP can continue to the next step. The specific feedback required is different for different activities.

Some common requirements exist: the system needs to know when an activity has started and when it has ended; people need to be communicated with; new alerts need to be raised. The Intelligent Operations Center provides some of these capabilities through its integration of IBM Tivoli Service Request Manager.

A common use case for SOP implementation, not currently provided by the Intelligent Operations Center, is for an activity to require some predefined feedback or a specific set of data from an operator. Typically, forms are used to support this use case. The Federal Emergency Management Agency (FEMA) website provides a large range of forms covering different activities within their scope (see Resources).

Standard operating procedures in Tivoli Service Request Manager

Three Intelligent Operations Center artifacts are required to create an SOP in Tivoli Service Request Manager: a standard operating procedure, a selector matrix, and a response plan. The SOP consists of the complete set of steps and activities that constitute a procedure. An example of a SOP in the context of public safety is shown in Figure 1.

It consists of two steps, one of which will trigger a workflow. Both of the steps have roles assigned to them. (Assigning roles and workflows are optional.)

Figure 1. SOP example in Tivoli Service Request Manager console
SOP example in Tivoli Service Request Manager console

(View a larger version of Figure 1.)

The SOP Selection Matrix application is used to build an SOP selector matrix that defines an SOP selector value based on event category, severity, certainty, and urgency. The matrix and value for the SOP selection matrix for the bomb threat SOP is 7 and can be seen in the Figure 1.

A response plan then is used to define a link between the SOP selector value and an SOP to be applied – see Figure 2.

When an Intelligent Operations Center incident is created within Tivoli Service Request Manager, triggered by an event from Intelligent Operations Center, an SOP selector value for the Intelligent Operations Center incident is chosen, based upon the SOP selector matrix, which is based upon the event parameters. The Intelligent Operations Center events trigger Tivoli Service Request Manager to create an incident. Applying the event’s parameters to the selector matrix to create a selector value and matching that value to the Intelligent Operations Center response plan determines the SOP that is assigned to the event.

Figure 2. Response plan example in Tivoli Service Request Manager console
Response Plan example in Tivoli Service Request Manager console

(View a larger version of Figure 2.)

Current Intelligent Operations Center approach to SOP

An Intelligent Operations Center incident is created in Tivoli Service Request Manager each time an alert-type Common Alerting Protocol (CAP) message is received. An SOP is applied to the incident, and the activities portlet in the Intelligent Operations Center console displays any linked activities.

Although the portlets provided by the Intelligent Operations Center allow some level of interaction with the underlying Tivoli Service Request Manager activities, the interaction is limited and changes are not always reflected in the underlying artifact. To edit Intelligent Operations Center incidents and activities so that the changes are fully reflected in Tivoli Service Request Manager, a link is provided by the Intelligent Operations Center to the Tivoli Service Request Manager web UI. This UI does not follow the general Intelligent Operations Center UI approach and can be difficult to navigate for Intelligent Operations Center users.


Let's discuss an approach to extending the Intelligent Operations Center to support soliciting activity-specific feedback as a form. We won't focus on the development of the form or the business scenario.

The Intelligent Operations Center requires the following major components to support activity-specific forms:

  • A registry that maintains a relationship between activities and forms
  • A form container portlet that reacts to activity selections
  • A mechanism for persisting data structures for an activity instance
  • A mechanism for ending an activity

What follows is our approach to implementing these components.

Our addition to the current approach

The primary use case was to present activity-specific data to users, gather data from them, persist that data and use it in the context of a subsequent activity. To support this use case, we used and extended the functionality of some existing Intelligent Operations Center portlets.

We also retrieved extra incident data using the latitude and longitude of the incident to find out what recorded resources were located near the incident. This extra information was stored and linked to an incident so it could be both viewed and modified by different activities as part of the same incident. We provided extra functionality to allow the direct updating of an activity's status, which previously was done through the Tivoli Service Request Manager user interface using a link provided by the Intelligent Operations Center.

The diagram in Figure 3 shows the addition to the current Intelligent Operations Center support for activities functionality. On the left side there is the current Intelligent Operations Center flow and on the right side there is our addition. The numbers in the callouts on the right side represent the sequence of steps that our software components implement. We describe them in detail in the next section of this article.

Figure 3. Our approach on the current Intelligent Operations Center
Diagram with our approach on the current Intelligent Operations Center

Example scenario that uses our approach

The inspiration for the presented solution came from a need to support some standard operating procedures related to severe weather emergency management. After the Intelligent Operations Center recognizes an event that is escalated to an incident a sequence of activities will start in accordance with the corresponding SOP.

In reality some activities may require manual steps to be done by several Intelligent Operations Center users, such as the incident operator, the incident commander, or other public safety officials.

The following describes what happens:

  • The CAP comes in
  • Activity appears for the incident operator
  • The operator selects corresponding activity
  • A form is displayed which shows resources near the incident that need to be selected
  • The operator selects resources
  • The activity is marked as complete
  • Next activity appears
  • The incident commander sees list of resources selected by the operator
  • The commander authorizes the resources
  • The activity is marked as complete

Activities portlet modifications

The standard Intelligent Operations Center activities portlet code was cloned and modified to support the extra functionality that allows the communication with the servlet that retrieves extra activity data.

After the user selects the activity, the portlet calls the servlet with dojo.xhrGet method. The servlet URL takes two parameters: action named getActivityInformation and activityID. The dojo.xhrGet method also loads a callback function that is invoked when the data is returned from the server. The data returned is in JSON format. In the same callback function, the parsed response from the dojo.xhrGet servlet call is published with the dojo.publish method. Afterwards the activity data can be used by other portlets and widgets that exist on the same page where the activities portlet is placed. In our example, the forms portlet, which we describe later, uses them.

Servlet that retrieves extra activity data

When a user selects an activity in the modified activities portlet, the activities portlet publishes information about the selected activity to a Dojo topic. The information published to the topic should be able to uniquely identify the step in an SOP that corresponds to this activity, that is a step type.

We use a concatenation of the step number and the SOP identifier (ID) as our activity type, for example type = WCONFIRMED_20 for an activity corresponding to step 20 in a SOP called "WCONFIRMED".

This information isn't available in the activity portlet, so we used a servlet to retrieve the information from the Tivoli Service Request Manager web services MXWO and MXINCIDENT. We used Tivoli Service Request Manager web services because the Intelligent Operations Center database doesn't store the SOP ID in any of its tables.

The servlet takes a comma separated list of activity IDs as a parameter and returns an array of JSON elements where each element contains the following information about one activity:

Table 1. JSON elements returned by the servlet for each activity.
Element name Description
sequenceNo The step number in the SOP (WOSEQUENCE from MXWO web service).
ticketId The ID of the incident associated with the activity. (ORIGRECORDID from MXWO web service).
activityId The activity ID. (WONUM in the MXWO web service).
SoPId The identifier of the SOP. (TEMPLATEID from MXINCIDENT web service).
uniqueStepIdentifier The 'type' of the activity which is a concatenation of SoPId and sequenceNo.

Forms portlet

The forms portlet was designed to fulfill the desire to collect and associate data with an ongoing incident. When handling an emergency it might be necessary to fill in forms for approval of resource allocation, or to record information that was retrieved in one activity that can feed in to another activity at a later stage.

To achieve this, we developed a generic container that could load different widgets or "forms" for entering data or displaying previously collected data. We associated the forms themselves with activities in a standard operating procedure, so when a particular activity in a standard operating procedure came into effect, the container would display the correct form.


The forms portlet has two main functions. The first is to act on a selected activity by displaying the correct form for dealing with it. The form loaded will have it's own logic, so the container does not need to know more than which form to instantiate. The second is to end the activity after the form has been completed.

Instantiating a form

When an activity is selected, a message is propagated across the web page using a Dojo publish. The form container is subscribed to this publish, and uses the information sent to determine the correct form to load. A registry table in the database maps activity IDs to form class names and allows for an API call that passes back the class name of a form widget that is associated with the selected activity. Using reflection, the form container will create an instance of the desired form and pass in the information about the activity.

The form life cycle

Each form widget is a Dojo style widget, with it's own template and collection of APIs. Using the information passed to the form at creation time, the form widget can contact various API's to determine the current incident type, location, etc. Each form can have unique functionality to enable it to handle different activities. For example, one might create a form to show the resources in the area of the incident, allowing an operator to select the desired resources for handling a situation. The form can then persist the users input to the back end using API calls. This persisted data can then be used in further forms for the incident when viewing other activities. After the form has reached its desired endpoint it will notify the container it is finished.

Ending an activity

After a form is submitted, it passes a message back to the container to let it know that its life cycle has completed. When the container receives this message, it calls an API to end the activity for which it is displaying the current form. The container will then sit idle until a new activity is selected that has a corresponding form.

Servlet that updates activity status

This servlet allows the status of an activity to be updated in Tivoli Service Request Manager. The parameters passed are the activityId and the new status. The servlet uses the MXWO web service to update the status of the specified activity to the specified new status.

Additional tables in the database

The following tables were added to the Intelligent Operations Center database.


During handling of an incident, a user can enter data into a form as part of an activity associated with that incident. This registry table records data entered by users on these forms.

This table has one row for each form filled in by a user. The table has the following fields:

Table 2. IOC.JSON fields and descriptions.
Field name Description
ID Primary key for the table.
INCIDENT_ID ID of the incident.
FORM_ID Identifies a form in an incident.
JSON The data collected from the user with this form.

Each form instance is associated with an incident and is uniquely identifiable in the context of an incident.


This associates a form type to a step in a SOP, that is an activity type. The forms portlet uses this table to determine which form to display based on an activity type. We saw earlier that the type of an activity is the concatenation of the SOP identifier and the sequence number. The table has the following fields:

Table 3. IOC.FORMID field descriptions.
Field Description
ID Primary key for this table.
SoP_STEP The type of the activity which is a concatenation of SOP identifier and sequence number
FORM_ID Identifies a form type.


The IBM Intelligent Operation Center is a software platform that provides multiple integration points through which solution delivery organizations can provide domain accelerators. We illustrated a possible way for software architects and developers to problem solve and implement a solution for activities supporting standard operating procedures. Based on IBM products, the Intelligent Operations Center is solid and flexible enough to add implementations needed by customers.



Get products and technologies

  • Evaluation software: Find more trial software. Download a trial version, work with product in an online, sandbox environment, or access it in the cloud.
  • IBM Smarter City Solutions on Cloud: IBM Intelligent Operations Center on IBM SmartCloud offers a straightforward, user-based subscription service at a single price that includes all costs, including hardware, software, maintenance, support, and networking.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into developerWorks

ArticleTitle=Enhance IBM Intelligent Operations Center-based applications