Changes

08.08.2016 – Added link how to implement custom routing

Usecase

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

/wp-content/uploads/2015/01/systems_small_634075.png

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.

Caution

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:

Solution

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

/sap/opu/odata/IWBEP/GWDEMO;mo/CountryCollection/

You would get responses like the following:

USER_A

<entry>

               <id>http://<host>:<port>/sap/opu/odata/IWBEP/GWDEMO;mo/CountryCollection(SAP__Origin=’BACKEND_1′,CountryCode=’AD’)

               </id>

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

               <updated>2015-01

</entry>

USER_B

<entry>

               <id>http://<host>:<port>/sap/opu/odata/IWBEP/GWDEMO;mo/CountryCollection(SAP__Origin=’BACKEND_1′,CountryCode=’AD’)

               </id>

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

               <updated>2015-01

</entry>

<entry>

               <id>http://<host>:<port>/sap/opu/odata/IWBEP/GWDEMO;mo/CountryCollection(SAP__Origin=’BACKEND_2′,CountryCode=’AD’)

               </id>

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

               <updated>2015-01

</entry>

USER_C

<entry>

               <id>http://<host>:<port>/sap/opu/odata/IWBEP/GWDEMO;mo/CountryCollection(SAP__Origin=’BACKEND_3′,CountryCode=’AD’)

               </id>

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

               <updated>2015-01

</entry>

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.

/sap/opu/odata/IWBEP/GWDEMO/CountryCollection/

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:

WRONG_CONFIGURED_SYSTEM_ALIASES.JPG

than the following error message would occur:

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

ERROR_no_system_alias_flagged_as_default.JPG

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

/sap/opu/odata/IWBEP/GWDEMO/$metadata

Custom routing

If role based routing 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.

9 Comments

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

  1. Seshaiah Machavarapu

    Hello,

    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.

    Seshu

    (0) 
    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,

      Andre

      (0) 
      1. Seshaiah Machavarapu

        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.

        Regards,

        Seshu

        (0) 
  2. Nguyen David

    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?

    Thanks

    DT

    (0) 
  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)

    System_B

    System_C

    System_D

    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

    (0) 

Leave a Reply