IDM Queries#

A query goes through different paths based on where the query is issued and the target the query. A query can be issued by a condition within a Rule, by an action within a rule or even by certain noun tokens inside an action's parameters.

Regardless of whether a query is issued from within XSLT code or from within DirXML-Script code the queries behave exactly the same.

A <query> always has a <status> coming back as a result. If any values are returned, those come inside an <instance> event.

Queries to EDirectory#

For this examples, a modify event came from eDirectory and is being processed normally by the policies and rules in the driver's Subscriber channel. When a rule (in our example, placed in the Event Transformation Policy set) issues a <query>, the original <modify> event will stop processing until the <query> results are returned.

The result of a query will always return a <status> message. Remember that a "Success" in this status message just means that the query was issued without errors to the destination, it does not imply that any results were returned. If the query has one or more results, those will come inside an <instance> element. If a query has zero results, there won't be an <instance> document in the <output> document returned.

All queries print in the IDM trace (level 2 or above) the text "Query from policy".

Queries to Connected Application#

For this example, a modify event came from eDirectory and is being processed by the policies and rules in the driver's Subscriber channel.

When a rule (in our example, one from the Event Transformation Policy set) issues a <query>, the original <modify> event will stop processing until the <query> results are returned.

In this case, however the <query> itself will pass through the following Translation Processor components:

After passing these 3 pieces of the engine, the <query> will be handed over to the driver shim and finally to the connected application.

The Connected Application will then return the results of the <query> to the driver shim. The driver shim then will build the XDS document with a <status> element and zero or more <instance> elements, based off of what was returned. This XDS document will then pass through the following Translation Processor components:

before being returned to the rule that issued the original query.

Note: Queries to a Connected Application that do not originate from within the Translation Processor is the only condition where both the <query> and its elements pass through any driver logic. This condition happens because IDM assumes that anything issued from within a driver channel is in eDirectory format. For the application to understand what is being requested the event will need to be converted to the application format. Conversely, any results from the application will need to be converted back to an eDirectory format before it can be processed.

Queries From within the Translation Processor#

Lastly, lets review a <query> coming from inside the Translation Processor which means the: and going directly to the application.

In our, again a modify event came from eDirectory and is being processed by the policies and rules in the driver's Subscriber channel. When a rule (in our example, one from the Output Transformation Policy Set) issues a <query>, the original <modify> event will stop processing until the <query> results are returned.

In this case the <query> is handed directly to the driver shim, and its results come straight from the driver shim to the rule that issued the <query>.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-4) was last changed on 17-Sep-2011 08:29 by jim