Federated data


Use data federation in BMC Helix CMDB to access and view external data sources without importing them into the database, ensuring real-time data availability while maintaining system efficiency.

The following data types are the most common types of federated data:

  • Related information or information about a CI that does not itself qualify as a CI and therefore should not be stored in a CMDB.
  • Detailed attributes are attributes of CIs stored in BMC Helix CMDB, but they are attributes that are not important enough to track at the level of a CMDB.

A few examples of federated data are invoices, purchase orders, and printer maintenance records.

By federating non-essential data outside the CMDB, you achieve the following benefits:

  • CMDB is easier to manage when it has only the essential data.
  • CMDB is more efficient and has better performance.


In BMC Helix CMDB, not only can you view federated data but you can also retrieve that data for use by a consuming application as if it were part of BMC Helix CMDB. This feature enables you to access outside data from the central CMDB repository by using your existing data store infrastructure.

The following figure illustrates both types of federation data for a BMC_ComputerSystem instance named Computer A. The instance can be linked to incident records about Computer A, which is related information, and also linked to the discovered attributes of Computer A that were not imported into BMC Helix CMDB:

image2019-9-27_9-4-47.png

By using the Federation Manager plug-ins, you can connect the BMC Helix CMDB to external data sources and federate data from different types of repositories. The following figure illustrates the concept of federation between BMC Helix CMDB and a federated Oracle database:


image2019-9-27_8-39-0.png

Important

Federated data is not bidirectional. BMC Helix CMDB can establish links only from its own data to an external source, but not from an external source to BMC Helix CMDB.

The following table explains some key concepts of federation:



You can use any adapter in one or more plug-ins. For example, you might use a single JDBC adapter to configure two different plug-ins, with each plug-in configured to connect with a different external database. BMC Helix CMDB includes the following adapters at installation:

  • JDBC — Federate data from any JDBC-compliant database.
  • AR — Federate data from forms on any AR System servers.
  • If you want to connect to an external data source of a different type, you must first create a new adapter.

Federation methods in BMC Helix CMDB

BMC Helix CMDB enables you to configure federation through the following methods:

  • The retrieval method enables you to view federated data as if it were stored in BMC Helix CMDB.
  • The cross-launch method enables you to view federated data in another application, such as a AR System form.


Retrieval method of federation

With the retrieval method of federation, you create BMC Helix CMDB classes to represent data that is stored outside of BMC Helix CMDB. You can also create federated relationship classes that join classes that are already part of the BMC Helix CMDB data model with the new federated data classes. This method enables you to view the relationships between federated data and CMDB data through BMC Helix CMDB components such as CMDB Explorer and CMDB Impact Simulator.

The following image illustrates the retrieval method for federation objects:

image2020-7-13_16-53-6.png

A federated data class represents a set of information on the external source of data, such as a table on a database, so that data can be viewed within the context of the data model. As part of the process of creating a federated data class, BMC Helix CMDB creates attributes to represent the fields from the external repository. Federated data classes that you create are subclasses of the BMC_FederatedBaseElement class.

A federated relationship class establishes a relationship between CIs stored in BMC Helix CMDB and external data. Federated relationship classes that you create are added to the data model as subclasses of the BMC_FederatedBaseRelationship class. The source class of the relationship must be in the BMC_BaseElement hierarchy of classes, and the destination class of the relationship must be a federated data class.

A federated data class represents information from an external data source, such as a database table, making it accessible within the data model. When a federated data class is created, CMDB generates attributes to represent fields from the external source. These classes are subclasses of BMC_FederatedBaseElement.

A federated relationship class defines a connection between CIs stored in CMDB and external data. These classes are added to the data model as subclasses of BMC_FederatedBaseRelationship. The source class must belong to the BMC_BaseElement hierarchy, while the destination class must be a federated data class.

Important

Federation does not support Nvarchar fields, because of which if an external database (federated data) is mapped to the BMC_FederatedBaseRelationship class, this data is converted to the character data type.

Cross-launch method of federation

In the cross-launch method of federation, you define the method of viewing the data such as opening the data on a AR System form, and then create a link between that data and CIs in BMC Helix CMDB. For example, in CMDB Portal in Federation Manager > Access Method, use the URL option to link a database through a browser, and use the AR System option to link the data through an AR System form.

BMC Helix CMDB uses several types of objects to implement federation. The following figure illustrates these objects, each of which is represented by a class in the BMC Helix CMDB metadata.

image2020-7-13_17-11-15.png

A CI class or instance has a cross-launch link to a launch interface, that provides the necessary details to access specific federated data.

The launch interface connects to a federated data store through a federated product link, identifying the external data source. Since an external source can provide multiple types of federated data, a federated data store can link to multiple launch interfaces.

If foreign key substitution is used, the federated data store establishes federated key link relationships with CIs, carrying key values that identify the federated data for each CI.

CMDB supports attribute substitution and foreign key substitution for implementing cross-launch federation.

Attribute substitution and federated data

In attribute substitution, a launch interface contains placeholders for attributes from the linked class. When a user or application launches the link, these placeholders are replaced with actual values, allowing access to different federated data for each class instance. This is a simple and effective way to federate data in context.

For example, if the Name attribute is used in attribute substitution, the launch interface dynamically adjusts the access string. For Computer A, it queries incident records where Machine = "Computer A", and for Computer B, it queries records where Machine = "Computer B".

The following image illustrates the attribute substitution concept:
image2020-7-13_17-47-15.png

Foreign key substitution and federated data

Some external data sources lack attributes that match CIs in BMC Helix CMDB, making attribute substitution impossible. In such cases, foreign key substitution can be used. A foreign key is a unique identifier in the external data store that maps to a specific CI.

For example, if maintenance contracts don’t list individual equipment, a foreign key link can associate a contract with the correct CI.

Foreign key substitution requires both a CI-to-launch interface relationship and a CI-to-external data relationship. This allows the key to be inserted into the launch interface when the link is accessed.

Important

You can get the same functionality by adding an attribute to classes in the Common Data Model (CDM) and storing the key in the CDM, or by adding an attribute in your federated data store and storing the instance ID or reconciliation ID of CIs in the federated data, which enables you to use attribute substitution instead. This provides faster performance when accessing federated data and eliminates the management of federated key relationships. Add an attribute in BMC CMDB only if the attribute will be populated for most instances of the class.

Testing your knowledge

Check your knowledge. See if you can answer each question. Click the questions to view the answer.

What are the benefits of federation of data?
  • CMDB is easier to manage when it has only the essential data.
  • CMDB is more efficient and has better performance.
What most important methods to access federated data in CMDB?
  • Retrieval method of federation
    You create BMC Helix CMDB classes to represent data that is stored outside of BMC Helix CMDB. You also create federated relationship classes that join classes that are already part of the BMC Helix CMDB data model to the new federated data classes.
  • Cross-launch method of federation
    You define the method of viewing the data (such as opening the data on a AR System form), and create a link between that data and CIs in BMC Helix CMDB.
What kind of data can be considered for federation?

Data such as maintenance records, purchase records of a CI, user manuals, and documentation can be stored in an external database and accessed by using federation.

Do you want to learn more?

Federating-to-databases-that-are-not-JDBC-compliant-by-registering-the-data-adapter-with-AR-System

Accessing-external-data-through-CMDB-by-using-Federation

 

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