Exposing utility FMs with complex interface in SAP Gateway

[ssimsekler]

Hello everyone

This is about exposing utility functions which have somewhat complex interfaces in SAP Gateway.

Think of a utility ABAP function module e.g. for bill simulation. There are a number of importing parameters such as:

• a structure data for a prospect (which we do not need to persist)
• a table data for prospect's historical billing-relevant activities (again not to be persisted)
• Other simple data parameters

Coming to how (or whether) this FM can be exposed directly in the OData layer, I am aware that there are quite a few discussions around this. Bear in mind that the main issue here is providing a complex input to a request; not about reading complex data. From what I have read, the following options have mainly been discussed:

1. I know many will raise an eyebrow to this option but it is possible to pass complex parameters by converting them into a string which can then be deciphered in the DPC before making the call to the FM. I can see how this approach does not comply with the OData principles. Yet, it is practically a working(!?) solution.

2. An OData compliant option is to model a series of interlinked entities for the complex data set that needs to be provided to the FM and use a batch operation like a deep insert (in our example there is nothing to be persisted in the DB though). As the import data for the FM does not correspond to business entities which we would normally like to persist, it just sounds a bit strange just because these would be like "virtual" entities as we do not need their persistence and the metadata here pertains only to the specific use of this FM.

I believe a similar restriction is valid for GenIL where the EXECUTE/EXECUTE2 methods only accept name-value pairs as parameters and passing a table parameter without a workaround is not possible. I believe the practicality level of the solution which is necessitated -although understandable- by the principles is an "unwanted" element on the trade-off seesaw.

All said, for the sake of robustness and compliance with the OData principles, the second option is much more favourable and should be used* although the first option is quite tempting and -in principle- should be avoided.

Finally, I would really like to see if anyone could share a practical example where Option 2 is utilised and let us know their experience on how it looks. Alternative solutions (in or out SAP Gateway [considering why we are leveraging SAP Gateway in the first place] are also welcome.

Kind Regards

*--Serdar

*Check out 's blog on how to "entityise", e.g. TripContext in his example.

Similar discussions:

[Former Member]

Hi Serdar,

Thanks for the mention and the techniques outlined in that article are how I would probably approach this.

Firstly, I would not try to create this service by RFC import mapping (not that you have suggested it). If an RFC function is being exposed, I'd still wrap it in a "code based" implementation. Code based will give you maximum flexibility and quicker build.

Secondly, there is nothing wrong with having a virtual data model. The whole point of OData services is to provide a service that does not expose the underlying business model in a verbatim fashion. Just as views in the MVC paradigm can provide alterations, filters and derived values from the business data (they rarely show 100% data, or technical values), so can the OData model.

What you might consider is something like this:

• Create a model that has a SimulationInput entity. In this, you have all inputs required.
• Provide another entity to provide results.
• POST a SimulationInput body to the backend from your client in a batch call.
• In the same batch request, add a GET or function import call that provides the results.
• In the implementation, because the calls are running within the same LUW, you can store the input in your session memory and retrieve them during the GET or function import (like I described in the above article).

The elegance of this method is that it requires no persistence in the backend to support the service and the entities therein. I've never tried this particular design but in theory there's nothing to stop it working other than some restriction in BATCH mode that I've not thought of.

Regards

Ron.

[ssimsekler]

Hi Ron

Thanks for your input. I believe the recipe you nicely provided will help many developers trying to resolve this problem while complying with OData principles.

I believe the key here is how we need to make a paradigm shift towards a model primarily based on entities and actually is a world of entities and their associations. Unfortunately, the design and implementation time required for doing this properly may make pragmatic 😉 developers to be more tempted towards the non-compliant options. I have witnessed this in GenIL programming examples and unless this is formalised, I am afraid the same may happen here.

Thanks again for providing a more concrete example. As you mentioned, I also wonder if there may be anything that may hinder this in terms of how SAP Gateway handles batch requests or any restrictions on implementing this way of implementation.

In case anyone has implemented something similar and would like to share their experiences/suggestions, I would really like to hear.

Kind Regards

*--Serdar

[AshwinDutt]

Hello Serdar,

What is the operation which you want to do here ? The FM which you are talking about performs GET CREATE or UPDATE ?

Can you share the screen shot of INPUT and OUTPUT of the FM ?

Regards,

Ashwin