cancel
Showing results for 
Search instead for 
Did you mean: 

Gateway Service for FM with Importing tables

GK817
Active Contributor
0 Kudos

Hello Experts,

I have a function module which imports around 4 parameters & a table with 4 fields. Since its a table, so there can be more than one entry. So, FM has:

Import Parameters - around 4 fields

Table  Parameters - a table with 4 fields. FM can execute more than one entry

Export Parameters - 3 fields - This is the information FM returns after processing records from import & table parameters

I am confused on how to build GW service for this scenario. I have gone through the GW service generation from FM but how are we going to address importing table parameter? I just need some pointers on how i should approach to build service for such a scenario.

Regards

Gaurav K

Accepted Solutions (1)

Accepted Solutions (1)

ChandraMahajan
Active Contributor
0 Kudos

Hi Gaurav,

I will recommend to go with code based approach. determine which fields will be your input and output fields, key fields etc and create entity type considering all those fields. define association and navigation between related entities and code into DPC_EXT class methods for the required operations.

your 4 importing fields can be part of your key. you need to implement get_entityset method to retrieve multiple records to which you need to pass importing fields as $filter.

Please refer and  

Regards,

Chandra

GK817
Active Contributor
0 Kudos

Thanks Chandra.

Now part of the trick is Importing table & 4 importing parameters are not related ( they have no common field). So, i can't create a navigation property between them.

In ODATA service, how do we pass the importing table entries with filter? ODATA service will have 4 parameters with single values & a table with multiple values. and exports are single fields only. They are just the number & some other header information about document created.

ChandraMahajan
Active Contributor
0 Kudos

refer this discussion on how to pass importing table entries

you will get the input values in it_filter_select_options .

you need to then loop this internal table and collect the values and pass it to your FM. see the code provided in one of the reply in same thread.

Regards,

Chandra

GK817
Active Contributor
0 Kudos

Thanks Chandra.

Links that you have provided really look useful to solve my problem. I will go through them. Thanks a lot.

i have provided points for helpful answers.

Regards

Gaurav Karkara

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Gaurav,

It seems you have fallen into the trap of inside-out modelling and associated pitfalls.This kind of FM is not a good fit for OData modelling.

As Chandra has suggested, you should really provide a code-based implementation to wrap the FM, but even more than that you really need to revalidate the design of your model because it is far too constrained by the FM design.

I am curious as to where the data for the tabular input comes from in the first place. It has to have some context for SAP so did it come form SAP in the first place? If that's the case, maybe you should be including the data provider of that list in your query method - code-base queries can use a blend of FM's/class methods that are assembled to fit the service definition, rather than the other way round.

I'm also curious to know why a SAP employee is going down this path?  SAP don't provide many off the shelf services, but they do a lot for Fiori apps. I have yet to see one that is built by FM mapping... that should be reason enough to avoid this kind of design.

Regards


Ron.

GK817
Active Contributor
0 Kudos

Hello Ron,

Definitely it was inside-out modelling pitfall, but now, after going through your blogs & other such information on SCN, I am feeling better.

I myself prefer code based implementation since it provides lots of flexibility. FM constraint definitely limits the scope improvement.

we are developing a internal application where we are trying to replicate a existing old application which accepts data in adobe forms. Purpose of creation is to give application a UI5 look-feel & use the ODATA way of exposing & consuming services. So, this way we are learning & along the way, improving some internal applications as well. Of course, we are doing this by taking some time out of our PRIMARY work.

Reason why i wanted to use this FM was mainly because it was already available as its already being used in existing application. I was trying to figure out the possibility of using this FM without any logic tweaking.

I was exploring this possibility to create a service by keeping most of the code-related things intact from existing application. But you experts have been such a valuable advisors. I will do it the best way now.

Thanks a lot.

Gaurav K

Former Member
0 Kudos

That's good to hear. Finding the best way to wrap existing functions will not only give you more flexibility but it will also enrich your knowledge. I've had to do a similar exercise in the past, where a large set of custom FM's were used for an old web app - the FM's had to be resurfaced as GW services to provide to a new UI, but the FM's could not be changed because the legacy UI had to be kept intact also.