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 favourableand 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 outRon Sargeant 's blog Improved Inside-Out Modelling on how to "entityise", e.g. TripContext in his example.
Similar discussions:
Odata function import - input as complex type
odata function import - structure as import parameter
GW Function Import: pass parameter table (e.g. multiple parameters of same type)