Handling tables parameters in Odata service (SEGW) within a RFC FM

[alexandreourth]

Hello expert,

I have consulted a lot of blogs dealing about RFC fm and Odata services. I found out there is no problem handling import/export paremeters as long as they are simple parameters or flat structures so the mapping from the entitytype properties to the function module parameters is "simple" and everything is automatically perfectly handled by the framework => When we call the URL with parameters, the function module is called and the mapping of data is done automatically with the mapping elements defined in the service.

Now, i try to create an Odata service from the FM BAPI_MATERIAL_AVAILABILITY which returns 2 tables in the tab "Tables" of the FM (WMDVSX and WMDVEX).

When i use the import RFC function from SEGW and i put this FM, the framework creates 3 entitytypes,

• my main one, which will be called in the URL - Stock, containing all import/export simple parameters & flat structures
• 1 for WMDVSX
• 1 for WMDVEX

I don't know how to tell SEGW that the entitytype WMDVSX/WMDVEX is a table and must be linked to Stock, as there are no common keys for a relation and also, i want SEGW to understand that WMDVSX/WMDVEX are the entytypes for the TABLES parameters of the function module.

Thanks a lot for your time and your help.

Regards,

Alexadre

[Tukutupap]

Hello,

It looks like that SAP wants you to retrieve your table results for WMD* through their own entity. You can see if SAP also created an association between your Stock entity and the other two entities. If not, you can create it yourself.

So basically:

Stock - main

WMDVSX - Table 1

WMDVEX - Table 2

In SEGW, if you navigate to your oData service, the first folder is Entity Types, your second folder is Associations. In that folder you need to create 2 new associations between Stock and the 2 table entities. There is where you pick what key fields are used to establish the link as well as the cardinality.

Once you are done you would just call your oData like this: https://yoururl/yourpath/StockSet('yourstockid')/WMDVSXSet

https://yoururl/yourpath/StockSet('yourstockid')/WMDVEXSet

I've never personally done this from creating an oData service from an URL, but I have done it manually for some of my real world scenarios, things like getting the attachments for a certain employee.

Another way to go about it, but you would probably have to create the service manually is you can return all together in your Stock entity, you would just have to convert your table to JSON format and return it as a JSON string, then parse it on the destination.

Good luck!

[alexandreourth]

Thank you Vicente for your time.

At first I wanted to do this with a rest service but the problem that there are no cockpits for monitoring Rest calls like with Odata SEGW and customer want a monitoring option, and also has several Odata services in place (but not one using a RFC with tables sadly).

I'm trying the associations yes and playing with the GET_EXPANDED_ENTITY as i saw in several blogs, but the URL is like

Stock(param1='', param2='', etc)?$expand=WMDVSX/WMDVEX and i don't like it. I would prefer something like :<baseURL>Stock(param1='', param2='') and done. The result would be in a format i want and not the repetition of the properties of the entity...

Guess sometimes Odata is not suitable for everything, or i don't know how to find a workaround for that within the framework

[Tukutupap]

Yeah I understand you. When working with oData you have to pay more attention at how your own business data look like and how you want to represent that, as well as following all these rules and best practices that oData puts on top of the REST call. Its good and bad at the same time 🙂

For a normal REST service you dont have as good monitoring (or as easy), but you can always look at your outbound calls through SICF transaction code. I think there is some type of recording that needs to be activated though.

The best of luck to you!