on 07-01-2014 6:28 AM
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
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.
Regards,
Chandra
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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.
User | Count |
---|---|
83 | |
10 | |
10 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.