Skip to Content

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: https://blogs.sap.com/2017/11/08/enable-bw-direct-live-connections-in-sac/. 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]
if %{REQUEST_METHOD} regimatch (GET|POST|OPTIONS)
setHeader isSACOriginAllowed true
 
if %{HEADER:isSACOriginAllowed} = true
begin
  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
  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
end
 
if %{HEADER:isSACOriginAllowed} = true [AND]
if %{REQUEST_METHOD} stricmp OPTIONS
begin
  regRewriteUrl ^/(.*) /sap/public/ping
  removeResponseHeader Set-Cookie
  removeResponseHeader Expires
end

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 ..).

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:
    • MethodIF_HTTP_EXTENSION~HANDLE_REQUEST
    • LevelInstance Method
    • VisibilityPublic
    • Description: Add a description
  • Double click on IF_HTTP_EXTENSION~HANDLE_REQUEST and add the following code:
method IF_HTTP_EXTENSION~HANDLE_REQUEST.
    DATA:
          html_content TYPE string.

    html_content = '<html><script type="text/javascript">window.close();</script></html>'.
    server->response->set_cdata( data = html_content ).
endmethod.
  • 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.

Requirements

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

  • SAP BW/4HANA SP4+
  • 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.

Troubleshooting

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.

Conclusion

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.

References

To report this post you need to login first.

9 Comments

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

    1. Simon Kessler Post author

      As you have already noticed this setup works for any BW system which uses NetWeaver 7.4+ (as this is the requirement to inject the CORS headers in the response).

      (0) 
    1. Simon Kessler Post author

      In this scenario you would need multiple SAC tenants. You might get away with a single SAC tenant if your user base is not too large. For large scale rollouts multiple SAC tenants are recommended. Then you could connect each tenant to each BW system, depending on your requirements.

      It might be best to set up a workshop to clarify such architectural questions as this is highly dependent on your use case.

      (1) 
        1. Simon Kessler Post author

          There are different pricing options available for multi tenant setups. For pricing related questions please get in touch with SAP Sales. They will help you with the pricing models.

          (0) 

Leave a Reply