Overview of the BMC Change Management integration

Notice

Support for integrating BMC Cloud Lifecycle Management with BMC Remedy OnDemand has been discontinued and will be removed fully in the next service pack release planned in 2018. BMC is no longer providing support for this integration.

This topic provides an overview of how you can perform an optional integration of BMC Change Management with a new installation of BMC Cloud Lifecycle Management. The topic contains the following sections:

BMC Change Management integration benefits (video)

The following video (3:39) provides an overview of the benefits of integrating BMC Cloud Lifecycle Management with BMC Change Management. (The video does not mention it, but you can now also synchronize with BMC Atrium CMDB, as described in Integrating with BMC Remedy ITSM.)

 https://youtu.be/k5PHJ8Yr8sk

Overview video series

See the following video series from BMC Communities to learn more about BMC Change Management integration.

Out-of-the-box support

Out of the box, only the provisioning of a service offering instance (with Day 2 - Apply Option Choice) is supported with the BMC Change Management integration.

However, the integration framework also supports various actions, such as start service offering instance, stop service offering instance, extend service offering instance, decommission service offering instance, modify server, start server, stop server, and add or remove storage.

The cloud administrator or a user with administrator permissions creating a service offering determines which change policy should be associated to the service offering. The end user who selects the service offering instance is typically unaware of the underlying change policy associated with that service offering.

Supported operations for change approval

BMC Cloud Lifecycle Management supports the following operations in relation to integration with BMC Change Management:

Value for ClassName

Available values for operation

ComputeContainer

  • start
  • stop
  • shutdown

ServiceOfferingInstance

  • startCompute
  • stopCompute
  • decommission
  • extend
  • shutdownCompute
SoftwareContainer
  • start
  • stop

Artifacts deployed from CLM AR

The following artifacts are deployed on BMC Cloud Lifecycle Management from BMC AR System server (CLM AR):

  • Distributed Logical mapping: CORPORATE-DESTINATION-SERVER logical name with dummy value of <CORPORATE-DESTINATION-SERVER>
  • Distributed Pool: CLMPool1
  • Distributed Mappings:
    • DIST-CMDB:CSM_TO_CORP-BMC_BusinessService
    • DIST-CMDB:CSM_TO_CORP-BMC_Component_WeakChildren
    • DIST-CMDB:CSM_TO_CORP-BMC_Cluster
    • DIST-CMDB:CSM_TO_CORP-BMC_Component_SOI_BusinessService
    • DIST-CMDB:CSM_TO_CORP-BMC_Component
    • DIST-CMDB:CSM_TO_CORP-BMC_ComputerSystem
    • DIST-CMDB:CSM_TO_CORP-BMC_ConcreteCollection
    • DIST-CMDB:CSM_TO_CORP-BMC_ContractLine
    • DIST-CMDB:CSM_TO_CORP-BMC_Dependency_WeakChildren
    • DIST-CMDB:CSM_TO_CORP-BMC_Dependency
    • DIST-CMDB:CSM_TO_CORP-BMC_LogicalSystemComponent
    • DIST-CMDB:CSM_TO_CORP-BMC_ConnectivityCollection
    • DIST-CMDB:CSM_TO_CORP-BMC_LogicalDisk
    • DIST-CMDB:CSM_TO_CORP-BMC_MemberOfCollection
    • DIST-CMDB:CSM_TO_CORP-BMC_Product
    • DIST-CMDB:CSM_TO_CORP-BMC_MemberOfCollection_BMC_SoftwareContainer
    • DIST-CMDB:CSM_TO_CORP-BMC_OperatingSystem
    • DIST-CMDB:CSM_TO_CORP-BMC_Organization
    • DIST-CMDB:CSM_TO_CORP-BMC_Person
    • DIST-CMDB:CSM_TO_CORP-BMC_ProtocolEndpoint
    • DIST-CMDB:CSM_TO_CORP-BMC_ResourcePool
    • DIST-CMDB:CSM_TO_CORP-BMC_ServiceOffering
    • DIST-CMDB:CSM_TO_CORP-BMC_ServiceOfferingInstance
    • DIST-CMDB:CSM_TO_CORP-BMC_SoftwareContainer
    • DIST-CMDB:CSM_TO_CORP-BMC_StorageExtent
    • DIST-CMDB:CSM_TO_CORP-BMC_StorageVolume
  • Filters:

    • DIST-CMDB:CSM_TO_CORP-BMC_Cluster_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_Component_BMC_BusinessService_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_Component_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_Component_HostedSystemComponents_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_ComputerSystem_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_ConnectivityCollection_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_ContractLine_C_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_ContractLine_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_ContractLine_MM_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_Dependency_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_Dependency_HostedAccessPoint_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_Dependency_TaggedWith_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_LogicalDisk_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_LogicalSystemComponent_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_MemberOfCollection_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_MemberOfCollection_SoftwareContainer_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_OperatingSystem_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_Product_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_ProtocolEndpoint_IPEndpoint_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_ProtocolEndpoint_LANEndpoint_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_ResourcePool_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_ServiceOfferingInstance_DSO_ROD
    • DIST-CMDB:CSM_TO_CORP-BMC_SoftwareContainer_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_StorageExtent_DSO
    • DIST-CMDB:CSM_TO_CORP-BMC_StorageVolume
    • DIST-CMDB:CSM_TO_CORP-BMC_StorageVolume_DSO

      The above mentioned artifacts are enabled. There are few more artifacts that are deployed but not enabled. You must not enable those artifacts.

  • Initial Load escalations:

    • DIST-CMDB: CSM_TO_CORP_CIs_BMC_ComputerSystem_InitialLoad
    • DIST-CMDB: CSM_TO_CORP_CIs_BMC_StorageVolume_InitialLoad
    • DIST-CMDB: CSM_TO_CORP_Rels_InitialLoad_BMC_Dependency_Component
  • Reconcilation job: BMC CSM Import (standard job with identification and merge activities)
  • Data set: BMC.IMPORT_CSM 



Out-of-the-box change policies

A change policy determines how the service request is processed in BMC Change Management. Out of the box, the following types of change policies are available:

  • No Change Required
  • Change Approval Required
  • Pre-Authorized Change
  • Audit-only Change

The change class indicates the urgency of the change request.

Note

Except for the No Change Required policy, each change policy is mapped to a change class. 

The following table maps a change policy to a change class attribute in BMC Change Management:

Change policy to change class mapping

Change policy

Change class

Description

Change Approval Required

Standard

Indicates a change that requires approval.

Typically, this policy is pre-approved and only requires approval by the Infrastructure Change Manager. It follows the out-of-the-box change process defined by ITIL specifications.

Pre-Authorized Change

No Impact

Indicates a change that has no impact on the infrastructure and does not require approval.

For example, a cloud end user requests a low-cost service offering instance that does not require a manager's approval. By default, this type of change follows the Business Approval - No Impact phase and moves to Scheduled status. Use this process for pre-approved No Impact changes where the change is automatically scheduled.

Audit-only Change

Latent

Indicates a change that has already been performed.

For example, a task implementer assigned to replace the hard drive on a computer decides to upgrade the memory while working on the computer. Latent timing automatically sets the request status to Completed after you save the change request.

The following table maps change policy to a BMC Cloud Lifecycle Management change template.

Note

Except for the No Change Required policy, each change policy is mapped to a BMC Cloud Lifecycle Management change template.

Change policy to cloud change template mapping

Change policy

BMC Cloud Lifecycle Management change template

Change approval required

CLM: Manual change

Pre-Authorized change

CLM: Pre Authorized change

Audit-only change

CLM: Audit only change

By default, a standard task template, Standard Cloud Task, is assigned to the policies that are mapped to change templates. The following figure illustrates the relation of a cloud service request to a change request:

About the BMC Cloud Lifecycle Management change process

The BMC Cloud Lifecycle Management change process differs from the standard change process. The BMC Cloud Lifecycle Management process does not require manual intervention by the Change Manager or Change Coordinator. For more information about user roles in BMC Change Management, see User roles. BMC Cloud Lifecycle Management does not use the standard change process stages, such as Request for Change, Scheduled for Review, and Scheduled, which require manual intervention.

The BMC Cloud Lifecycle Management change policies follow the change process stages as shown in the following figure:

A change request initiated by BMC Cloud Lifecycle Management already contains attributes and tasks. Therefore, the Change Manager or Change Coordinator does not need to add or update the change request. However, the Change Approver must approve or reject a change request by using the Change Approval Required policy.

Typical request workflows

The process workflow follows the information present in the change policy and the change template.

Typical flow of an audit-only change request

The service requests assigned to the Audit-only Change policy do not execute tasks in BMC Cloud Lifecycle Management. The status of the change request is automatically changed to Completed.

Typical flow of a pre-approved change request

The service requests assigned to the Pre-Authorized Change policy are automatically approved.

Typical flow of a change request that requires approval

The cloud end user or administrator initiates a service request by using the BMC Cloud Lifecycle Management portal. When the service request is initiated, a change request is automatically created in BMC Change Management. The change request is assigned the Draft status.

The task-related data is automatically populated for the standard cloud task depending on the information in the change policy and the associated change template. The status of the change request is changed to Request for Authorization.

The approver for the specified cloud change approval process approves or rejects the change request depending on the change class associated with the change template. The Change Approver does not need any special permissions to approve or reject a change request approval.

  • If the approver for the specified cloud change approval process approves the change request, the status of the change request is changed to Scheduled.
  • If the approver for the specified cloud change approval process rejects the change request, the status of the change request is changed to Fail, and the tasks associated with the service request are canceled.

When the change request approval is approved, the tasks related to the service request are executed in the BMC Cloud Lifecycle Management portal. The status of the change request changes to Approval Pending:In Progress. When the tasks are completed, the status of the change request is changed to Completed. Depending on the approval rules defined, the status of the change request is changed to Closed.

Typical flow of CMDB CI synchronization for BMC Remedy ITSM and BMC Remedy OnDemand

The cloud end user or administrator uses the BMC Cloud Lifecycle Management portal to initiate a service request. Provisioning or other actions are performed in BMC Cloud Lifecycle Management based on the service request.

Each update of a cloud object and its relationship populates a DSO record. An Add, Modify, or Delete action is performed in the corporate CMDB CI for such cloud objects according to the CMDB mapping table. All of these records are populated in the BMC.CSM_IMPORT data set.

The ITSM administrator manually triggers a reconciliation job, or a scheduled reconciliation job can periodically trigger the job. The job checks each record in the IMPORT.CSM data set and reconciles the equivalent record in the BMC.ASSET data set (the master copy of the CMDB CIs).

The ITSM administrator or a user can then use the CMDB CI explorer to see the CMDB CIs for each resource that BMC Cloud Lifecycle Management provisions and updates. The administrator or user can relate the CIs to any incident, problem, or change requests in the Corporate ITSM.

Typical flow of CMDB CI synchronization for BMC Remedyforce

The cloud end user or administrator uses the BMC Cloud Lifecycle Management portal to initiate a service request. Provisioning or other actions are carried out in BMC Cloud Lifecycle Management based on the service request.

On a periodic basis, a process in BMC Cloud Lifecycle Management fetches all added, modified, and deleted cloud objects related to servers from BMC Cloud Lifecycle Management:

  • All cloud objects created in BMC Cloud Lifecycle Management are translated as a CMDB CI record and populated in the Corporate ITSM CMDB repository according to the CMDB mapping table.
  • All cloud objects updated in BMC Cloud Lifecycle Management are translated as a CMDB CI record and updated in the Corporate ITSM CMDB repository according to the CMDB mapping table.
  • All cloud objects deleted in BMC Cloud Lifecycle Management are deleted from the Corporate ITSM CMDB repository.
  • All relationships between CIs are created and updated according to the created and updated CMDB CI records.

The ITSM administrator or a user can then use the CMDB CI explorer to see the CMDB CIs for each resource that BMC Cloud Lifecycle Management provisions and updates. The administrator or user can relate the CIs to any incident, problem, or change requests in the Corporate ITSM.

Where to go from here

Depending on what product your company is using, review one of the following topics to integrate with BMC Change Management:

Was this page helpful? Yes No Submitting... Thank you

Comments