Accessing on-premise from XS on trial

Some time ago, I have bumped into a scenario that required me to access an OData on-premise service (built with NW Gateway). The problem arose when I wanted to use it from within a HANA native application, because according to help.hana.ondemand.com and some other blog posts on scn this was not possible.

I have found a work-around to allow developers to access such services. Please note that it should never be used in a productive scenario (mainly because of performance and security issues). In a productive scenario, you can use the connectivity service directly.

There are two ways to do this:

Either deploy a Java HTTP Proxy servlet and connect XS with that servlet via a HTTP XS destination.

Or create a HTML5 app and use the dispatcher to forward your requests

I will provide an end-to-end guide for both scenarios (although the ideas themselves are very simple).

Exposing the resources with HCC

Before starting to do anything, we must install HCC on-premise (or on a computer which has access to the resources). See the docu for more info 🙂 .

In the HCC, the host on which the OData service is located must be mapped to a virtual host and the OData service path must be exposed or even the root of all OData services. Example:

Once the resources have been exposed to the cloud, a destination must be created in the connectivity service (using the cockpit).

This is an example of such a destination configuration:

[Option 1]Creating the HTTP Proxy Servlet

The idea behind this kind of servlet is simple: map all HTTP requests to the servlet path (and subpaths) to a predefined path in the previously added destination. Request headers, body and URL parameters must all be passed through and the response must be simply mirrored. Here is a very basic implementation of this kind of servlet:

When accessing the application URL of the application, the OData Service description should be shown. For example:

[Option 2]Creating the HTML5 app

This is even more simple than the Java app alternative. It also has the added benefit of not blocking the account’s compute unit (i.e. we can have several HTML5 apps running in the same time, but only 1 Java app).

Once the XS app is up, the default trust store must be assigned (Cockpit -> XS Apps -> Select they application -> Assign Trust Store -> DEFAULT). After this step, running the app should print the service metadata. Something like this:

And that’s it 🙂 This would work for any on-premise HTTP resources exposed through HCC. If RFC’s are needed, they can be called through a Java app and then exposed using HTTP with a similar mechanism as above.