System Integration Key Data Standard

Intended Audience and Contact Information

Contact Chief Data Officer, Office of the CIO
Intended audience: Internal UBC
UDM Domain All

Change Log

Standard Version Date Change Log
2022-07-21

1.0 The integration key generation point is altered (i.e. SoR Cache, instead of SoRef Adaptor)

2.0 Addition of Workday to the Dispensation section
2022-03-09

Reference Data Compliance for Data Integration sub-section of Compliance section added

Purpose

This standard aims to achieve consistency with how Integration Keys are structured, generated and utilized. Integration Keys are referenced between two Online Transaction Processing (OLTP) systems that are communicating using a UBC integration service's Application Programming Interface (API).

The structure (format and name) of Integration Keys has major downstream impacts including:

  • The ability to manipulate objects and their values programmatically i.e. whether it is possible to access, integrate, and/or automate the management of business objects within the UBC application ecosystem;
  • Maintenance and sustainment of the Integration Key values. i.e. how confusing, difficult to remember, and/or outdated the keys become if they are not aligned with best practices.

Standard

Integration Key Structure

Integration keys are generated in the System of Record Cache when integration request is made by the UBC API (Common Service). See Figure 1 in the Appendix.

The following is the naming convention for an integration key:

«Component1»-«Component2»-«Component3»

  Component1 Component2 Component3
Rules SoR Business Object Name1 SoR Acronym2 SoR Unique Identifier3
Mandatory Mandatory Mandatory
Alpha only Alpha only Numeric or Alphanumeric only

For example: ArcGIS has been designated as the System of Record (SoR) for all BUILDING data at UBC. When Workday or any other system (SoRef) needs to reference BUILDING information, an Integration Key will be generated in a similar fashion to this:

Building-ArcGIS-2345678

1 Use an object or entity name in the SoR. Full names or acronyms can be used, but the format must be consistent once selected.
2 Accepted values only. Click here to access accepted application system acronym values. Reach out to the Enterprise Data Governance team if the reference list does not include the system name and acronym needed for your integration key.
3 Unique Identifier, can either be:

  • a Business (or natural) Key which is an attribute identifier that has business meaning and is also used to uniquely identify each record in a table or a business object; or
  • a Surrogate Key which is normally system generated to uniquely identify each record in a table or a business object.

Important Note:

  • If a Business (or natural) Key is available, it shall be used as the Unique Identifier.
  • The Integration key is ONLY utilized to communicate with the SoR where the information defined in Component1 originated.
  • Once an integration key has been generated by a SoRef, that key is utilized ONLY to communicate with the SoR where the information defined in Component1 originated.
  • An Integration Key can ONLY be generated using a Unique Identifier from the SoR.
  • An Integration Key can ONLY be used for UBC's APIs with the sole intention of integrating the data with other systems.
Integration Key Standard
Requirement Integration Key Standard
Allowable characters
  • alphanumeric characters allowed.
  • Allowable special characters include:
    • "_" (underscore) to be used to replace space within a component
    • "-" (dash or hyphen) to distinguish between different components
  • No other special characters can be used.
Mixed case Mixed case representation of configuration values is allowed. For example, Asset_Maintenance
Spaces Must not include spaces. Use "_" (underscore) for space.
Numbers Numbers must be none-zero and positive. Avoid using leading zeros at the beginning of Component 3 of the integration key. e.g. 00PR-1234
Descriptions Components must be named without including descriptions. They must be short and concise.
Integration Key Length Limit the integration key to no more than 64 characters.

Compliance

This standard must be complied with every stage of the data lifecycle with the exception of EDG approved dispensations (see Dispensation section):

  • All applications must define Integration keys as recommended in this standard.
  • Enterprise Data Integration must adopt this standard.

Reference Data Compliance for Data Integration

The use of accepted reference data values in this standard for data integration among applications must comply with the enterprise integration pattern of leveraging the reference data common service API (Application Programming Interface) published in UBC MuleSoft Exchange.

Any application that intends to access real-time, case-level reference data should have the application owner or manager complete and submit a Request API Access form.

For any compliance questions or requests for a dispensation temporarily, please contact the Enterprise Data Governance Team.

Dispensation

Workday

Workday is allowed to use its REFERENCE ID(s) as Integration Key. It shall be in the format as described in the Workday Reference Id Data Standard

Workday Integration Key Format and Components

The following structure has been adopted by Workday to structure their Reference ID, which will be made up of three components as shown below:

«Component1»-«Component2»-«Component3»


 Component1Component2Component3
Rules Workday Business Object Name
(Full_Name or Prefix) 		Environment Code
(6|3|16|9) 		Number
(non-zero)
Mandatory Mandatory Mandatory
Alpha Only See Environment Code table for more information Numeric Only

Please reach out to the Enterprise Data Governance team if a system cannot comply to this standard and requires a dispensation.

Appendices

UBC Integration Key generation and usage in system integration:

System Integration Key
Figure 1: Sample representation of Integration Key generation and usage