Learning about federated data stored outside the CMDB

Federated data is data stored outside BMC Configuration Management Database (BMC CMDB) but linked to configuration items (CIs) so that it is accessible through BMC CMDB. The most common types of federated data are related information and detailed attributes.

Related information is 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 CMDB, but they are attributes that are not important enough to track at the level of a CMDB.

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

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

 Federated data

Federation Manager plugins and adapters provide the mechanism to connect the master BMC Configuration Management Database (BMC CMDB) to external sources of data, federating data from different types of repositories. The following figure illustrates the concept of federation between BMC CMDB and a federated Oracle database.

Federation between BMC CMDB and federated database

The following table explains these federation concepts.

Important federation concepts explained

As shown by the downward arrows in the illustration, BMC CMDB can establish links from its own data to the external data source, but the external source cannot establish links to BMC CMDB. Federated data is not bidirectional.

You can use any adapter in one or more plugins. For example, you might use a single JDBC adapter to configure two different plugins, with each plugin configured to connect with a different external database. BMC CMDB includes three adapters at installation:

• JDBC — Enables you to federate data from any JDBC-compliant database.
• CMDBf — Enables you to federate data from any CMDBf-compliant CMDB. If you have third-party CMDBs in your environment, you can use the CMDBf adapter. 
• 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 CMDB

BMC Configuration Management Database (BMC CMDB) enables you to configure federation through retrieval and launch methods.

• The retrieval method enables you to view federated data as if it were stored in BMC CMDB.
• The launch method enables you to view federated data through another application, such as a BMC Remedy 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 an external source has to offer.

Retrieval method of federation

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

Federation objects for the retrieval method

The 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 CMDB creates attributes to represent the fields from the external repository. Federated data classes that you create are subclasses of the BMC_FederatedBaseElement class.

The federated relationship class establishes a relationship between CIs stored in BMC 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.

Launch method of federation

With the launch method of federation, you define the method of viewing the data (such as opening the data on a BMC Remedy AR System form), and create a link between that data and CIs in BMC CMDB. For example, you could use the URL method to access any database to which you allow browser access, and you could use the BMC Remedy AR System query method to access data from a BMC Remedy AR System form.

BMC 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 CMDB metadata.

Federation objects for the launch method

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

The launch interface has 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 CMDB offers attribute substitution and foreign key substitution as ways to implement the launch method of federation.

Attribute substitution and federated data

Attribute substitution is the more straightforward method of federating data in context. The information in a launch interface can include placeholders representing attributes from the linked class. The values for those 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.

The following figure shows an example of this. 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 have data that also exists as attributes of CIs in BMC 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.