Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert
This blog post will cover the usage of the direct live data connection in SAP Analytics Cloud to SAP BW/4HANA. It is a follow-up and enhancement of my previous blog post. To help you with your implementation you will learn about:

  • Architecture of live data without a reverse proxy but using CORS

  • SSO with SAML using the direct connectivity with Azure AD and SAP Cloud Platform Identity Authentication Service (IAS)

Architecture without a reverse proxy

As stated in my previous blog post we need a way to overcome the Same-Origin-Policy (SOP) which disallows a browser to make XMLHttpRequests to another domain (BW/4HANA). The workaround in my other blog post was to use a reverse proxy. This is working fine and was until recently the recommended setup. But with Wave 20 we got the support for Direct Live Data Connections to BW/4HANA. As the name suggests no middleman (reverse proxy) is required anymore. SAC can now talk directly to BW/4HANA.

But wait.. Didn’t we say it is not possible because of the SOP? Yes, but there is this great feature called Cross-Origin-Resource-Sharing (CORS):

“CORS (Cross-Origin Resource Sharing) is a system, consisting of transmitting HTTP headers, that determines whether to block or fulfill requests for restricted resources on a web page from another domain outside the domain from which the resource originated.

The same-origin security policy forbids "cross-domain" requests by default. CORS gives web servers cross-domain access controls, which enable secure cross-domain data transfers.“

(Source: Mozilla)

Now that sounds exactly like what we need! So CORS is adding some HTTP headers from the server’s (BW/4HANA) response that tell the browser “Hey, it is safe and okay to access my domain as long as you are from <domain-of-SAC>”. Among others the Access-Control-Allow-Origin header is sent. It must contain the SAC domain so the browser knows it is safe to access this server from the SAC domain. You could call this kind of a trust setup. Keep in mind that as with the reverse proxy setup the data flow is only happening between the browser and your BW/4HANA system. If both are in the corporate network your data never leaves your network.

Entering the credentials all the time is also not very convenient. Therefore we have to enable SSO as well. For that we will use SAML and two Identity Providers. Why would we use two IdP? Well, if possible you should always go with one IdP only. But some landscapes may require you to use one master IdP and another which acts as a proxy. SAP IAS allows you to be setup as a proxy. It will basically pass through all authentication requests to your corporate IdP (e.g. Azure AD). This setup is totally possible with SAC and BW/4HANA. In this blog post we assume that you want to setup trust between BW/4HANA and Azure Ad. SAC will have a trust relationship with IAS where IAS is acting as a proxy for Azure AD.

In the next chapters we are going to check out what is required to set this all up.

BW/4HANA setup

First of all you have to ensure that the information access (InA) service is activated and you are running SP4 at least. Then follow the excellent description of Firas: You must perform the steps mentioned under the section “Netweaver 7.4+”.

I will quote the relevant steps for easier reference here:

“On your BW system, create a file somewhere (ex: /usr/sap/<SID>/SYS/profile/cors_rewrite), then add it to icm/HTTP/mod_0 as the following:
icm/HTTP/mod_0 = PREFIX=/,FILE={path_to_cors_rewrite_file}

The file should hold the following content:
if %{HEADER:isSACOriginAllowed} = true
setHeader isSACOriginAllowed false

if %{HEADER:ORIGIN} regimatch ^(http(s)?:\/\/)?{SAC_HOSTNAME} [AND]
if %{PATH} regimatch (\/sap(\(.*\))*\/bw\/ina\/*) [AND]
setHeader isSACOriginAllowed true

if %{HEADER:isSACOriginAllowed} = true
setResponseHeader Access-Control-Allow-Origin %{HEADER:ORIGIN}
setResponseHeader Access-Control-Allow-Methods GET,POST
setResponseHeader Access-Control-Allow-Headers x-csrf-token,x-sap-cid,authorization,mysapsso2,x-request-with,sap-rewriteurl,sap-url-session-id,content-type,accept-language
setResponseHeader Access-Control-Max-Age 600
setResponseHeader Access-Control-Expose-Headers x-csrf-token,sap-rewriteurl,sap-url-session-id,sap-perf-fesrec,sap-system
setResponseHeader Access-Control-Allow-Credentials true

if %{HEADER:isSACOriginAllowed} = true [AND]
regRewriteUrl ^/(.*) /sap/public/ping
removeResponseHeader Set-Cookie
removeResponseHeader Expires

kindly replace {SAC_HOSTNAME} with your SAC host name(s) (including port if none standard), you may also adapt the pattern to meet your requirement (http or https or both ..).

Make sure you have enabled the /sap/public/ping service as this is used to handle the OPTIONS HTTP request.

Finally you have to restart your ABAP system.”

Now BW/4HANA will send CORS headers when the request is coming from the SAC domain. If you are using a Web Dispatcher in front of BW/4HANA then please perform the aforementioned step on the Web Dispatcher instead of on the BW/4HANA server. Always the last node (which is "nearest" to SAC) must be configured to send the CORS headers.

This is technically everything we need to use the direct live data connection. But as we also want to use SAML SSO some more steps need to be performed.

First ensure that the InA package (/sap/bw/ina/service/v2) or a higher-level package is configured for SAML authentication with your chosen IdP.

To enable SAML SSO from SAC to BW/4HANA we must provide some dummy HTML file which is used to authenticate the user and follow the SAML HTTP redirects. The setup is straight forward and documented in detail in the SAC manual:

  • Enter transaction code in BW/4HANA: SICF.

  • Enter Service Path/sap/bw/ina, and then press Enter.

  • Under default_host > sap > bw, right click ina, then choose New Sub-Element.

  • In Service Name, enter auth.

  • Add a description.

  • Open the Handler List tab, and enter ZCL_DUMMYAUTH_SERVICE

  • Save and return to the main menu.

  • Enter transaction code: SE24.

  • Enter Object TypeZCL_DUMMYAUTH_SERVICE, select Create, and then select Save.

  • Go to the Interfaces tab, and add IF_HTTP_EXTENSION, plus a description.

  • Go to the Methods tab, and add the following information:


    • LevelInstance Method

    • VisibilityPublic

    • Description: Add a description

  • Double click on IF_HTTP_EXTENSION~HANDLE_REQUEST and add the following code:

html_content TYPE string.

html_content = '<html><script type="text/javascript">open(location, '_self').close();</script></html>'.
server->response->set_cdata( data = html_content ).

  • Select Save.

  • (Optional) Check if the auth package is installed.
    Open the following URL in your browser: https://<Your_ABAP_System>/sap/bw/ina/GetServerInfo?sap-client=<Your_Client_ID>. Make sure you are redirected to your IdP login page, and that you do not get 404 page after login. Replace <Your_ABAP_System> with your ABAP system host, and <Your_Client_ID> with your SAP BW client ID.

As you can see the HTML file does nothing except closing the window. This is required as SAC will trigger this URL (/sap/bw/ina/auth). As this URL is SAML protected the browser will be redirected to the IdP. The IdP will then recognize that you are already authenticated (when logging in to SAC) and have a session. So your browser follows the redirects by the IdP and finally the HTML content is delivered which closes the pop up.

Browser setup

Your browser (Chrome) must allow 3rd party cookies and pop ups from the SAC domain. This can be easily configured in the Chrome settings menu:


SAC setup

Ensure that you have setup trust between your IdP (in this case IAS) and SAC. This can be configured in the SAC admin panel: Enabling SAML Single Sign-On (SSO).

In case your IdP delivers the User ID in mixed case (e.g. KesslerSimon) then you cannot use the user id as the user attribute. In SAC all user ids are uppercase and the comparison is case sensitive. If this is the case for you then choose Custom SAML User Mapping which allows you to enter case sensitive attributes (here: the user id). In SAML you have a NameID attribute which identifies a user in the system. This attribute is compared against SAC and if it matches the user is allowed to access. That’s why we use custom SAML user mapping which enables SAC to compare this NameID attribute (coming from your IdP) against a custom attribute in your SAC user list. When using this configuration the user id in SAC (first column in the Users menu) is not relevant anymore for the IdP and can contain any string.

Now we can proceed to setup the connection to BW/4HANA:

  1. Create connection “Live”

  2. Specify the BW/4HANA domain

  3. Specify the client

  4. Select SAML

  5. Press OK


Now a pop up window should appear and immediately close. That’s it! Now you can create models from your direct live data connection to BW/4HANA.


Currently the live data connection from SAC to SAP BW is supported for the following BW versions:


  • SAP BW 7.4 SP17+

  • SAP BW 7.5 SP7+

  • SAP BW on any DB / on HANA

The information access (InA) service and SAML must be activated on the BW/4HANA system.


When you experience any issues please first try to clear your browser cache or perform the steps in a Chrome incognito window to rule out any old sessions getting in your way.


You have learned an alternative and recommended setup to use the live connection to BW/4HANA without a reverse proxy by using CORS. Additionally we have set up SAML SSO for convenient query consumption.