Page tree
Skip to end of metadata
Go to start of metadata

You must configure your on-premise SAP Netweaver BW, BW/4HANA, or either S/4HANA system in order to support live data connections that use the direct connection.

It is required to configure CORS on the backend side, to be able establish the communication between the client and backend. Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell browsers to give a web application running at one origin, access to selected resources from a different origin. A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, or port) from its own.

The following page is intended to show a working network communication between SAC BW Live and the correspondent backend.


By checking the network communication, one can already recognise that the request Methods (OPTIONS and GET) come always in pairs. The OPTIONS method is used to describe the communication options for the target resource (handshake), while the GET method requests a representation of the specified resource.

The pair that marked red is only used for authentication and it does not request to open an ABAP sessions on its own, while the HTTP calls marked yellow are intended to establish the ABAP session(s).

By having a closer look at the red OPTIONS request we can see that the request triggers te SICF service GetServerInfo. The Host is always the backend application server host, while the Origin and Referer are related to the SAC tenant. Since the first GetServerInfo pair is only for authentication, the OPTIONS calls only requests http header authorization and GET method. The authorization header contains the credentials to authenticate with the server.

As a response the server returns all allowed and exposed http headers for later usage as well as the requested method. The returned list needs to contain the requested http header. These are the http headers that are configured in either transaction UCONCOCKPIT, or via ICM rewrite script. The allowed and exposed headers tells the browser where the web application runs, that what actions, resources are allowed to be taken from the from a different origin server.

In case, the http response is not as expected, first of all make sure that the server sets the correct http headers.

OPTIONS /sap/bw/ina/GetServerInfo?sap-client=800 RequestOPTIONS /sap/bw/ina/GetServerInfo?sap-client=800 Response


In the correspondent GET request, client sends the User/Password (in case of Basic authentication) in Base64 encoded format. As response server sets the following cookies and sending it back to the client as a response: sap-ssolist,
sap-usercontext ,MYSAPSSO2, SAP_SESSIONID. 

sap-ssolist: This cookie is issued to prevent further logon attempts with specific authentication methods. If the the correspondent SICF service (GetServerInfo) is not configured to prioritize Basic authentication at the first place, then on the server side there can be failed logon attempts with other authentication methods which are then blacklisted in the current session.

sap-usercontext: Contains the ABAP client number and any user specific information like language.

MYSAPSSO2: After a user authenticates on a ticket issuing system, the system issues the user a logon ticket, which the user can use for access to successive systems. The ticket issuing system encodes the logon ticket and sets it as the value of non-persistent cookie with the name MYSAPSSO2. Without the MYSAPSSO2 cookie, the logon screen to authenticate would come every time when a model, or story is wanted to be created, even if the sessions is not yet expired. How to make sure that MYSAPSSO2 cookie is set correctly.

SAP_SESSIONID: Session cookie. A security session exists between an HTTP client and an HTTP server (ABAP: logical system), is created as the result of a successful logon and is ended when the logoff is performed. On the server, the result and the type of the authentication is stored in the security context. During the communication between the HTTP client and the HTTP server, (only) the security session ID is transferred (using a host-specific, non-persistent cookie), which refers to this security context. As long as a security session exists, you can start Web applications that require an authentication (without logging on again) if the existing security session covers the authentication requirements (that may be application-specific). How to make sure that SAP_SESSIONID is set by the server.

GET /sap/bw/ina/GetServerInfo?sap-client=800 RequestGET /sap/bw/ina/GetServerInfo?sap-client=800 Response

By having a closer look at the yellow OPTIONS request we can see that the request also triggers the SICF service GetServerInfo, but with a suffix sap-sessionviaurl=x. This indicates that it is the preflight request for the session opener http call. It checks the allowance of further http headers like x-csrf-token. When the client creates a session and connects to the server, it is needed to fetch a CRSF token. The client must send a request header called X-CSRF-Token with the value fetch in this call.

As a response the server returns all allowed and exposed http headers for later usage as well as the requested method. The returned list needs to contain the requested http header. These are the http headers that are configured in either transaction UCONCOCKPIT, or via ICM rewrite script. The allowed and exposed headers tells the browser where the web application runs, that what actions, resources are allowed to be taken from the from a different origin server.

In case, the http response is not as expected, first of all make sure that the server sets the correct http headers.

OPTIONS /sap/bw/ina/GetServerInfo?sap-client=800&sap-language=en&sap-sessionviaurl=X RequestOPTIONS /sap/bw/ina/GetServerInfo?sap-client=800&sap-language=en&sap-sessionviaurl=X Response

Here we can see that there are two correspondent GET requests. It is a really important SAC session handling logic. Depending on the configured number of "Number of parallel sessions configured for BW data sources" there will be as many session opener GetServerInfo http calls. So for example if there are 6 parallel sessions configured, then there will be six GetServerInfo session opener http calls.

One of the sessions is being reserved for the DataSource instance that bound to a widget and another other one is reserved for the Story relevant tasks. For example depending on how the Prompt screen is being called (Story level, or Widget level), a different ABAP sessions will be utilized. 

Of course if there is only one DataSource bound to one widget, then not all six sessions will be utilized, but if we have a DataSource bound to six widgets, then the DataSource instances will be distributed between the maximum possible six ABAP sessions. 

With the explanation above, it is then clear that the scenario of ours was recorded with setting two "Number of parallel sessions configured for BW data sources".

With the sap-ssolist, sap-usercontext, MYSAPSSO2 and SAP_SESSIONID cookies in the request it is possible to get the sessions information which is hold by http header sap-url-session-id in base64 encoded format and appended then to the follow up request url when running a story. In order to be able to modify the request urls, sap-rewriteurl is needed to be allowed and exposed. Also the CRSF token is being fetched here, as well as the sap-usercontext cookie is being set and updated with the current user session information.

It is really important to be mentioned that the SameSite=None; Secure attribute is also set here already. If even though the server side solution from the official documentation is configured, the attribute is not set, please check the How to make sure that that SameSite=None; Secure attribute is set by the server.

GET /sap/bw/ina/GetServerInfo?sap-client=800&sap-language=en&sap-sessionviaurl=X RequestGET /sap/bw/ina/GetServerInfo?sap-client=800&sap-language=en&sap-sessionviaurl=X Response

As it has been mentioned the sap-url-session-id in base64 encoded format is appended to the follow up INA requests. INA GetResponse call is intended to request Metadata, Query/variable Value help, Variable Submit and ResultSet. As the communication is Stateful, it is really important that INA http calls that are related to the same Query instance should go to the same sessions, therefore it is also needed to make sure that the SAP_SESSIONID cookie is part of the request Cookies section (can be filtered out, because of SameSite cookie problem), as well as to have the sessions id appended to the request. How to make sure that the Query Instances fall into the same Session

  • No labels