FetchXML Exception Reporting in Microsoft Dynamics CRM 2013

Want to know what accounts in Dynamics CRM have no related opportunities? How about which contacts haven’t had any activities in the last few months? Exception reporting using the FetchXML data processing extension is one feature that in previous versions of CRM, has not been possible.  With the introduction of Microsoft Dynamics CRM 2013, the capabilities of a left outer join is possible, therefore customers can now perform custom exception reporting with the FetchXML DPE out of Microsoft Dynamics CRM.

In CRM 2011 Fetch cannot express queries of the form:

· Find all Accounts that have no Opportunities

· Find all Accounts that have no Contacts

· Display a list of contacts who did NOT have any campaign activity within the last X months

The following syntax in CRM 2011 doesn’t work exactly as expected for Fetch XML.

 1: <fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="true">

 2:   <entity name="account">

 3:     <attribute name="name" />

 4:     <link-entity name="opportunity" from="customerid" to="accountid" alias="ab" link-type="outer">

 5:       <filter type="and">

 6:         <condition attribute="opportunityid" operator="null" />

 7:       </filter>

 8:     </link-entity>

 9:   </entity>

 10:  

This FetchXML converts to the following SQL:

SELECT account.Name
FROM Account as Account
LEFT OUTER JOIN Opportunity
ON (account.Accountid  =  Opportunity.Customerid and (Opportunity.Customerid is null))

Since the filter condition is appended to the ON, this query does not work as expected.

In CRM 2013 this scenarios can be addressed as follows:

An alias must be defined for a link-entity in order for it to be used in the filter. In the filter element, the value of the attribute (customerid) is the field of the form entityname (ab) which must have been already defined as an entity name or alias or a link-entity name or alias.

 1: <fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="true">

 2:   <entity name="account">

 3:     <attribute name="name" />

 4:     <link-entity name="opportunity" from="customerid" to="accountid" alias="ab" link-type="outer">

 5:        <attribute name="customerid" />

 6:     </link-entity>

 7:     <filter type="and">

 8:         <condition entityname = "ab" attribute="customerid" operator="null" />

 9:     </filter>

 10:   </entity>

 11: </fetch>

 12:  

This Fetch XML would result in SQL equivalent to:

SELECT account.Name
FROM Account as account
LEFT OUTER JOIN Opportunity ab
ON (account.accountid  =  ab.customerid)
WHERE ab.customerid is null

Note that the filter has moved from the ON clause to the WHERE clause.

Another example, here including more than one filter, returning all accounts that either don’t have any related activities or they don’t have any open related activities:

 1: <fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="true">

 2:     <entity name="account">

 3:         <attribute name="name" />

 4:         <link-entity name="activitypointer" from="regardingobjectid" to="accountid" alias="ab" link-type="outer">

 5:             <attribute name="regardingobjectid" />

 6:             <attribute name="statecode" />

 7:         </link-entity>

 8:         <filter type="and">

 9:             <filter type="or">

 10:                 <condition entityname="ab" attribute="statecode" operator="ne" value="0" />

 11:                 <filter type="or">

 12:                     <condition entityname="ab" attribute="regardingobjectid" operator="null" />

 13:                 </filter>

 14:             </filter>

 15:         </filter>

 16:     </entity>

 17: </fetch>

Here is a summary of the considerations:

· Filter on the LEFT OUTER JOIN should apply to the WHERE clause when converted to SQL.

· Entity alias can be used in the filter clause.

· In the link-entity node of a Fetch XML query, an alias can be specified. This alias should be supported in the filter node when performing a LEFT OUTER JOIN.

• FetchXML involving a Join are not editable in the Advanced Find editor or customization settings from the application.

• However, this can be executed via SDK or imported as part of a solution.

If you are interested, our PFE team is ready to help you. We have many services we offer such as reporting workshops, developer training, admin workshops, and code reviews.  If you would like to have another Microsoft PFE or I visit your company and assist with the ideas presented on our blog, contact your Microsoft Premier Technical Account Manager (TAM) for booking information.  For more information about becoming a Microsoft Premier Customer email PremSale@microsoft.com.

Thanks!

Sarah Champ

Microsoft Premier Field Engineer