OData custom parameters - Gateway can have them too!

[Former Member]

Since starting with Gateway I've always wondered why one of the simplest OData conventions is not implemented in Gateway yet.

Simply stated, at the end of a resource path you can add typical query string parameters that you would see in other URI schemes -makes sense.

e.g.  <resource_path>/<resource_endpoint>?sap-language=EN

If you call a service with this kind of URI scheme, it won't object. Nor will it pass those parameters to your backend provider.

From previous REST developments in SAP, I knew that the query string was probably being accepted and even present, so why was it lost?

After a debugging session that would have benefited from 3D googles, I found the answer.

a) Gateway uses the query string for other "stuff".

b) If that other stuff, such as $expand is present, then it gets processed.

c) If what is in the query string is not within an elite group of parameters, it is unceremoniously discarded.

I thought this was rather harsh - they are only trying to be helpful. Time to be helpful in return.

I want my parameters. I planned them, raised them and sent them off on a journey and I want to see them arrive safely at Uncle Backend's home. Uncle Backend will put them to good use and probably keep me in his will.

Now I know the following is probably going to dislodge a very firm stick from a very tight posterior socket somewhere, but I decided to do something about it.

"Get your custom parameters here!"

The first step was to enhance the ODATA processor, namely class /IWFND/CL_SODATA_PROCESSOR, Method INIT_REQUEST. If you have separate GW and BEP, this class will be in the GW instance.

This was done with the following implicit enhancement on the post-exit.

The basic story here is that the exported table 'et_parameter' is responsible for persisting the parameter name-value pairs through the request cycle.

It is at this point that all will be lost if we cannot grab them - this piece of code does that. Anything that was in the query string is saved.

How do you access them in the backend? Well, they aren't exposed in the CRUD method signatures, but they are present in the provider runtime object - you just need to know where to find them.

Or write a method in the data provider to read them - like this:

It is then just a case of calling this method with a parameter name to see if it is present and get its value.

Rather than write this method into every DPC class, I'd suggest putting into an interim custom class inserted into the class inheritance if possible. That way it will appear in all your DPC's. It's easy to do in SP03 but a bit harder in SP04 using SEGW-generated code, I suspect.

I have used this enhancement with no ill effects on a live project and both SP03 and SP04 versions, but anyone wishing to use this solution does so at their own risk.

Regards

RS