Federated data

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

Federated data is data stored outside BMC Helix CMDB but linked to configuration items (CIs), so that it is accessible through BMC Helix CMDB.

Types of federated data

These are the most common types of federated data are:

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 information that can be federated are invoices, purchase orders, and printer maintenance records.

Benefits of creating federated data

These are the benefits of federating non-essential data outside the CMDB:

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:

By using the Federation Manager plug-ins, you can connect the master BMC Helix CMDB to external sources of data 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.

Federation between BMC Helix CMDB and federated database

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 itself.

The following table explains these federation concepts.

Important federation concepts explained

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 three adapters at installation:

JDBC — Enables you to federate data from any JDBC-compliant database.
AR — Enables you to 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 retrieval and cross-launch 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.

These methods enable you to retrieve data in the context of a configuration item (CI). That is, you want data that is relevant to a particular CI, not every piece of data that an external source has to offer.

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 BMC Helix CMDB data through such tools as CMDB Explorer and CMDB Impact Simulator.

Federation objects for the retrieval method

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.

Note

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.

Federation objects for the cross-launch method

A CI class or instance has a cross-launch link relationship to a launch interface, which defines the information necessary to access a particular piece of federated data.

The launch interface contains a federated product link relationship from a federated data store, which names an external source of data. Because an external source of data might offer several types of federated data, each federated data store can be linked to multiple launch interfaces.

If foreign key substitution is used, the federated data store also has one or more federated key link relationships to CIs. This relationship carries the key value that identifies the federated data for the CI.

BMC Helix CMDB offers attribute substitution and foreign key substitution as ways to implement the cross-launch method of federation.

Attribute substitution and federated data

In attribute substitution, the information in a launch interface includes placeholders representing attributes from the linked class. The values for these attributes are substituted when a user or application launches the link, which enables it to access a different set of federated data for each instance of the class. Attribute substitution is the more straightforward method of federating data in context.

The following figure shows an example of attribute substitution. The value of the Name attribute is substituted in the launch interface, so that the access string for Computer A queries for incident records where Machine = "Computer A" and the access string for Computer B queries for incident records where Machine = "Computer B."

Attribute substitution

Foreign key substitution and federated data

Some external sources of data do not contain data that also exists as attributes of CIs in BMC Helix CMDB, which means that you cannot use attribute substitution to match a CI to pieces of federated data. You can still federate this data in context by using a foreign key, a unique identifier in the data store that maps to a specific CI.

For example, you might have maintenance contracts for your office equipment, where the contracts do not see individual pieces of equipment. If you have no single piece of data to link the contract to a CI, you can create a foreign key link that enables you to identify the contract that is associated with a particular CI.

In addition to the relationship between the CI (or its class) and a launch interface that is required for any federation, using a foreign key also requires a relationship between the CI and the external source of data, containing the key. This relationship enables the key to be substituted in to the information in a launch interface whenever a link to that interface is launched from that CI.

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