Direct Live Connections in the Internet Scenario

In my last blog Introducing Direct Live HANA Connections in SAP Analytics Cloud, I talked about the new “Direct” connectivity option for live HANA connections based on the HTML5 CORS specification. The Direct live connectivity has now become the recommended connectivity option for all live connectivity data sources, including HANA, BW, S4 and universe. With this new connectivity option, a reverse proxy is not needed anymore as long as the end user’s web browser has direct access to the backend system. But what if some end users are on the Internet and don’t have access to the backend system directly? Well, like any web application server, you can “publish” the web server (in this case, the HANA/BW/S4/BIP system) to the Internet.

This can be done by various infrastructure options, such as port mapping, etc, but the most commonly used approach is to add a reverse proxy in your DMZ for the backend HANA/BW/S4/BIP system. But wait a minute, reverse proxy again?? Didn’t we introduce the Direct connectivity option to avoid reverse proxies in the first place? Well, the reverse proxy here serves a totally different purpose from the traditional reverse proxy-based live connectivity, which was to bypass the web browser’s Same Origin Policy. In this case, the sole purpose of the reverse proxy here is to publish the backend system to the Internet. Technically, this means:

• No complicated reverse proxy rules needed for URL rewriting, for both non-SSO and SSO scenarios.
• Only the backend system is reverse proxy’ed, not the SAP Analytics Cloud (SAC) system.

As a result, we can use SAP Web Dispatcher for this purpose, and Apache is not mandatory anymore. This offers great relief to many customers as they are able to get SAP product support on SAP Web Dispatcher, while Apache, as a third-party open-source product, offers community support only. We therefore recommend using SAP Web Dispatcher for this purpose.

Below is a snippet of a sample Web Dispatcher profile for this scenario:

# Backend System
#This is the rule for the HANA system
wdisp/system_1 = SID=HN2, EXTSRV=https://righana2.yourcompany.corp:4300, SRCURL=/, SRCSRV=*:4310

# SAP Web Dispatcher Ports
icm/server_port_0 = PROT=HTTP,PORT=8010
icm/server_port_1 = PROT=HTTPS,PORT=4310

Some prerequisites and best practice tips:

• Note that in the earlier version of the blog post, I provided an option for the SAP Web Dispatcher to issue the CORS headers. The updated recommendation is to make sure that the backend system issues the CORS headers, and Web Dispatcher just passes them through.
• As the Web Dispatcher’s root URL is used to map to the HANA system, this Web Dispatcher is used for the HANA/BW/S4/BIP system exclusively. If you would like to use the Web Dispatcher for other systems as well, make sure a dedicated virtual host/port is allocated for the backend system.
• If there are multiple instances of server nodes for the backend system, it is recommended to turn on load balancing on the Web Dispatcher to leverage the entire server cluster and distribute the workload for optimal performance. Important: make sure session stickiness is configured on the Web Dispatcher so that live connection requests within a session are always routed to the same server instance.

For the SAML 2 SSO scenario, make sure your backend SAML 2 SP metadata is revised so that the Assertion Consumer URL points to the new reverse proxy’ed URL.

One more word on the SSO scenario. For the Internet scenario, the SAML 2 Identity Provider (IdP) must be accessible on the Internet too. This can be a cloud-based SAML 2 IdP on the Internet, or an on-premises SAML 2 IdP which has been made available to the Internet – how this is done is beyond the scope of this blog, but most likely you will publish it via a reverse proxy too.

Cheers:)