Skip to Content
Information
This version of the software is currently available only to customers in the Controlled Availability (CA) program.

Remote systems and identifiers

All interfaces that connect with a BMC Helix ITSM system that is being consolidated into another system are impacted by the change to the architecture and potentially to the application, particularly when a consolidation is combined with an ITSM upgrade. However, the transformation of unique identifiers (which is typically performed as part of the consolidation) significantly impacts interfaces to systems that hold these unique identifiers.

From the perspective of consolidation, we can identify three classes of interface:

  • Architecture impact only
  • Data impact only
  • Unique identifier impact

Architecture impact only

This category includes interfaces that are impacted only by the change to the architecture that is being implemented as part of the consolidation. Interfaces in this category include LDAP integrations for authentication, incoming email integrations, CMDB discovery, and event monitoring of systems that create incidents.

For some integrations that send data into the BMC Helix ITSM system, the impact can be mitigated through the use of the infrastructure described in Redirecting-integrations.

Data impact only

This category includes interfaces that are impacted by the change in the ITSM application data structures that occur as part of a consolidation, either because of an application upgrade or because the new consolidated ITSM application does not match the source data structures. Examples include BMC Analytics and other data warehouse solutions that extract data from the BMC Helix ITSM system. For reporting systems, you might need to adjust the data structures and reports, and you might have to fully reload the data. This category of interface does not include systems that rely on the unique identifiers held in the BMC Helix ITSM system.

Unique identifier impact

Interfaces that rely on the unique identifiers include service-desk-to-service-desk (SD2SD) integrations. These interfaces are typically bi-directional and include multiple messages being sent between the BMC Helix ITSM system and the remote system through the life cycle of a ticket. Typically, the remote system will hold one of more unique identifiers for the tickets that are in scope of the integration. The messages sent between the BMC Helix ITSM system and the remote systems will include these unique identifiers so that updates and changes are routed to the correct ticket.

Following a consolidation, the unique identifiers that these remote systems hold are no longer synchronized with the unique identifiers held in BMC Helix ITSM. This might mean that a request to close an incident will refer to an invalid incident or to a wrong incident.

Consolidation does not impact remote systems that use GUIDs as the unique identifier for data held in BMC Helix ITSM. However, the majority of systems use the ticket number as this is human-readable and is guaranteed unique for the target BMC Helix ITSM system.

You can select between the following two strategies to mitigate the impact of the consolidation unique identifier transformation on remote systems:

  • Dynamically converting unique identifier
  • Transforming unique identifiers in remote systems

Dynamically converting unique identifiers

The interface that manages the exchange of data between the BMC Helix ITSM system and the remote system is re-engineered to allow unique identifiers to be dynamically transformed. This is practical only where the integration technology supports additional processing of the message. For example, a query via an AR System web service will not support additional processing, whereas the same query via Atrium Orchestrator will allow the request to be analyzed before being processed. In the case of a query, for example, the interface must be able to interpret a request for the Incident INC000000000123 to be interpreted as a request for INCPBJ000000123.

The key challenge the interface has with dynamic transformation of unique identifiers is that following consolidation, the BMC Helix ITSM system must have a mixture of prefixed and un-prefixed unique identifiers. Therefore, through the interface, a remote system might send a work log update intended for Incident INC000000000123 that should be applied to INCPBJ000000123 but in other cases be applied to INC000000000123. The interface will require some contextual information to make the correct decision about the incidents that the remote system is referring to when it provides a specific ticket number or other unique identifier. It might be possible to make this decision based on the originating system, company name or create date of the original ticket. However, implementing dynamic transformations of unique identifiers is complex, requires additional development and testing time, and adds complexity and performance overhead to the interface.

Transforming unique identifiers in remote systems

As part of the cutover process, all of the unique identifiers in the remote systems that refer to the BMC Helix ITSM system are transformed. Assuming the BMC Helix ITSM system data is held in a database, the same functions that BMC Helix Data Manager uses to transform the AR System unique identifiers can be applied to the remote system.

his strategy requires a single change to the remote system that can be quickly applied and rolled back. Furthermore, this approach does not require any changes to the mechanism of the interface or incur any performance overheads. We strongly recommend this approach where possible.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC Helix Data Manager 21.3