Introduction to Change Management
Data Structures for Changes, Models, and Rules
This document is provided as a reference tool if you customize Tivoli Change Management. This document provides basic architectural information about Tivoli Change Management. It includes explanations for concepts like change management and guidelines for customizing the application.
Business is increasingly dependent on evolving technology and the changes that accompany it. As a result of this evolution, change management has become an integral tool in the business community. Because changes run the risk of impeding or interrupting operations, they must be created and managed using a planned process that eliminates or minimizes any potential negative effects.
With Tivoli Change Management, your organization can establish procedures, rules, and policies to propose changes, analyze potential impacts, implement changes, monitor the progress of changes, and automatically notify appropriate personnel of milestones.
The state records in the Tivoli Change Management source code are listed in the following table.
State Record For | Name |
Changes | R_G_SChange |
Models | R_G_SModel |
Rules | R_G_SRule |
The state record is the primary structure for changes, models, and rules. The state records carry the information that applies to the current change, model, or rule, along with any other pertinent information. A state record consists of the following:
A CStack is a stack is a stack of current state records. There is a separate CStack for chages (R_G_SChange.CStack), models (R_G_SModel.CStack), and rules (R_G_SRule.CStack)
Keeping with the traditional rules of a "stack," the current state record is always on top. In the scenario where a change request and an activity have been added the activity is currently being edited, the root change will be positioned on the bottom of the Change CStack and the activity on top.
Activity 2 of Activity 1 |
Activity 1 of Change 1 |
Change 1 |
Activities is a list of the current and initial states of the activities for a change. The structure looks like this:
Note: There is not an activities field in the rule state record.
AChanges, AModels, A/Rules are lists of the initial states of changes models, or rules. They act as a cache. If multiple changes are queried, all are kept. If the change is acted upon (edited, viewed, and so on) no database read is required because it is already held in AChanges.
IChanges and IModels are the temporary storage areas for modifications made to attachments. Until the modifications are saved and loaded into the AChanges or IModels list, they are stored here. IChanges or IModels are used to prevent writing to the database until modifications are permanent. Note that IRules does not exist.
The CP_Index denotes the specific instance of the list of subordinate elements (impacts, schedules, etc.) for the change. For example:
Position in List | Schedule Name |
1 | Task 4 |
2 | Task 6 |
3 | Task 8 |
If Task 6 is edited, the CP_Index is set to 2. No CP_Index field exists for the rule state record.