Question regarding possible limitations to RFC parameters (deep structures)

[MFry]

Hi all,

We currently have a mobile application built to run on iPad and iPhone that uses RESTful calls to read and post data from/to a backend SNC system. The calls are currently using an SICF service as the interface and JSON data formatting (within the handler method).

We are running into issues where we try now to use Gateway as the middleware and trying to replace the handler methods with RFC's. In particular, one of the calls reads backend configuration to return data structures used by the front end device to render the tabular information being displayed. Since it is configuration, the line type of the returned data is not static, so we convert the data into a JSON string and pass back via a parameter of type STRING.

In a second case, there are multiple internal tables of data being returned where the line types are static but are deep structures (in one case, with up to 4 levels of nested internal tables). Again, in the case of the handler methods, we simply convert to JSON string and pass back but in the case of the RFC, we could simply return as exporting parameters. However, am told by various people that Gateway RFC's can not have multiple internal tables and definitely not deep structures?

Any advice as to whether we should or can use Gateway in this endeavor?

Kind regards,

Mike

[MFry]

Hi Sergio,

I got a quick response back from Jeff Gebo regarding this topic and his response was to develop the services using the OData Channel API. Unfortunately, he is on vacation now through the rest of this year and I am trying to complete this development this week. Is there anyone in the forum who has used OData Channel API and has a simple example of modeling with an RFC with a complex return structure? Also, recommendations on what to do in the case of an internal table whose line type is not determined until runtime (dynamic type) ...

Thanks,

Mike

[SergioFerrari]

Mike, it's not so easy to help you via the forum, you're asking to perform the complete job.

I hope this article will help you [Content Deleted Jan 2014].

Regards

Sergio

Message was edited by: Jason Lax

[MFry]

Hi Sergio,

Am awarding points for the reference document (although I had just found it a few minutes before this reply) but will still keep the question open as am still looking for an answer or recommendation for the dynamic table return parameter. Any ideas on that? For example, what would happen if I were to simply create an exporting parameter of type STRING and generate JSON output for the dynamic table? In a sense, I would simply want the Gateway service to return my converted string without doing any further manipulation. Is this a possible workaround?

Thanks,

Mike

[SergioFerrari]

Limitations are well described here [http://help.sap.com/saphelp_gateway20sp02/helpdata/en/56/d0cc05b564411e841141f68294e29f/frameset.htm|http://help.sap.com/saphelp_gateway20sp02/helpdata/en/56/d0cc05b564411e841141f68294e29f/frameset.htm] and probably can be bypassed wrapping RFCs with complex interface within a custom RFC.

Let us know what you think about

Sergio