Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Universal CMDB11.0

Develop > Developer Reference > Creating Discovery and Integration Adapters > Developing Java Adapters > Interactions between the Federation Framework, Server, Adapter, and Mapping Engine

Interactions between the Federation Framework, Server, Adapter, and Mapping Engine

The following diagrams illustrate the interactions between the Federation Framework, UCMDB Server, the adapter, and the Mapping Engine. The federated TQL query in the example diagrams has only one virtual relationship, so that only the UCMDB and one external data repository are involved in the federated TQL query.

In the first diagram the calculation begins in the UCMDB and in the second diagram in the external adapter. Each step in the diagram includes references the appropriate method call of the adapter or mapping engine interface.

Calculation Starts at the Server End

The following sequence diagram illustrates the interaction between the Federation Framework, UCMDB, the adapter, and the Mapping Engine. The federated TQL query in the example diagram has only one virtual relationship, so that only UCMDB and one external data repository are involved in the federated TQL query.

The numbers in this image are explained below:

Number	Explanation
1	The Federation Framework receives a call for a federated TQL calculation.
2	The Federation Framework analyzes the adapter, finds the virtual relationship, and divides the original TQL into two sub-adapters–one for UCMDB and one for the external data repository.
3	The Federation Framework requests the topology of the sub-TQL from UCMDB.
4	After receiving the topology results, the Federation Framework calls the appropriate Mapping Engine for the current virtual relationship and requests reconciliation data. The `reconciliationObject` parameter is empty at this stage, that is, no condition is added to reconciliation data in this call. The returned reconciliation data defines which data is needed to match the reconciliation CIs in UCMDB to the external data repository. The reconciliation data can be one of the following types: IdReconciliationData. CIs are reconciled according to their ID. PropertyReconciliationData. CIs are reconciled according to the properties of one of the CIs. TopologyReconciliationData. CIs are reconciled according to the topology (for example, to reconcile node CIs, the IP address of IP is required too).
5	The Federation Framework requests reconciliation data for the CIs of the virtual relationship ends that were received in step 3 from UCMDB.
6	The Federation Framework calls the Mapping Engine to retrieve the reconciliation data. In this state (by contrast with step 3), the Mapping Engine receives the reconciliation objects from step 5 as parameters. The Mapping Engine translates the received reconciliation object to the condition on the reconciliation data.
7	The Federation Framework requests the topology of the sub-TQL from the external data repository. The external adapter receives the reconciliation data from step 6 as a parameter.
8	The Federation Framework calls the Mapping Engine to connect between the received results. The `firstResult` parameter is the external topology result received from UCMDB in step 5 and the `secondResult` parameter is the external topology result received from the External Adapter in step 7. The Mapping Engine returns a map where External CI ID from the first data repository (UCMDB in this case) is mapped to the External CI IDs from the second (external) data repository.
9	For each mapping, the Federation Framework creates a virtual relationship.
10	After the calculation of the federated TQL query results (only at the topology stage), the Federation Framework retrieves the original TQL layout for the resulting CIs and relationships from the appropriate data repositories.

Calculation Starts at the External Adapter End

The numbers in this image are explained below:

Number	Explanation
1	The Federation Framework receives a call for an federated TQL calculation.
2	The Federation Framework analyzes the adapter, finds the virtual relationship, and divides the original TQL into two sub-adapters – one for UCMDB and one for the external data repository.
3	The Federation Framework requests the topology of the sub-TQL from the External Adapter. The returned `ExternalTopologyResult` is not supposed to contain any reconciliation object, since the reconciliation data is not part of the request.
4	After receiving the topology results, the Federation Framework calls the appropriate Mapping Engine with the current virtual relationship and requests reconciliation data. The `reconciliationObjects` parameter is empty at this state, that is, no condition is added to the reconciliation data in this call. The returned reconciliation data defines what data is needed to match the reconciliation CIs in UCMDB to the external data repository. The reconciliation data can be one of three following types: IdReconciliationData. CIs are reconciled according to their ID. PropertyReconciliationData. CIs are reconciled according to the properties of one of the CIs. TopologyReconciliationData. CIs are reconciled according to the topology (for example, to reconcile node CIs, the IP address of IP is required too).
5	The Federation Framework requests reconciliation objects for the CIs that were received in step 3 from the external data repository. The Federation Framework calls the getTopologyWithReconciliationData() method in the External Adapter, where the requested topology is a one-node topology with CIs received in step 3 as the ID condition and reconciliation data from step 4.
6	The Federation Framework calls the Mapping Engine to retrieve the reconciliation data. In this state (by contrast with step 3), the Mapping Engine receives the reconciliation objects from step 5 as parameters. The Mapping Engine translates the received reconciliation object to the condition on the reconciliation data.
7	The Federation Framework requests the topology of the sub-TQL with reconciliation data from step 6 from UCMDB.
8	The Federation Framework calls the Mapping Engine to connect between the received results. The `firstResult` parameter is the external topology result received from the External Adapter at step 5 and the `secondResult` parameter is the external topology result received from UCMDB at step 7. The Mapping Engine returns a map where the External CI ID from the first data repository (the external data repository in this case) is mapped to the External CI IDs from the second data repository (UCMDB).
9	For each mapping, the Federation Framework creates a virtual relationship.
10	After the calculation of the federated TQL query results (only at the topology stage), the Federation Framework retrieves the original TQL layout for the resulting CIs and relationships from the appropriate data repositories.

Example of Federation Framework Flow for Federated TQL Queries

This example explains how to view all open incidents on specific nodes. The ServiceCenter data repository is the external data repository. The node instances are stored in UCMDB, and the incident instances are stored in ServiceCenter. It is assumed that to connect the incident instances to the appropriate node, the node and ip_address properties of the host and IP are needed. These are reconciliation properties that identify the nodes from ServiceCenter in UCMDB.

Note For attribute federation, the adapter's getTopology method is called. The reconciliation data is adapted in the user TQL (in this case, the CI element).

After analyzing the adapter, the Federation Framework recognizes the virtual relationship between Node and Incident and splits the federated TQL query into two subgraphs:
The Federation Framework runs the UCMDB subgraph to request the topology, and receives the following results:
The Federation Framework requests, from the appropriate Mapping Engine, the reconciliation data for the first data repository (UCMDB) that contains the information to connect between received data from two data repositories. The reconciliation data in this case is:

The Federation Framework creates a one-node topology query with the Node and ID conditions on it from the previous result (node in H1, H2, H3), and runs this query with the required reconciliation data on UCMDB. The result includes Node CIs that are relevant to the ID condition and the appropriate reconciliation object for each CI:

The reconciliation data for ServiceCenter should contain a condition for node and ip that is derived from the reconciliation objects received from UCMDB:

The Federation Framework runs the ServiceCenter subgraph with the reconciliation data to request the topology and appropriate reconciliation objects, and receives the following results:

The result after connection in Mapping Engine and creating virtual relationships is:

The Federation Framework requests the original TQL layout for received instances from UCMDB and ServiceCenter.

Send Help Center feedback