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.
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".
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.
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>.