Managing Configuration Items › Configuration Audit and Control Facility (CACF) › How Change Verification Occurs

More information:

Managing Change Specifications

Change Specification Statuses

Managing Failed Verifications

Managing Undiscoverable Attributes

How Change Verification Occurs

When a user requests a save to a CI, CA SDM searches for applicable change specifications as it searches for all matches. The following information describes an applicable change specification:

• The CI in the change specification is the same as the one that is being saved.
• The Change Order is in a managed change state defined with Change Verification Active.
• The attribute in the change specification is the same as the attribute being updated.
• The change specification is active
• If there are no managed attributes being updated or policy in effect, the save proceeds uninhibited.

If the inbound data values match a change specification exactly, CACF considers the change specification as validated. Depending on the policy, verification closes any Incident that change verification created.

Verification take place when information from web clients, web services, or GRLoader update the CI while the Change Order and all underlying change specifications are undergoing verification. After all verifications for a Change Order complete, the Change Order can optionally promote to the next Change Order state automatically.

If the inbound data values do not match the values in the change specification, it is considered an incorrectly implemented or failed change and Incidents are created or appended to, depending on policy.

For example, CA SDM does not find applicable change specifications, but Change Orders exist in a change verification active state. These Change Orders specify the target CI and have no change specifications. CACF manages this change by policies which handle Change Orders without Specifications.

• If there are no applicable change specifications or Change Orders without specifications, the save operation is considered rogue.
• After all attributes have been processed, any policy that requested the inbound data to write to the TWA triggers.