cancel
Showing results for 
Search instead for 
Did you mean: 

Exporting deep structure in a single call

Sm1tje
Active Contributor
0 Kudos

Hi all,

I'm looking for some clarification on 'exporting' a deep structure via OData / Gateway. Based on some importing parameters, I have to return a structure which has several properties (columns).

Some of these columns are structures or even table types which in turn can have structures and/or table types themselves. Is it possible to fill the export structure as a whole within a single request?

I know it is possible to use expand to return (for example) for a single business partners all of his orders and order items. But these are based on the following model (hierarchy):

partner data

     sales orders

          sales order items

A single request in such a case would look something like this ....../PartnerCollection(PartnerID='000123')?$expand=SalesOrders,SalesOrders/OrderItems

But what about a structure like this:

partner data

     sales orders[]

          sales order items[]

     Addresses[] "Where a partner can have several different addresses for example

Sales Orders and Addresses are on the same level in the hierarcy, but I would like to return all the data in a single call.

If the latter is possible, how would such a request look like?

Kind regards,

Micky.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Micky,

Do you actually have to have this data monolith or can you use lazy-loading to call parts as required. Just because you have this family of data doesn't mean they are "joined at the hip".

There are quite a lot of regular posts on this topic so you might want to look at those.

My initial response is that your particular case is best solved by using "$batch" (also covered in some of those threads).

Regards

Ron.

Sm1tje
Active Contributor
0 Kudos

Hi Ron,

thanks for the reply.

In fact I do, since it 'must' be based on an existing RFC. We do not want to create a whole new (quite complex) RFC. I know it would be best pratice to do this in several separate calls, but we prefer to do this in one single request to the backend.

Conclusion: it should be possible to achieve this in a single call.

I already went through some of the blogs but I couldn't find a blog that reflects my particular requirements. That's the reason why choose to open a new topic / discussion. But if you could recommend a blog or two, that would be nice.

Thanks again.

Regards,

Micky.

kammaje_cis
Active Contributor
0 Kudos

Micky,

This should be the URL .

....../PartnerCollection(PartnerID='000123')?$expand=SalesOrders,Addresses, SalesOrders/OrderItems

'Addresses' in the above URL is the navigation property from Partner entity to Address entity pointing to an association where 'Address' side has * as the cardinality. (Similar Association and Navigation for SalesOrders )


But, that is not the best practice as Ron wrote. Since you already know the 'best practice' I will not repeat it here.



Former Member
0 Kudos

Hmm, sounds like a Web UI or CRM-style RFC that is meant to provide monolithic data to a stateful session. It's an inside-out model and Gateway doesn't do these well. 

You don't have to use RFC for this, in fact, you are probably making it more complex than it needs to be.

The overarching problem is that the internal storage of most SAP applications doesn't fit into the well-defined resource usage pattern that OData represents. Travel and expenses is a classic example of a data model that presents huge difficulties in extracting low-level entity properties with good performance and lightweight logic.

I wrote a deep-dive blog on this kind of modelling and how it can be improved if people insist on doing it.

Regards

Ron.

Sm1tje
Active Contributor
0 Kudos

Hi Ron,

thanks again. I'll look into this.

BTW: Indeed. your assumption is correct. It is in fact an CRM-style RFC. And even though I'm just a 'newbie' to OData and Gateway 'development', I do agree (based on numerous blogs I read and the SAP Press book), that this is definitely not best practice at all.

This function module (developed way in the past) is not a 'perfect' fit (far from it) onto the OData Data modelling.

Regards,

Micky.

Answers (0)