Deep structures in GW Service Builder

[Sm1tje]

Hi All,

I'm trying to import a (custom) RFC in the Service Builder. But the service Builder seems to be having some problems with deep structures. In the RFC we have one export parameter (Table type).

This export parameter however has quite some columns and some of them are table types themselves or structures for that matter. In turn some of the structures also have structures or table types in them. Is it even possible to import these kind of deep structures into the service builder.

While importing the structure the service builder does recognize all the fields and (sub)structures. But after pressing the <finish> button, the generated entity types do not reflect the actual deep structures.

Again, is it possible to import it like this? Is this the way to go? Or is there a better/other way?

I do know about associations, but there is no real association based on key fields between the entity sets. For example, the order number in the export number (Set of orders), is not part of the key in the OrderItemsData(Set).

Hope to hear from you soon.

Kind regards,

Micky

[Sm1tje · Accepted solution]

Hi Ashwin,

first of all thanks for the quick reply. Let me elaborate on my initial post.

The export parameter looks like this.

ORDER_NUMBER

DISCOUNT

CUSTOMER_DATA (structure, see below)

STATUS

PAYMENT_MODE

ORDER_ITEMS (table, see below)

Structure CUSTOMER_DATA

CUSTOMER_ID

FIRST_NAME

LAST_NAME

MIDDLE_NAME

SALUTATION

TITLE

DATE_OF_BIRTH

Table ORDER_ITEMS (NO Order number for linkage with ORDER_NUMBER!)

POSITION

PRODUCT_ID

DESCRIPTION

QUANTITY

PRICE (table, see below)

Table PRICE

REGULAR_PRICE

OTHER_PRICE

This is a simplified version of our RFC export parameter, but you should get the picture I guess.

Regards,

Micky

[ChandraMahajan · Accepted solution]

Hi,

I guess you can use association/navigation to read deep structures. you can look my blog for more details.

Regards,

Chandra

[AshwinDutt · Accepted solution]

Hello Micky

Thanks for sharing the info.

Since GW will not allow mutiple tables to map as GW response,we need to model our service using association and navigations between entities.

This way we can see all those return structures and multiple tables in our GW response.

Most of the time as u said there would be no real meaning in creating association and navigations,but still I do not see any ways other than this to model our services so that we can fit in our RFC which has got deep structures as part o output.

Implement expand entity/entityset to implement ur scenario. In forum there are use cases illustrated and implementation details are also shown.

U can have a look at those and can decide what is the best way to model ur use case.

Regards

Ashwin

[AshwinDutt · Accepted solution]

Hello Micky

Please follow what Chandra suggested and that is what I was talking about.

Regards

Ashwin

[Sm1tje · Accepted solution]

Hi Chandra,

thanks for the reply.

I haven't been able to read the entire document yet, but what you are basically saying is that is tis possible to create association/navigation without having a corresponding key field between two entity sets.But I can overcome this by coding. Correct?

Regards,

Micky

[Sm1tje · Accepted solution]

Hi Ashwin,

I will give it a try.

Micky.

[ChandraMahajan · Accepted solution]

Hi Micky,

Yes you can achieve that without having keys. In the blog, I am having association between sales items and its product without any key. You can implement the logic inside get_expanded_entityset and/or get_expanded_entity by redefining it.

Regards,

Chandra

[Former Member · Accepted solution]

Hi Micky,

This is going to be a lot easier to achieve if you drop the RFC mapping and code the implementation yourself.

In , I have explained my reasons for the above in more detail. You are obviously an experienced Sapper, so I would hope that you'll take some advice from another old hand.

I will soon be adding a follow up to this article which may be even more useful.

I'd like to know why you have the RFC:

• It''s been developed for this GW use case.
• It's a legacy FM from a previous application use.

Regards

Ron.

[Sm1tje · Accepted solution]

Hi Ron,

of course I'll take some advice from another old (rather call it 'experienced' Sapper) hand like yourself.

Meanwhile I have read all three blogs (Outside-in modelling, Improved Inside-Out Modelling and Outside-in modelling - a practical guide (RFC Rehab 1)) and waiting for the ext one (RFC Rehab 2 maybe?

It's more than obvious that you are not very fond of using an existing RFC for modelling the service. And based on my current knowledge I agree. It is indeed a 'nightmare' to use a complex RFC (deeply structured and currently none of the entities is related via keys) and import it using the Service builder.

Ron Sargeant wrote:

I'd like to know why you have the RFC:

It''s been developed for this GW use case.
It's a legacy FM from a previous application use.


Regards

Ron.

Why:

Because (without the knowledge I have now, thanks to you amongst others) it seemed a good idea at the time to use an existing (legacy) RFC and reuse it to create the OData model. And, in some of the standard examples for using the gateway and exposing it to the outside world, existing BAPI's were used (Salesorder header and salesorder items).

But now, after experimenting, trying (and failing) I see that another approach is much more suitable.

The one thing that still bothers me is the licensing model which charges per x service calls (If I understand correctly). This encourages me minimize the number of calls to the backend as much as possible. This leads me to a service in which in a single call multiple entities are returned. Fits onto the OData model/protocol (using $expand).

At first I wanted to used the GET_EXPANDED_ENTITY(SET) approach, but after readin your blog (Improved Inside-out modelling), I'm still considering the pros and cons of both methods.

Thanks again.

Regards,

Micky.

[Former Member · Accepted solution]

Hi Micky,

If it is a legacy RFC, is it still in concurrent use? I had a scenario a couple of years ago where a customer was relaunching their web site for customer e-service.

The legacy web site was to run concurrently. That web site used RFC calls from javascript to CRM backend, with a large number of custom RFC's.

In the new site, the same backend logic was required, but surfaced through GW &OData. So, we simply wrapped the existing FM's into the DPC and built the data model by DDIC import or from scratch. I think we would still be building it if we used RFC import wizard.

Even with this amount of freedom, some of the RFC's were difficult to map into OData because they weren't resource-centric.

I understand your point about metering, but that does only apply to non-licenced users. If this is a public consumption service then there will be a metering cost, but otherwise it's not a concern for intranet usage.

If this is a public consumption model , you are going to have to balance cost of operation against performance of operation. No-one is going to want to use this service if it is slow because of data bandwidth issues. Lazy-loading will cost more but provides a better UX.

There is no guarantee that the licence won't change to data usage in future, which would make low hit models pointless and more costly. GW licencing has been through a few changes since it was introduced, nothing is final!

I think your best compromise is to wrap the RFC in an intelligent DPC design. You won't have the "blinkered" model that the RFC wizard will give you and manage performance by various means.

Regards

Ron.

[Sm1tje · Accepted solution]

Hi Ron,

almost scary how much our scenario resembles yours. Indeed, the RFC is still in (concurrent) use via the website (JCo) and we're usgin the same backend!

So what I did (still doing btw) was use your blog about 'improved Inside-Out modelling' as a starting point (I took this from an 'old hand'). As said, I'm still in the middle of this (have to implement some of the coding for xxxxx._GET_ENTITY and I'm currently doing the mapping for the import parameters).

I know that the metering only applies to non-licensed users, but indeed it is going to be a public consumption service. And of course you are absolutely right about the balance between cost of operation against performance. But I expect that this is not going to a major problem since the performance for the website seems to be 'okay'.

Regards,

Micky.

[AshwinDutt]

Hello

Yes GW interprets all those as complex types when we import in service builder.

Your GW modelling depends on ur use case.

It would be good if u can share what s that use case and the structure of ur backend RFC so that we can share our ideas what shyd be the best way of modelling ur use case in GW.

Regards

Ashwin