Skip to Content


08.08.2016 – Added link how to implement custom routing

12.06.2017 – Added section about host name based routing


Use case 1 – Multi Origin Composition


A service is configured to use Mulit Origin Composition to retrieve data from different backend systems, say Backend_1, Backend_2 and Backend_3.




Therefore corresponding system alias entries have been created in the SAP Gateway Server and have been assigned to the service. This works fine as long as every user that calls this service has also a user in all three backend systems. However f there are users that have do not have users in all connected backend systems the call will fail.




Since as of SP07 of SAP Gateway 2.0 it is possible to make the READ feed requests of a service in “Multi Destination Composition” mode error tolerant (SPRO -> SAP NetWeaver -> Gateway -> OData Channel -> Composition -> Flag OData Services to be error tolerant in case of MDC) customers have tried to use this feature to solve the issue describe above.


The fault tolerant behaviour should however NOT be used in this case since the intention behind the fault tolerance option is to handle temporary error situations, e.g. a temporary connection problem to the backend where a next call that is performed a little bit later would be successful.The initial request however is processed by all backends and does not break at the first failing backend.


The solution that we recommend for the use case mentioned above is to use routing together with multi origin compositino as described in the following:




In a situation as described above one would like to restrict the SAP Gateway server such that it would only call those backend systems where the user that calls the service also has a user. This can be achieved by combining the features of Multiple Origin Composition and Routing.


Let’s assume we have three different user groups A, B and C that have users in the following backend systems


Userid Backend System 1 Backend System 2 Backend System 3
USER_A (user group A) X
USER_B (user group B) X X
USER_C (user group C) X


We now add the roles USERGROUP_A, USERGROUP_B and USERGROUP_C to the system aliases BACKEND_1, BACKEND_2 and BACKEND_3 that are assigned to the OData service. Since users from USERGROUP_A and USERGROUP_B have users inBACKEND_1 we have added the system alias BACKEND_1 twice. One time with having added role USERGROUP_A and one time with having added role USERGROUP_B.


Roles and System Alias Entries assigned to a service.JPG


We can now assign the roles USERGROUP_A, USERGROUP_B and USERGROUP_C to the users USER_A, USER_B and USER_C respectively so that their calls are routed to those system(s) where they have backend users.


Role assignment user_a.JPG


Role assignment user_b.JPG


Role assignment user_c.JPG


When performing a MOC call like the following using the Gateway Client




You would get responses like the following:








               <title type=”text”>CountryCollection(SAP__Origin=’BACKEND_1′,CountryCode=’AD’)</title>










               <title type=”text”>CountryCollection(SAP__Origin=’BACKEND_1′,CountryCode=’AD’)</title>






               <title type=”text”>CountryCollection(SAP__Origin=’BACKEND_2′,CountryCode=’AD’)</title>










               <title type=”text”>CountryCollection(SAP__Origin=’BACKEND_3′,CountryCode=’AD’)</title>





Please note that an additional key field SAP__Origin has been added to the response. Therefore it is possible to distinguish results from the different backend systems that might have the same key values.


Use only routing


If the users have only one user in one of the backend systems you could call the service without the MOC option. In this case the call is simply routed to one backend.


The default flag


When assigning system alias entries to a service there is the option to mark an entry as default which is also described here: Assigning SAP System Alias to OData Service – SAP NetWeaver Gateway – SAP Library.


Why do we have this default flag ?


There are basically 3 types of requests:


  1. Requests that can only be performed in one system

    An example for such a request is the $metadata request or a create request or a function import that only retrieves one entity (multiplicity 1)

  2. Requests that can retrieve data from multiple systems

    Here we are talking about Multi Origin Composition requests that use the option “;mo”. Examples are requests that retrieve a list from an entity set or a function import with multiplicity n.

  3. Requests that will end up in one system

    A simple example is any request that is sent without the MOC option.


The default flag is needed to specify a specific system alias to be used if more than one system alias is found but only one is needed. Let’s have a look at the following two examples where this is the case.



1.) Request of an entity set without using the MOC option


In the example described above this would be the case if USER_B performs the http GET request without using the MOC option.




In this case the data would be retrieved from BACKEND_2 since based on the role assignment two system aliases are found (BACKEND_1 and BACKEND_2) but only the one with BACKEND_2 is marked as default.
If none of the 2 system alias entries BACKEND_1 and BACKEND_2 are marked as ‘Default’ as shown in the following screen shot:




than the following error message would occur:


No System Alias flagged as “Default” for Service ‘ZGWDEMO_0001’ and user ‘USER_B’








2.) Retrieve the $metadata document of a service


The same error would also occur if USER_B would try to retrieve the $metadata document of the service





Use case 2 – Use the host name in addition for routing

In this scenario different system aliases should not only be selected based on the roles that have been assigned to a user but also on the host name that is used by the OData client to call the service.

In this case you have add a host name including the port number in the field Host Name when adding a new system alias to a service using the transaction /n/IWFND/MAINT_SERVICE.

Please note:
Adding solely the host name without the port number will not work.

If a user uses the following URL


the system alias LOCAL will be used whereas when using the following URL


the system alias LOCAL2 will be used.


Custom routing


If role based routing and the use of host names does not suite your needs you can implement custom dynamic system alias calculation as described in my following blog.


How to implement custom dynamic system alias calculation in SAP Gateway

To report this post you need to login first.


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

  1. Former Member


    We have implemented OData Service using Multiple Origin Composition concept. Where, We had two backend Systems ( for ex: SYS1 and SYS2 ) and a gateway server system (For Ex: GWS). So When we make a call to service, the result comes from both the backend systems into a single feed.

    But if one of the backend systems is down, We could not receive the result from the other backend as well. We should receive the result from SYS2 when SYS1 is down. Could you help in this regard.

    Note: We have RFC connection from GWS to SYS1 and from GWS to SYS2.

    Thank You.


    1. Andre Fischer Post author

      Hi Seshu,

      as I wrote in the section “Caution” in this document there is a way to achieve a fault tolerant behavior for exactly these kind of scenarios.

      Since as of SP07 of SAP Gateway 2.0 it is possible to make the READ feed requests of a service in “Multi Destination Composition” mode error tolerant (SPRO -> SAP NetWeaver -> Gateway -> OData Channel -> Composition -> Flag OData Services to be error tolerant in case of MDC)

      Best Regards,


      1. Former Member

        Hi Andre,

        Yes. We have added our service in ‘Flag
        OData Services to be error tolerant in case of MDC’ table in SPRO. Which is able to
        handle if there is any runtime error in one system (in this case, rfc
        connection is successful and service call can meet backend system). But, When
        the whole backend system is down (which results in rfc connection fail) for
        maintenance, the result is some rfc error but not the result from another
        backend. Could you please tell me what is the reason.

        Thank you for looking into this issue.



  2. Former Member

    Hi Andre, great blog! With this scenarios, how would you know/specify which system is making the call since they all using the same gateway server?



  3. Oliver Walter

    Hello everyone,

    we face an issue with multiple Aliases assigned to an OData Service, where the aliases are not restricted by user roles:

    System_A (Default)




    In General every user could call every alias and the selction is controlled by SAP_Origin. A request goes only to one particular System.

    No it can happen, that a user has Access to Gateway, but is missing sufficient authorization to any of the backends. `In that case we return a message, that user is not authorized for backend xxx.

    Unfortunatly now we the issue that the Odata call is executed with SAP_Origin=System_D, but the error Returns always the Default Alias System_A.

    Switching off the Default Alias is also not working.

    Any idea to solve this issue?

    Regards Oliver

  4. Beat Birrer

    Hello everyone,

    I have a generated oData-Service based on a CDS-View. I try the multi origin composition to get data from two different clients. This works basically but when I add a filter to the request to get the data from a specific client, i’ll always get an error. There are no issues when I do the same with a manually created oData-Service. So I think there is a problem with the SADL based services.

    This is the request


    And this the response:


    Can anyone help me?

    1. Andre Fischer Post author

      Hi Beate,

      I tested this myself and found the same issue.

      I raised an SAP internal incident for that.

      Can you please create a question in the forum that I can answer once I get Feedback from my colleagues.

      I don’t see a workaround right now since the SADL runtime used the io_tech_request_context object.

      In contrast to the mapped data source approach there is no option to manipulate the filter string.





Leave a Reply