Show your cards, please!

Let me tell a short story.

Imagine a SAP customer having a webapplication using SAPUI5. The architecture is a typical transactional Fiori-like application.

Meaning: SAPUI5, connecting to SAP Gateway via OData. The services are implemented in the ECC backend via ABAP OO.

In our case leveraging the SAP PM/CS module. This is working perfectly fine. Like this:

HANA

Due to new requirements, HANA as platform came into scope as well. Searches do have to stay fast even if the amount of data will grow on our ECC system. Another reason was to be able to search in ‘legacy’ data. ECC Tables will now be replicated to HANA enterprise. Also the legacy (read-only) data will be loaded into HANA. Search services are implemented here via OData as well, in this case via xsodata. So a 2^nd OData source come into play.

Pictured it in mind? Great! Let’s draw it.

So our new picture would ideally be like this.

SAP Gateway as our central access point for services. Meaning we can still to tracing/ logging as we are used to have with our initial architecture with the SAP Gateway to ECC setup. See response times, trace activity for a limited amount of time. And have a single and central access point for all our services. Ideally as well, since we have to deal in SAPUI5 with the ‘same origin policy‘ issue. Also for other applications later on which have to benefit from these services, can benefit from a single access point.

As Sheldon Cooper, would say:

All set… Or not?

External OData source

When we want to use SAP Gateway as our route to HANA, means we have to call an external OData source (HANA) via SAP Gateway.

Let me explain; Calling external OData services (in our case HANA) via SAP Gateway can be done, it is called OSCI. It is explained here. So we did. We run the wizard, and ….. it failed. “Metadata cannot be loaded”. It turns out a ‘http://’ deep down in the class is missing. No worries, when adding this via the debugger, luckily we could continue. Generation was successful. The metadata could now be loaded. All fine? Actually no, when testing our ‘new’ service via the gateway client, it failed. It had a different interpretation of ‘nullable’. Meaning all records with empty values failed, The default of Nullable is differently interpreted in Gateway. Nothing to worry as well, I guess we can fix that by making our definitions more explicit on the HANA side.

What was unexpected is, a complete new service is generated in Gateway. A completely new set of classes. Doing all the logic as you would have when generating a Gateway service using an ECC backend via an RFC. Meaning it parses the incoming request and check for validity against the metadata. Especially responses are completely parsed. Not only it takes time (we run 60.000 records through it, and it took >1,5 minute before a parse error came up). But parsing and validating the response would anyway be done in the source system, in our case HANA.

Sheldon is over-reacting when hearing this news.

Of course there are reasons for this, and there are great teams working at SAP, who must have a very good reason to implement it like this. In our scenario it is a bit unexpected, and behavior which is actually not required.

Our requirement would be fulfilled with having a proxy behavior. Proxying requests to HANA. With Gateway as proxy, but still enabling logging, tracing and response time measuring. A pure representation of a proxy is shown below.

What does Fiori do?

How does standard Fiori do this, when calling HANA OData services from a Fiori application. Is Gateway being leveraged here as a central point of access? Is it using OSCI?

This picture is directly from SAP documentation. The “Setup of SAP Fiori System Landscape with SAP HANA XS”. It describes the architecture for an analytical application. A SAPUI5 application consuming OData services from HANA.

What do we see? The webdispatcher. The good‘ol webdispatcher. This does mean it will do simple proxying, this also means it will not be consuming time in reading and validating and parsing the response. Great? Yes, sure it is acting a proxy. But remember, we want to have full tracing, and logging options. To be able to see if a request has failed. To turn on a trace for 2 hours and watch what happens (for a particular user). To quickly spot the services which have high response times, and possibly cause time-outs.

Solutions

We could implement our solution with bypassing SAP Gateway for HANA OData services. Since we are serving the SAPUI5 from a Java stack (Gateway is not our frontend server). We implemented a proxy here by using a Java proxyservlet, to route requests to HANA. However we do not have the routing and logging, handy tracing options and response times measuring in (one) place. It can be build and implemented here, sure, but it’s not standard.

It could be, that our future architecture will be a even more Fiori-like landscape. Gateway, ECC, HANA. The Gateway server being the frontend server, this stack running the Launchpad and offering the SAPUI5 applications. Meaning it might grow towards an architecture without the Java stack, this means we cannot do the proxying anymore here.

Roadmap

What is SAP’s roadmap here? In scenario’s with more OData sources being consumed in one or in more applications.

Is the webdispatcher the final solution, as in the Fiori analytical landscape? Monitoring and managing is less advanced here as the customer would prefer.

Is there another way to route and monitor and manage these different API’s via one solution. Will SAP Gateway get proxy functionality?

Or is this why SAP started a partnership with ApiGee?

Although it seems to be more focused on cloud based solutions, will this also be available for on premise usages as API management for all (SAP) OData sources?

Please SAP, show your cards!

Thanks for making it onto the end of this blog. Please share your comments!