Support of multiple backend systems – How to use Multi Origin Composition and Routing
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.
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.
When performing a MOC call like the following using the Gateway Client
You would get responses like the following:
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:
- 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)
- 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.
- 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.
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.
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.