Operation > Data Flow Management > Integrations > Integration Studio > Integration Studio Overview > Federation

Federation

An integration of Federation type includes data in the CMDB from other sources in such a way that the source of the data still retains control of the data.

You use the CMDB's federation capabilities to extend the scope of the existing Topology Query Language (TQL) capabilities to encompass data that is stored and maintained in an external repository. The ability to include such information is important as it prevents you from having to copy large amounts of data and, instead, bring it into your CMDB only when it is really needed.

Federation also has the benefit that the federated data does not burden the CMDB in terms of capacity; theoretically, you can set up an integration that federates trillions of CIs and relationships. Federated data is fetched at runtime, as requested, which lessens the impact on system performance.

Note The CMDB does not offer change tracking on federated data because the data does not reside within the CMDB and the CMDB is not notified when external data is modified.

Federated integration creates a federated integration point, which can then be used when defining TQL queries. For details on TQL, see Topology Query Language.

Note Federation can be configured in Actual state only, but can be performed in either Actual or Authorized state.

ClosedRetrieving Data from Multiple Federated Data Sources

During TQL query calculation, you can retrieve data for the same CIT from several federated data sources. The data is retrieved from the local CMDB, as well as from other federated data sources, according to how you have configured integration points. As data arrives at the CMDB, it is identified and reconciled, with the end result determined according to the configured reconciliation priority given to the various integrations.

Each CI that is retrieved from an external data repository includes an attribute (Created By) to show from which federated data source the CI has been retrieved.

For limitations, see Limitations – Integration Studio.

ClosedRetrieving Attributes from an External Data Repository

  • You can retrieve the attributes of a CI from an external data repository, when the core CI data is stored in the CMDB.

  • The core data repository must be the CMDB.

  • The CIT must be located in a data repository for its attributes to be defined.

  • The same attributes can be retrieved from multiple data repositories.

  • For details on retrieval options, see the CI Type Retrieval Mode field on the Federation Tab.

  • When you configure an integration point to include federated CIs, you must select full federation of a CI or the federation of an attribute alone. You cannot set up two integrations for the same CIT where one is mapped to an external CIT and the other is mapped to that same CIT with an external attribute.

  • A CIT can support external attributes if the adapter (which is federating the CIT data) supports mapping information (reconciliation) for this CIT.

ClosedReconciling Information

Federated queries should use the mapping file to reconcile the CI from the CMDB with the attributes from the external data repository.

For details on the Mapping Engine, see Federation Framework for Federated TQL Queries.

For details on selecting attributes to be included in the federation, see Federation Tab.

For details on how reconciliation is performed, see Data Reconciliation.

Use Cases

  • You need to discover the SMS or Altiris desktops in your system. The desktop CIT is a core CIT and is already synchronized with the CMDB. However, you do not want to store all the desktop data in the CMDB as this is inefficient and unnecessary. It is enough to store core attributes such as name and MAC address in the CMDB, and to define the other details of the desktops as external attributes in two data repositories: SMS and Altiris.
  • VMware creates virtual machines that contain a virtual machine monitor (hypervisor) that allocates hardware resources dynamically and transparently. Multiple operating systems can run concurrently on a single physical computer. Since the allocation resources—for example, memory—are dynamic, DFM cannot discover these resources (DFM runs once every 24 hours and the resource data can change hourly). To enable UCMDB to always be updated with real-time data, the solution is to divide the data into two: the core data of the virtual hosts should be discovered and placed in the CMDB; the resource attributes should be retrieved from the external source. In this use case, the data for these attributes is retrieved from two data repositories: CMDB and VMware.
ClosedCalculating Federated TQL Queries

When defining an adapter, you can specify whether calculation of TQL queries must be performed first on the CMDB (default) or whether it can start on the adapter.

As an example of a one-node adapter, if you have a TQL query of Node > CPU (with conditions on the federated CPU):

  • If the calculation is performed first on the data in the CMDB:

    • The TQL query for Node is calculated in the CMDB, which retains all of the Node's data.

    • Then Node > CPU is calculated by the adapter, which uses the reconciliation data from the previous step.

  • If the calculation is performed first by the adapter:

    • The adapter calculates the TQL query for CPU, and returns the connected nodes as the reconciliation data.

    • Then the calculated data is sent to the CMDB, where the TQL query for Node is calculated according to the reconciliation data from the previous step.

The option to set the adapter as the starting point of the TQL query calculation is specified in the Adapter Management module. For details, see Adapter Source Editor Window.

Related Topics Link IconRelated Information