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

Unique identifier consolidation and transformation


The following categories of unique identifiers are used in AR System applications.

Category

Description

Request ID

The Request ID is the primary key for all AR System forms. AR System automatically generates a Request ID when a record is created in any form. Request ID is a string with a default and maximum length of 15 characters. When AR System generates a Request ID, it is padded with zeros. Therefore, the first record created for a form with a default Request ID length of 15 characters has a Request ID of 000000000000001.

Request IDs can be prefixed with an alphanumeric string. For example, the TMS:Task form has a prefix of TAS and a length of 15 characters, so the first record created has a Request ID of TAS000000000001.

Request ID has an enforced unique index on all forms ensuring that the Request ID is guaranteed to be unique within a form on AR System.

Group ID

Groups are used in AR System to control access to application functions and data. User are assigned membership of an AR System group to gain access to application functions or application data.

Groups are assigned a unique integer identifier called the Group ID. For example, the Incident Management application permission has a Group ID of 20004, but the Calbro company created as part of the sample data for an AR System instance has a Group ID of 1000000001.

Restricted access to data controlled by group membership underpins the multitenancy feature within a BMC Helix ITSM application. Each ITSM company and ITSM support group is associated with an auto-generated AR System group. If a user does not have membership of the group associated with an ITSM company or support group, they cannot see data associated with that company or support group. This behavior is controlled by the data held for each record in AR System in the Assignee Group field (field 112). Each record is stamped with the list of Group IDs for the groups whose users should be able to view and modify the record. Not all data is controlled by the Assignee Group feature. The range of data protected was considerably extended in ITSM 8.1 and later.

The Group ID is not guaranteed to be unique within the Group form, and it is possible to create (or import) multiple groups with the same Group ID. AR System application workflow ensures that any Group IDs created for a company or support group are unique.

Ticket Number

Ticket numbers are the public-facing unique identifiers for incidents, problems, changes, service requests, and a range of other entities including service request carts, SLA targets, and so on. These numbers are typically prefixed and 15 characters in length. For example, INC000001001802 is an example of a ticket number used for incidents. However, there is a wide variation in the format of these ticket numbers. Ticket numbers are unique and often used as a primary key for a record.

Globally Unique Identifiers

BMC Helix ITSM can generate globally unique identifiers (GUIDs). Unlike all the other types of unique identifiers, a generated GUID is unique between AR System instances. All other identifiers can be duplicated for different logical entities between systems. The BMC Helix ITSM application makes extensive, but not exclusive, use of GUIDs instead of Request ID as the primary key for data. In principle, use of GUIDs allows data configuration created in a development AR System to be more easily promoted to a production AR System without causing unique identifier clashes. Therefore, GUIDs are extensively used in the configuration of modules such as Service Request Management and Service Level Management. But the majority of transactional data that is not promoted between systems uses Request IDs instead of GUIDs.

GUIDs are character strings of up to 38 characters in length and can have an optional prefix of two characters added. An example of a GUID is AG4CA520524153J8j5SgB12jCgR_UA.

Consolidation challenges

The principle challenge in merging data from multiple AR System instances is the reconciliation of the unique identifiers used in the application data in each of the originating systems. While you can rely on GUIDs to be unique between different systems, Request IDs, ticket numbers, and Group IDs are not unique between systems. If data from one AR System instance is directly imported into another AR System instance, the following consequences are likely:

  • Records in the target system are overwritten with records from the source system with an unrecoverable loss of data such as incidents, problems, or changes.
  • Logical entities are corrupted by data being overwritten or sharing the same foreign key references.
  • Companies or support groups with the same Group ID in the source and target system can see or modify each other's data. In short, a straightforward import of data will fundamentally compromise an AR System application.

BMC Helix Data Manager provides the transforms unique identifiers in a consistent way during a data migration to ensure that they do not clash with the existing unique identifiers in the target AR System instance while retaining data integrity. This is achieved by transforming all fields that hold primary or foreign keys that are not unique between systems.

Unique identifier data transformation

The following table lists the unique identifier data transformation that BMC Helix Data Manager can apply during a data migration.

Identifier

Example

Transformation

Request ID

Using DF as the prefix:

  • INC00000000011 becomes INCDF000000011
  • 000000000002345 becomes DF0000000002345
  • PR00001234 becomes PRDF001234

BMC Helix Data Manager transforms Request IDs and ticket numbers in the same way. A prefix of up to 3 characters is injected into the Request ID or ticket number at the first non-alphabetic point in the identifier.
While the prefix applied to Request IDs and ticket numbers is generally a character prefix, you can also use a numeric prefix.

Ticket Number

Using DF as the prefix:

  • INC00000000011 becomes INCDF000000011
  • CHG000000002345 becomes CHGDF0000002345

 

Group ID

Using 22 as the prefix, 1000000027 becomes 1220000027.

Group IDs are integer values and therefore cannot be transformed by using a non-numeric prefix. BMC Helix Data Manager will add a numeric prefix of up to two digits after the first digit of the Group ID.

BMC Helix Data Manager prefixes only Group IDs that are not reserved for ITSM or AR System. This ensures that application permissions such as Incident Master are not transformed. (This would effectively invalidate the permission.) Only Group IDs in the following ranges are manipulated:

  • 60000
  • 60002 to 60099
  • 100000 to 999999999
  • 1000000000+ The Group ID prefix can be any numeric value that will not result in a transformed Group ID greater than 2147483647, which is the maximum value that can be stored in a SQL Server int column.

SLA ID

Using DF as the prefix, SLM00502 becomes DFSLM00502.

SLA IDs are used for SLA targets and agreements. These unique identifiers are similar to ticket numbers because they are generated unique identifiers with a character prefix. BMC Helix Data Manager transforms them differently due to the unique behavior of the ITSM application when processing SLA IDs.

The numeric portion of the SLA ID consists of only 5 numbers. This gives a theoretical maximum of 99,999 entities that can be created. However, due to the way that the AR System server reserves Request IDs, the numbers are consumed in increments of 100 every time an AR Server is restarted. This can very quickly consume the numeric portion. Therefore BMC Helix Data Manager preserves the numeric portion and adds the prefix at the start of the SLA ID.

You can easily configure these unique identifier transformations in BMC Helix Data Manager. Use a different prefix for each originating system you are consolidating.
In any consolidation scenario, it is possible for one (and only one) of the AR System instances being consolidated to avoid any transformation of unique identifiers, as the non-transformed identifiers will be as unique as the transformed identifiers after consolidation. The un-transformed data must be the first to be migrated into the target system, or be in place already. Otherwise, new records created in the target system (that is unprefixed records) will clash with the imported data.

Primary and foreign keys

BMC Helix ITSM has been developed over a long period of time by many different groups of developers working to different development standards. Consequently, the BMC Helix ITSM application might use Request IDs, GUIDs, or ticket numbers as the foreign key for a record.
In some cases, more than one of these unique identifiers can be used as the foreign key. For example, incident Work Log records are linked to the parent incident record using the ticket number and Request ID. The following diagram shows how three forms are linked by using three types of unique identifiers to the HPD:Help Desk form. This lack of consistency in the BMC Helix ITSM application directly contributes to the complexity of the data model.

chart1.png

To ensure referential integrity, BMC Helix Data Manager applies the correct type of transformation to all unique identifiers, whether used as primary or foreign keys during a data migration. This ensures that data being imported will not clash with existing data in the target system. It also ensures that all logical entities are composed correctly, regardless of their complexity.

The following diagram shows how primary and foreign keys are transformed to ensure referential integrity.

chart2.png

Impact of unique identifier transformation

BMC Helix Data Manager provides a fully automated capability for transforming unique identifiers as part of a consolidation operation. All the unique identifiers held within the BMC Helix ITSM data set are consistently and appropriately transformed. However, the transformation of the unique identifiers has an impact on these key areas:

  • ITSM application workflow that does not expect prefixed unique identifiers
  • Email sent from the BMC Helix ITSM system prior to the consolidation
  • Remote systems that hold the original, untransformed identifiers

 

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