Support of multiple backend systems – How to use Multi Origin Composition and Routing
Changes
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.
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.
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
/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:
- 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.
/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:
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
/sap/opu/odata/IWBEP/GWDEMO/$metadata
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
http://gw_on_host1:50006/sap/opu/odata/IWBEP/GWSAMPLE_BASIC/ProductSet
the system alias LOCAL will be used whereas when using the following URL
http://gw_on_host2:50006/sap/opu/odata/IWBEP/GWSAMPLE_BASIC/ProductSet
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
If this is not sufficient, SAP provides the enhancement spot /IWFND/ES_MGW_DEST_FINDER for the implementation of customer specific rules.
See SAP Help Portal:
http://help.sap.com/saphelp_gateway20sp09/helpdata/en/5b/3391526aa6224fe10000000a445394/content.htm
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
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
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
Hi Andre Fischer,
Is there workaround for this?
I'm having similar issues for MyInbox. I've followed the SAP Note 2944571 - My Inbox substitution - user does not exists by maintaining the TaskProcessing service in "Flag OData Services to be error in case of MDC" in SPRO. However when User A do substitution from which having system backend 1 and backend 2 access to substitute User B which only exists in backend 2, the substitution raised an error just like what is described in the SAP Note.
Anyone face similar issue and able to resolve?
Thanks.
Regards,
Ben
Hi Ben,
as indicated in the documentation the fault tolerance only works for read requests.
You can flag READ feed requests of a service in MOC mode error-tolerant.
And doing a substitution is probably not a READ request.
What you can try to do is to implement your own logic on top in the extension point of the destination finder as described here.
https://blogs.sap.com/2016/08/08/how-to-implement-custom-dynamic-system-alias-calculation-in-sap-gateway/
You could for example check if the user has an appropriate role in the hub system that indicates that he or she has a user in the backend.
Or you can implement other business logic to find out if some body has use in the system(s) that shall be called.
Best regards,
Andre
Appreciate for your prompt response Andre Fischer, !
Will check on the blog you shared!
Thanks.
Regards,
Ben
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
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
Oliver,
Clear cache /IWFND/CACHE_CLEANUP t-code and then try.
~Rahul
Hi Rahul,
thanks for the hint, but this does not solve the issue. Any ideas?
Regards Oliver
Hi Andre
Please, which the content of the role? The authorization objects?
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?
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.
Regards,
Andre
Hi Andre,
thanks for your answer and for creating an internal incident.
I create the following question in the forum where you can answer if you get some news.
https://answers.sap.com/questions/621502/odata-multi-origin-doesnt-work-with-sadl-runtime.html
Thanks and regards,
Beat
Hi,
Does this work for batch operation?
We have a similar setup, but it only works of the requests are on a non-batch request.
Thanks,
Gin
Hello,
how can we implement this behaviour when using SAP Cloud Platform OData Provisioning?
Hi Marc,
SAP Cloud Platform OData Provisioning does not support routing.
It only supports multi origin composition (MOC).
So you can't implement this behavior using SAP CP ODP.
Regards,
Andre
Thank you for your response. This seems like a showstopper for us, since we are currently migrating from on-premise to the cloud. Is this on the roadmap?Is there a workaround?
Hi Marc,
I checked with my colleagues and they told me that it is on the roadmap but I can unfortunately not share any Details, especially not when this feature is planned to be delivered.
Depending on the complexity you might be able to use several sub accounts that are connected to different backend Systems?
Best Regards,
Andre
Hi Andre ,
I have a scenario where I need to build an ODATA Service in SAP CRM system to SFDC to consume. This ODATA service, in turn, has to communicate to C4S by consuming multiple standard C4S ODATA service and RFC to S4 system to pull some of the data. For this scenario, what is the recommended approach?
Regards
Kiran
It depends on the SAP NetWeaver Release in your SAP CRM system and the timeframe in which the new service has to be built.
1.
The new SAP Cloud ABAP Environment might be an option for you since the new ABAP RESTful programming model allows for both, the consumption of OData Services as well as the consumption of RFC function modules and is perfectly suited for an ABAP based extension for SAP on premises systems as well as for SAP S/4 HANA Cloud.
There are still some technical restrictions that one would have to look into whether they are a showstopper right now.
2.
The second option would be to build an OData Service in the CRM using the SAP Gateway Framework using SEGW.
Here one would have to look how calling an OData service in C4S can be implemented since the OData Proxy will not yet be part of your SAP Gateway framework functionality.
HTTP calls can be performed but you would have to parse the OData reponse on your own.
Regards,
Andre
Hello Andre,
Thank you very much for your Article!
We can connect one Gateway(Hub) with one Mandand with multiple Mandand in S/4 HANA On-Premise?
Several Apps use Standard System Alias (Example S4FIN). How connect we in this Case?
Best Regards
Olga
Yes , you can define several system aliases (S4FIN1, S4FIN2, …) that will use RFC destinations that point to Client 001, 002, ...
So you simply have to define additional system aliases for all clients in your S4 Backend and assign those to your services using transactin /iwfnd/maint_service.
Hello Andre,
We have clients 100, 200, 300 in S/4 HANA. In Gateway Hub (Fiori) have we only one client 100. If I understood correctly, for each Client should we do System Alias FI100, FI200, FI300 with Role ZGW_100, ZGW_200, ZGW_300 and assign to OData Service. Should we assign System Alias in each Tile by Parameter Field in Fiori Launchpad Designer? What else should we do? How do we set SAP GUI, WEB Dynpro in this Case to Fiori Launchpad? Is there documentation?
Best Regards
Hello Andre,
thanks for this post. It’s great. Just one thing I came across. As far as I found out the determination of the table is not like it is in all other SAP customizing tables meaning the more restrictive the datarecord is it will be taken into account. So it is not possible to have one data record without a user role and one record with a user role and SAP searches for the best fitting.
In my opinion this is unfortunatly not very flexible because it implies that you have to maintain all user roles. There is a way to achieve it to implement Badi /IWFND/ES_MGW_DEST_FINDER but honestly it would be great if that would be the last option.
I didn’t raise a SAP call as I think it’s more a design question than a real bug, but maybe you can adress it internally?
BR
Stephan
Hi Stephan,
thank you very much for your feedback.
The design for the customizing of the destination finder is already out for about 10 years now and though it is not the most flexible we do not plan to change anything here given the fact that any change here might have the potential to destabilize the huge number of existing installations out there.
So unfortunately the only thing that I can suggest you would be to implement the Badi with your own optimized code.
But maybe you can share your implemenation with others if you write a blog and share your code on GitHub?
Best regards,
Andre
Hello,
I have a local OData Service and would like to add a second backend from another SAP client. I want to connect the second backend via an RFC-Connection.
Do I need to implement a OData Service in the second backend?
Right now I have a local connection (local client) and an RFC-Connection to the client (second backend) and matching it to a system alias. But its giving me duplicate local data.
Is there a step by step guide how to establish a second backend to an existing hub?
Thanks in advance
You simply have to create a second system alias that uses the RFC destination that points to the other client.
And then you have to add this system alias to the service that you have already registered.
That should work.
https://help.sap.com/saphelp_gateway20sp12/helpdata/en/46/bf1c1543eb406dbeece15d05d5582b/frameset.htm
Thank you for your reply.
I had already taken all the steps you mentioned.
In T-Code SM59 the Remote-Login is working fine.
This is my System Alias:
But still in the SAP Gateway Client the output (SAP__Origin=’BACKEND-2′) is from client 100 instead of 400.
I havent done any implementation or anything else in the client 400 System. Am I missing something there?
From your screen shot it is clear that this is not going to work since the alias is named "SYSTEM-2" and not "BACKEND-2".
Also it is strange why you are using a software version /IWPGW/BWF for the system alias "SYSTEM-2".
I would create a new system alias without a software version instead.
Have you tried to call your service using the option ";mo" ?
/sap/opu/odata/IWBEP/GWDEMO;mo/CountryCollection/
This should return values with keys from both "LOCAL" and "SYSTEM-2".
Best regards,
Andre
Sorry I pasted the wrong SAP_Origin. Instead it is "SAP__Origin=’SYSTEM-2′).
And yes I am using ";mo"
One last question to my issue.
When I uncheck all checkboxes in "Manage SAP System Aliases" and hit the button "Check Connection" I get this error message:
I havent found anything for this error message?
Does this mean the RFC-Destination is not created? Because in t-code sm59 its working fine and "Remote Logon" in sm59 is also working fine.
We found the solution. The RFC Connection was not created in upper case. Now everything is working fine.