Set Up Static Federation TQL Queries

The rules for determining what static TQL queries are needed for a federation TQL query are:

1. Look at all the links in the federated TQL query which has one local end and one federated end. If there is such a link, then a static TQL query must be created exactly like the one from the federated TQL query.

2. Look at all nodes that are federated. A static TQL query with each federated node type must be created.

For example, taking the below TQL query as an example, three static TQL queries will be needed:

1. Node Linked To Incident - because the Node is only local and the incident is federated (this follows rule 1 described above)

2. Business Service Linked To Incident – because the Business Service is only local and the Incident is federated (this follows rule 1 described above)

3. Incident – because the Incident is federated (this follows rule 2 described above)

The framework sends the following queries to the adapter:

• A query with only the incident
• A query with the incident linked to the node with a relation of type connection
• A query with the incident linked to the node with a relation of type membership
• A query with the incident linked to the business service with a relation of type connection
• A query with the incident linked to the business service with a relation of type membership

After the results of the User mapping union FTQL query are processed, other calls are made to retrieve the attributes of the objects. These calls contain a query called objects layout. The federation engine will try to get all the attributes for a CI, but the connector does not need to provide them all; it is enough to return only the ones required by the mapping file.

The reason for sending the same query with different relations is because in the TQL query there is a managed_relationship type link between the node and incident/business service and incident, but the only valid links when trying to link these CI types together are connection and membership.

By using this approach we only need to define one static TQL with a generic managed_relationship type link, instead of defining two almost identical TQLs with different relationship link types, like below.

Also, similar to the relations, the adapter supports subtype CIs. For example, if you have a TQL Incident related to a Node, you can also receive subtypes of the Node (Windows, Unix).

For the TQL query example above, three static TQL queries are required in order to configure the federation:

• Incident TQL query
• Incident To Node TQL query with managed_relationship (if both connection and membership are required)

• Incident To Business Service TQL query with managed_relationship (if both connection and membership are required)