Learning about federated data which is stored outside the CMDB
Federated data is data stored outside BMC CMDB but linked to configuration items (CIs), so that it is accessible through BMC 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 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 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 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 CMDB.
Federated data
By using the Federation Manager plug-ins, you can connect the master BMC CMDB to external sources of data and federate 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
Important
Federated data is not bidirectional. BMC 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
Federation concept | Description |
|---|---|
Core BMC CMDB class | Stores Configuration Item (CI) instances (for example, |
Federated data class | Represents data that is stored externally (for example, data in an Oracle database). In the retrieval method of federation, you can use CMDB Explorer to view or query this data in the context of the data model. |
Federated relationship | Joins the core BMC CMDB classes with the federated data classes. |
Adapter | Provides the code-level connectivity between BMC CMDB and an external source of data. It enables you to federate data from various external data sources (for example, the Oracle adapter connects to a JDBC-compliant Oracle database). |
Plug-in | Provides access to an external source of data. The plug-in uses an adapter and other information, such as the user name and password required to access a database. |
Database | Contains the data in database tables that you do not want to store directly in the BMC CMDB. Examples of such data include incidents, change requests, and service records. |
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 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 CMDB
BMC 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 CMDB.
- The cross-launch method enables you to view federated data in another application, such as a 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 that 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 can also create federated relationship classes that join classes that are already part of the BMC CMDB data model with the new federated data classes. This method enables you to view the relationships between federated data and BMC 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 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 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 Remedy AR System form), and then create a link between that data and CIs in BMC 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 Remedy AR System option to link the data through an 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 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 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 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.
Comments
Log in or register to comment.