Skip to Content

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. 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 HANA XS engine. But what if some end users are on the Internet and don’t have access to the HANA XS engine directly? Well, like any web application server, you can “publish” the web server (in this case, the HANA 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 HANA 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 HANA 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 HANA 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 HANA 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. If for any reason you have to use Apache as the reverse proxy, check out my blog Direct Live HANA Connections in the Internet Scenario – For the Apache Fans.

The use of reverse proxy also brings new configuration flexibility to the landscape. The CORS headers can be issued either by the HANA system, or by the SAP Web Dispatcher. As the SAC product document mentions, the CORS configuration on HANA has to be re-done after each HANA upgrade. If the CORS configuration is done on the SAP Web Dispatcher, you won’t have to re-do it every time your HANA system gets upgraded, as the settings are persisted on the Web Dispatcher.

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

# URL rewrite
icm/HTTP/mod_0 = PREFIX=/,FILE=.\rewrite.txt

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

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

And the corresponding rewrite rules that add the CORS headers for CORS requests from SAC:

#Issues the CORS headers only if the CORS request originates from the SAC host
if %{HEADER:ORIGIN} = https://<SAC_Host>
  begin
	SetResponseHeader Access-Control-Allow-Origin %{HEADER:ORIGIN}
	SetResponseHeader Access-Control-Allow-Credentials true
	SetResponseHeader Access-Control-Allow-Methods "GET, POST, PUT, OPTIONS"
	SetResponseHeader Access-Control-Allow-Headers "X-Csrf-Token, x-csrf-token, x-sap-cid, Content-Type, Authorization"
	SetResponseHeader Access-Control-Expose-Headers x-csrf-token
  end

Some prerequisites and best practice tips:

  • Requires SAP Web Dispatcher 7.49 PL112 or above if the rewrite rules are done on SAP Web Dispatcher
  • As the Web Dispatcher’s root URL is used to map to the HANA system, this Web Dispatcher is used for the HANA 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 HANA system.

For the SAML 2 SSO scenario, make sure your HANA 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:)

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Matthew Shaw

    Thank you Dong. These are great posts.

    Perhaps not entirely obvious and so I’d thought I’d add a bit:

    The Reverse Proxy hostname:port would need to used in the SAC-Connections-HANA Live Connections-(direct connection)-Host and HTTPs Port for the client to connect to HANA via the Reverse Proxy.  Reverse Proxy here, as you say, will be rewriting the headers to give the impression the Reverse Proxy is the HANA system to the client browser.

    I think my understanding is right? Regards, Matthew

    (0) 

Leave a Reply