Tivoli Change Management Integration


Integration with Common

Integration with Tivoli Asset Management

Integration with Tivoli Probelm Management


Integration with Common

The Notification Monitor

Tivoli Change Management uses the Notification Monitor to:

To use the notification monitor, each person must be a user in Tivoli Change Management. Only people who are users can receive notifications.

System administration data

Tivoli Change Management accesses the following common tables in the database:

The information listed above must be accurately maintained for you to obtain the maximum benefit from Tivoli Change Management.

In addition, you must do the following in order for Tivoli Change Management to fulfill its role:


Integration with Tivoli Asset Management

Because Tivoli Change Management interacts with other applications, there are setup tasks that must be performed for the applications to work together. With the Tivoli Asset Management interface, Tivoli Change Management users can:

Setting up Tivoli Asset Management

Tivoli Change Management relies on the following base manager tables in Tivoli Asset Management:

These tables must be maintained and kept accurate for you to obtain the maximum benefit from Tivoli Change Management.

In addition, the following steps must be taken above the normal operation in order for Tivoli Change Management to work with Tivoli Asset Management:

Asset dynamics

When a change is marked as “Approved” in Tivoli Change Management, a planned event is created in Tivoli Asset Management for each asset modified or deleted by the change. Events are not created for inventory created on a later date.

When the change is marked as “Completed,” the planned events are converted into history events and history events are created for new inventory.

If desired, you can modify the name of the event type by changing the string R_INV_EFFECT_EVENT in the r_msgs.df file and reparsing.

Asset tags are checked for duplicates when being added from Tivoli Change Management using Tivoli Asset Management code.

Caution: If a change in Tivoli Change Management adds a piece of inventory and a piece of inventory is added in Tivoli Asset Management before the change is marked “Completed,” database errors occur.


Integration with Tivoli Probelm Management

The interface between the two applications is used in the following ways:

Creating a change from a problem

When a user creates a change from a problem, there are a few steps that always take place:

  1. The user is queried for a status code and a change category.
  2. The current problem is queried.
  3. The change requester is set to the logged user and the change location is set to the location of the first Tivoli Problem Management contact.
  4. The Change ID, Name, and Number defaults are created.
  5. The Date Requested and Date Needed are defaulted to $Today.
  6. The description of the change is set to the description from the problem session.
  7. The Problem ID is tagged as an associated problem within the change.
  8. Any models associated with the change category will be executed.

Note: To modify any of the above logic, modify the R_InitChangeFromProblem routine in rchg_bf.kb.

Configuring Hot News

The following steps occur when creating a Hot News for Tivoli Problem Management:

  1. The active flag is set to True.
  2. The date, time, and time stamp are defaulted to the current values.
  3. The aid_type is set to C_HOTNEWS and the usage_count is initialized to 0.
  4. The solution and aid IDs are initialized.
  5. The event_begin_date and the event_begin_time are set to the appropriate values based on the earliest schedule task date and the number of days specified in the impact.
  6. The title and description are created based on the change_id and the description.
  7. The event_end_date, event_end_time, SCIM, and location_id are set to $UNKNOWN.

Note: To modify any of the above logic, modify the function R_SendHotNews in the file rchg_bf.kb.

Problem Status Code

The Problem Status Code preference in Tivoli Problem Management defines the status code that is sent back to all problems attached to changes when that change request is completed. If no preference is defined, no status code is sent and an error appears.

No checking is performed on the problem status code that is typed. Therefore, if a nonexistent code is typed, database errors occur whenever Tivoli Change Management attempts to update the PROBLEMS table.