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


A Web Dispatcher

For more information about SAP Web Dispatcher, see the section 
SAP Web Dispatcher: Setup of Communication in the UI Technology Guide on the SAP Help Portal at for the appropriate version of SAP S/4HANA

In the Web Dispatcher configuration, the following path must be configured to be routed to the Backend Server:

  • /sap/bw/ina (in some cases with caching /sap*/bw/ina is required instead)

<TODO screenshot>

B Backend System (the System containing the Query!)

B1 Activate INA services

In transaction SICF activate the following InA services:

  • sap/bw/ina/GetServerInfo
  • sap/bw/ina/GetResponse

<TODO screenshot>

B2 Test InA Services using Internet Control Framework

In transaction SICF select "Test Service" in the context menu of the service: sap/bw/ina/GetServerInfo

You should see a response. The tag ServerInfo must contain the backend system id and client.

<TODO screenshot>

B3 Test InA Services using HTTP/HTTPS settings of system

call transaction SMICM. In Menu select Goto > Services. Using host and port from protocol HTTPS call the InA Service "GetServerInfo" from your browser or call transaction IWFND/GW_CLIENT (preferred since error log can be viewed):


You should see a response. The tag ServerInfo must contain the backend system id and client.

<TODO screenshot>

B4 Test InA Services using WebDispatcher URL

call the InA Service "GetServerInfo" from your browser or call transaction IWFND/GW_CLIENT (preferred since error log can be viewed)

https://<webdispatcher url>/sap/bw/ina/GetServerInfo[?sap-client=<client>&sap-language="<lang>"]

You should see a response. The tag ServerInfo must contain the backend system id and client.

<TODO screenshot>

Note: If previous tests sent a response and this one does not or backend system/client does not match then the WebDispatcher itself is not configured properly and is not routing to the correct backend system.

C Single Sign-On

It is also necessary that SSO is correctly configured between the Frontend/Gateway Server and the Backend Server.

D Tests

D1 No Alias URL parameter

Run you Fiori scenario and either check with Chrome network tools (F12) or with Fiddler that the GetServerInfo URL does not contain a URL parameter specifying a system alias to use e.g. o=<systemAlias>which tells the InA implementation to go to the RFC target defined by the system alias.


Press F12 to view the Chrome Network Tools. Navigate to "Network" and search for the request "GetServerInfo" by applying this to the Filter. Click on the Request. Under "Headers" check the Request URL. Ensure that the URL does not contain a URL parameter similiar to o=<systemAlias>.


<TODO screenshot>

Request contains URL parameter specifying system alias

If your request contains a system alias you must create the system alias on your Backend System with RFC destination "NONE". Follow the instructions for "RFC Destination and Alias" from here Config 1: RFC Destination on Frontend Server routing InA requests to Backend Server#C1RFCDestination+SystemAlias and ensure the RFC destination is set to NONE.

<TODO screenshot>

D2 Backend sessionID cookie

To verify that the request reaches the right server, you have to use a new incognito (Chrome) / InPrivate (IE) Browser window. As your browser only knows the web dispatcher it will show cookies from all targeted systems behind the web dispatcher, i.e. the frontend and the backend system. With an empty cookie store you can make sure that you only see the cookies from 1 request/response.


Press F12 to view the Chrome Network Tools. Fire the GetServerInfo URL against the web dispatch without system alias of course:


In Chrome Network Tools under "Network" search for the request "GetServerInfo" by applying this to the Filter. The request must not contain any cookies (incognito!) but the response should contain a set-cookie with the sessionID cookie that from the backend server. See trouble shooting chapter for details.

<TODO screenshot>

Trouble Shooting

SessionID cookie identifying server/client

Press F12 in Chrome and check the network requests and response for cookies. You must only see the cookie of your frontend system otherwise the web dispatcher forwards the cookies to some other server / client.

Alternatively you can use the Fiddler HTTP sniffer. Be aware that the cookie need not be in the request if this was the first request. Then you will find it in the response under set-cookie.

The cookie identiying the answering server looks like this where XYZ is the system ID of the answering server and 123 is the client.

Could not instantiate data source "DS_1" for Query <Query> / Query <Query> is unknown

Perform all test steps in the configuration docu above.

Additionally check if Query exists on Backend System

Call transaction RSRT on your backend system for Query <Query> and execute. Ensure the Query is displayed by the BW Query Test Tool. 

If the Query exists and error still occurs:

Launch the App in the Browser but open the Debug Tools of the Browser first (e.g. press F12 in Chrome Browser before launching the App URL with ENTER).

Note down the Error reported in the console and also have a look under "Network" at the responses of the requests

  • GetServerInfo
    was it successful or was the service refused?
    is the System and client mentioned in the response the correct Backend System? E.g. launch transaction RSRT in this system with the Query mentioned in the URL (e.g. XQUERY).
  • GetResponse
    was is successful or was the service refused?
    was an error reported? Did it say that system alias is missing? If so then this means the Application requires the configuration of a system alias which has not yet been configured in the system. ==> Run through all tests in this document again and make sure system alias is configured.

400 CX_BICS_INA_RFC_ERROR - System alias <alias> does not exist (e.g. System alias "<systemAlias>" does not exist)

{"Messages":[{"Type":2,"MessageClass":"/IWFND/CM_COS","Number":2,"Text":"System alias '' does not exist","ExceptionClass":"CX_BICS_INA_RFC_ERROR","OlapMessageClass":0},{"Type":2,"MessageClass":"SY","Number":530,"Text":"An exception was raised.","ExceptionClass":"/IWFND/CX_COF","OlapMessageClass":0},{"Type":2,"MessageClass":"/IWFND/CM_COS","Number":2,"Text":"System alias 'S4PRC' does not exist....

If you are using an S/4 area which requires the system alias to route all service requests to the defined backend system then you must not use the WebDispatcher configuration in this document. In this case follow Config 1: RFC Destination on Frontend Server routing InA requests to Backend Server.

An not recommended alternative would be:

  • to create the system alias "<systemAlias>" on your Backend System with RFC destination "NONE" 
    In this case the WebDispatcher configuration can still be used as before. However, application specific information stored using the Fiori Launchpad services will no longer be available to apps. This could cause issues. For this reason we do not recommend using the WebDispatcher in this manner. Applications which rely on the information stored by Fiori will not work!


Applications belonging to a specific S/4 area have specified a system alias for their requests. This means that all browser requests launched within these applications contain the parameter sap-system=<systemAlias>(o=<systemAlias> in service URL's). Normally only the Frontend/Gateway system is to be called with this information. On the Frontend/Gateway system this information then causes the services to be routed to the specified target system.

If you are using the WebDispatcher to dispatch different requests to frontend or backend system, then the requests forwarded to the backend system will also contain the parameter system=<systemAlias>. However, the Backend System has no knowledge of this configuration and will throw an error "System alias <alias> does not exist".

Technical Background:

The S/4 Fiori Launchpad Apps (FLP Target Mapping) embed Design Studio using the UI5 Fiori application "fin_acc_query_analyze". Here they also provide the parameter XSYSTEM specifying the system alias which should be used for all service requests. The parameter XSYSTEM is evaluated and passed over to Design Studio (parameter systemAlias) which then forwards the parameter systemAlias to InA. InA processes the system alias for on-premise systems and ignores the system alias for cloud systems.

Query <Query> is unknown

S. "Could not instantiate data source "DS_1" for Query <Query>" paragraph

InfoObject name is initial.

In this case please follow instructions from BW InA Note 2541557


  • No labels