Using retrieveMultiple with Related Entities

Apr 27, 2012 at 1:34 PM
Edited Apr 27, 2012 at 1:35 PM

I had a look at using this library for quering Related Entities (see http://msdn.microsoft.com/en-us/library/gg334767.aspx)

An example:

/AccountSet(guid'[GUID value]')/opportunity_customer_accounts?$select=FullName

Adding id as an optional parameter to retrieveMultiple
and also adding an optional relatedentityName would then make it possible.

Coordinator
Nov 15, 2012 at 1:52 AM

Hey Peter,

just to clarify - are you looking to extend retrieveMultiple to cover case where you need to retrieve child records for a specific entity? Unless I'm missing something, this is fairly trivial by providing a condition on parent id attribute. 

Or, perhaps you're looking at the inclusion of the information from the child records? That's already supported by toolkit with $expand argument as per http://msdn.microsoft.com/en-us/library/gg309461.aspx:

/AccountSet(guid'[GUID value]')?select=Name,opportunity_customer_accounts&$expand=opportunity_customer_accounts

Can you please clarify so that we can create an issue if applicable?

Thanks
George

Dec 4, 2012 at 9:06 AM

Currently in the libary, the retrieve function supports opts.id but retrieveMultiple does not.

retrieveMultiple should allow for an optional opts.id so that the Set(guid'[GUID value]') can be specified if required.

Coordinator
Dec 4, 2012 at 9:38 AM

Sorry, still don't understand what are you trying to do. Filtering primary does not make any sense in retrieveMultiple as you might as well use retrieve instead. If you are filtering child records on parent id then query is more complicated anyway since in addition to id you need to specify the relationship.

In any case, it's supported via options.odataQuery parameter, e.g.

opts.odataQuery = "(guid'...')?select=Name,opportunity_customer_accounts&$expand=opportunity_customer_accounts";

Hold on, are you looking to simply parameterise the above? E.g.

opts = {
parentid: primaryrecordid,
relatedEntityName: 'opportunity_customer_accounts',
columns = ['Name']

That could add value but, frankly, not a high priority. I suggest you create an issue record that can be taken care of at some point. Or, better still, fork the project, add the code and create a pull request. We'll review and integrate.

Dec 4, 2012 at 9:57 AM

If you want to retrieve a list of opportunities where a specific account is the customer, use the opportunity_customer_accounts entity relationship in the context of a specific account:

/AccountSet(guid'[GUID value]')/opportunity_customer_accounts

I suppose the other way would be to use $expend and $filter

 

Another thing I've noticed is that if you are using retrieve, you can specify opts.select & opts.expand but if using retrieveMultiple you can specify opts.odataQuery
Would be good if you could use either method of parameters against both retrieve & retrieveMultiple

I'll have a look at making a fork.

Coordinator
Dec 4, 2012 at 10:41 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Dec 4, 2012 at 10:42 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Dec 6, 2012 at 6:16 AM

I can see this useful, but I suppose this is achievable by constructing odataQuery parameter to be passed to retrieveMultiple method, so I would recommend developing an utility method (outside the libary) to handle this instead of implementing it in the library, which would probably cause confusions for people who are new to the library. 

What do you guys think?

Coordinator
Dec 6, 2012 at 6:43 AM

After thinking about it some more, I’m with Daniel. The idea is good, the code is useful in certain scenarios but different meaning for parameters like entityName, id is *very* confusing. Adding extra parameters like parentEntityName, parentId sounds like overkill, to be honest.

How about a separate function instead, say, retrieveChildren that encapsulates the functionality in a nice and clean single-purpose wrapper?

Daniel, for now I think it’s OK to add method to the library but create a separate namespace, say XrmSvcToolkit.Extensions. If it starts growing beyond a reason, we’ll split it into a separate source. Or we might just start a separate file right now?

Thoughts?

Dec 6, 2012 at 8:30 AM

Could also add support for $filter and $orderby in this new function.

Coordinator
Dec 6, 2012 at 8:36 AM

Peter,

That sounds good. Hopefully it all makes sense, looking forward to the final code.

Cheers

George