Tivoli Change Management Integration
Integration with Common
Integration with Tivoli Asset
Management
Integration with Tivoli Probelm
Management
Tivoli Change Management uses the Notification Monitor to:
- Notify the help desk of the potential impacts of a change
- Notify impacted personnel when a change involves inventory with a connectivity link, if
you also use Tivoli Asset Management
- Notify approvers when a change is submitted for their approval
- Notify a requester and the person assigned to a change of the approval status
- Notify a changeâ™s resources of the start of their tasks
To use the notification monitor, each person must be a user in Tivoli Change
Management. Only people who are users can receive notifications.
Tivoli Change Management accesses the following common tables in the database:
- People
- Locations
- Organizations
- Groups
- Security rights for users and groups
- Notification methods for users and groups
- People-to-contact mappings
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:
- Each organization used as an approver in Tivoli Change Management must have one member
who is granted a title. This person receives notifications from Tivoli Change 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:
- Select inventory to add, update, and specify deleted inventory from the Tivoli Change
Management application as part of a change
- Generate planned events and history records in Tivoli Asset Management for inventory
affected by a change
- Access data managers in Tivoli Asset Management wherever a Browse button appears
- Access people records from Tivoli Asset Management
Tivoli Change Management relies on the following base manager tables in Tivoli Asset
Management:
- ORGANIZATIONS
- LOCATIONS
- CONNECTIONS
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:
- Specify a title holder for each organization in Tivoli Asset Management to use as an
approver in Tivoli Change Management. An organization that is assigned to a task as a
resource does not receive notifications unless it has a designated title holder.
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.
The interface between the two applications is used in the following ways:
- Help desk analysts can create a change from a call registration or an active problem in
Tivoli Problem Management.
- Time-sensitive bulletins (Hot News) can be sent to help desk analysts to inform of
requested changes (specified in a model or change).
- The Tivoli Problem Management notification monitor is used to send notifications to
impacted personnel, assigned resources, approvers, and requesters.
- The Tivoli Problem Management Escalation Monitor is used to escalate changes, tasks, and
approvals and send escalated notifications to the specified users.
- Tivoli Change Management sends a problem status code back to an attached problem when
the change is completed and closes the problem ticket.
- A requester can attach a problem to a change created in Tivoli Change Management.
- Tivoli Change Management performs keyword searches on problem descriptions as part of
its impact analysis to find past problems that may have an impact on a change.
- The Tivoli Problem Management adl320.dll file includes text retrieval routines for
performing keyword searches.
When a user creates a change from a problem, there are a few steps that always take
place:
- The user is queried for a status code and a change category.
- The current problem is queried.
- 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.
- The Change ID, Name, and Number defaults are created.
- The Date Requested and Date Needed are defaulted to $Today.
- The description of the change is set to the description from the problem session.
- The Problem ID is tagged as an associated problem within the change.
- 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.
The following steps occur when creating a Hot News for Tivoli Problem Management:
- The active flag is set to True.
- The date, time, and time stamp are defaulted to the current values.
- The aid_type is set to C_HOTNEWS and the usage_count is initialized to 0.
- The solution and aid IDs are initialized.
- 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.
- The title and description are created based on the change_id and the description.
- 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.
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.