From
the time of its creation to the time that it is no longer needed, a CMDB CI would typically
transition through several operational states while undergoing various operations. CI LIfecycle
Management provides the mechanism to define states and actions for a CI and lets you apply
appropriate actions based on a CI's state to tailor the management of CI lifecycle to business
needs.
Terms associated with CI Lifecycle Management:
- Operational states
- A set of states that a CI can be at such as 'Operational' or 'Repair in Progress'. A CI can
be associated with only a single operational state at any given time. The choices for
operational states are based on the operational_status field in the
[cmdb_ci] table. There are several operational states that are defined in the base
system such as 'Retired' and 'Repair in Progress'. You can modify this list to reflect
operational states that are relevant in your business.
Note: By default, Service Mapping
is configured to ignore all host CIs for which the value of Operational status
[operational_status] is not 1 (Operational) or the value of status [install_status] is
100 (absent). For additional information about this behavior, see
Preparing customized ServiceNow deployments to work with Service
Mapping [KB0647574] in the HI Knowledge Base.
CI Lifecycle Management
allows multiple operators and automations to simultaneously set different operational
states of a CI. Since a CI cannot be associated with multiple operational states, it is
important to configure each operational state with a priority. These priorities are then
used in such situation to determine which of the operational states is the cumulative
operational state.
- CI actions
- A
set of actions that can be applied to a CI during its lifetime. You can define CI
actions that are relevant in your business.
- Compatible CI Actions
- CI Lifecycle Management allows a CI to have multiple active CI actions simultaneously,
however they must be specifically defined as compatible. By default, there are no two
actions for a CI that are compatible with each other. You can change this behavior by
specifying pairs of actions that are compatible and thus allowed to be applied
simultaneously to a CI. For example, you can specify that the ‘Patching’ and the
‘Provisioning’ CI actions are compatible making it possible to apply both simultaneously
to a CI.
- Not Allowed CI Actions
- By default, any CI action can be applied to any CI. You can restrict this behavior by
defining a rule that an action is not allowed for a CI when it is in a specific
operational state. For example, you can define a Not Allowed CI Action in which it is
not allowed to apply the 'Provisioning' action to a Linux Server that is in a
'Non-Operational' state.
- Not Allowed Operational Transitions
- By default, transitions are allowed from any operational state to another. You can restrict
this behavior by defining a rule that for a specified CI, a transition from a certain
operational state to another operational state is not allowed. For example, you can
define that for a Linux Server it is not allowed to transition from 'Repair in progress'
to 'Non-Operational'.
- Requestor
- A requestor can be a workflow or a non-workflow operator that is trying to set operational
states and apply CI actions. Each requestor has an associated requestor ID that is a
GUID and that can be an active workflow context or a non-workflow registered operator
ID.
- Lease time
- A time period that each requestor (especially non-workflow operators) can provide, during
which a specified CI action is allowed to be active for a specified CI.
CMDB CI Lifecycle Management provides a set of APIs to manage CI operational states and CI
actions. And the UI where you define a set of rules to restrict certain operational state
transitions and to restrict actions based on operational states. It also provides a mechanism
to audit CI operational state and CI actions during the entire CI lifecycle.
Providers such as automation, workflows, or Change Management can use CI Lifecycle Management
as a mechanism to manage CI operational states and apply CI actions. By default, the behavior
of CI Lifecycle Management has no restrictions on some operations, and full restrictions on
other operations. The CI Lifecycle Management UI lets you modify this default behavior by
specifying Not Allowed CI Actions, Compatible CI Actions, and Not Allowed Operational
Transitions that restricts some operations and enables for others.
With CI Lifecycle Management you can:
- Manage CI operational states and CI actions throughout the entire CI lifecycle.
- Manage CI operational state transitions.
- Restrict certain operational state transitions.
- Associate certain actions for certain CI types that are in specific operational state.
- Restrict IT Service Management applications based on CI operational state.
- Audit CI operational states and CI actions during the entire CI lifecycle.
Lifecycle management APIs
CI Lifecycle Management provides a set of APIs to manage CI operational state and CI actions
during the entire CI lifecycle. All restrictions and allowances specified by rules in the UI
are enforced when state management APIs run, and if an API attempts to perform a restricted
operation, the operation is blocked and an error is logged.
Registering
requestors
When using the lifecycle management APIs to apply CI actions, requestors are required to be
registered and to obtain a requestor ID which is unique within the lifecycle management
tables. To register and to obtain a requestor ID, non-workflow users should call the
registerOperator API. Workflow users can use the active Workflow
context as the requestor ID, and they do not need to explicitly call
registerOperator.
After completing the CI lifecycle operations, the requestor should call the
unregisterOperator API to unregister. All the state management records
associated with that specific requestor ID are then marked as inactive or they are removed
by the CI Lifecycle Management — Restore Internal State Management
Tables scheduled job.
Integration with Incident Management
and Problem Management
A base instance includes the pre-defined CI action
CreateTask used for creating a task for a CI. New instances have a
pre-defined Not Allowed CI Action, specifying that the CreateTask action is not allowed for
any CI with a Retired operational state. This restriction is integrated
with Incident Management and with Problem Management to prevent the creation
of incident or problem tasks for retired CIs. The CreateTask CI action
is used as a reference qualifier to the Configuration Item field of the
Incident/Problem tables. In a new incident or problem, CIs in which Operational
Status is Retired — are filtered out from the Configuration
Item list on the form. For more information about reference qualifiers, see
Reference qualifiers
.
Integration with Asset Management
In a base system, a CI's
Operational Status field and the
Status/
Hardware Status (if its hardware) fields
are kept synchronized if one of the two fields' values is
Retired.
When
Operational Status of a CI is set to
Retired, then the
Status/
Hardware
Status field is automatically set to
Retired. In the
opposite direction, when the
Status/
Hardware
Status field of a CI is set to
Retired,
Operational Status is automatically set to
Retired too.
- When an Operational Status field changes from
Retired to another status, the CI’s
Status/Hardware Status field is set to
Installed.
-
When a CI’s Status/Hardware Status field
changes from Retired to another status, the
Operational Status field is automatically set to
Non-Operational.
The change of state from 'Retired' to another state is seldom, and by default, the
state is changed to 'Non-Operational'. However, this might not be the intended state
for the record. Therefore, it important that administrators review and manage the
state appropriately in this case.
Whenever CI’s Status/Hardware Status changes, it
is synchronized to the CI’s corresponding Asset State field, and vice
versa — keeping the CI’s Operational Status and the CI’s corresponding
Asset State synchronized.
For more information about mapping Asset State and
Substate fields to a CI's
Status/Hardware Status (if its hardware) field,
see Map asset state and CI hardware
status. And for more
information about retiring assets, see Retire assets.
