Some days a request comes along for a view that goes beyond what the advanced find can generate. Some examples are Aggregates, Left Outer Joins, or you simply might be joining entities in a way to display data that the Advanced Find doesn’t allow. (Example: Opportunity Line à Opportunity à Account. We cannot display a column from the account entity.) A great example of a Left Outer Join came across my desk recently for a client that wanted a view of “All Opportunities Without an Open Activity”. Left outer joins are required when you are doing a “not in” query.
I took this opportunity to utilize a few items in the XRMToolbox to help me with this task. I was already aware of the “FetchXML Tester” and after years away from it, it still worked like a charm. I started by getting as far as I could with an Advanced Find Query and then downloading the FetchXML.
I loaded the results into the FetchXML Tester and updated it to include the left outer join logic. (NOTE: If you are uncomfortable working with FetchXML by just typing it in, you might want to use the FetchXML Builder that I referenced in Part 2.) To learn more about FetchXML and the left outer join, click here to see a Microsoft example. Microsoft’s example is a little simpler and might be easier to follow.
There isn’t much to explain with this tool other than you can type FetchXML against your CRM Org and click the execute button to see the results in the next “Response” tab. In the example above, I am excluding any task (entity name “activitypointer”) that is not open and displaying the task’s statecode. (A task’s open state code = ‘0’.)
The last highlighted filter references the entity alias of “ab” and looks at the task’s statecode returned. Any Opportunity that has a task of open will return a ‘0’. All other Opportunites return a task statecode of null. I only wanted the opportunities without an open task so I made sure this was null.
I click Execute and the Response tab shows my results. The simplicity of the “FetchXML Tester” is what I like the most. Connect to your org, type in your FetchXML, click Execute, and see your results.
At this point, I had tested my XML and it was returning the data I wanted. I now had to get my new query into the view in CRM. Previously when I had to do this I had to:
- Add the View that I wanted to update to a new unmanaged solution
- Export the solution.
- Unzip the solution and open the customizations.xml file.
- Parse through the solutions XML and find the view with the FetchXML that I want to update.
- Manually modify the view with my new FetchXML.
- Save the customizations.xml file.
- Zip up the solution and re-import.
- Test and hope I did not make a typo.
There had to be a better way. Good news is there was! Next, on to Part 2 where we discuss the XRMToolbox “View Designer” and “FetchXML Builder.”