Technical Articles
How to implement custom dynamic system alias calculation in SAP Gateway
Introduction
The standard routing used by the destination finder can be based on user role assignments and host names of the OData client calling the service. It has however turned out that some customers have requirements for the routing that cannot be implemented by just assigning roles.
The standard routing based can thus be enhanced by custom rules. These rules can be implemented in a BadI.
This option is described in the SAP Online Help Dynamic System Alias Calculation Via /IWFND/ES_MGW_DEST_FINDER – SAP NetWeaver Gateway – SAP Library. What was missing so far was a simple how to guide that showed how to perform the implementation steps.
You can find more detailed information about system aliases in the following blog All About System Alias and Routing of Requests in SAP NetWeaver Gateway and about routing and multi origin in my SCN document Support of multiple backend systems – How to use Multi Origin Composition and Routing
Another example of an implementation of this enhancement spot can be found in the following blog post https://blogs.sap.com/2020/04/21/multiple-backend-systems-in-gateway-server-enhanced/
Implementation of the enhancement spot
For a detailed description how to implement a BadI see the SAP Online Help: How to Implement a BAdI – Enhancement Framework – SAP Library
- Start transaction SE80 and search for the enhancement spot /IWFND/ES_MGW_DEST_FINDER
- Start to create a BadI implementation by pressing the Create Enhancement Implementation pushbutton.
- In the next screen enter the following values for the enhancement implementation
- and now you can enter the values for the implementing class for your BAdI impelmentation
- Now you can start to implement the class
We will use the following (very simplified) logic to determine system aliases for our users:
method /iwfnd/if_mgw_dest_finder_badi~get_system_aliases.
if iv_service_id = ‘ZGWSAMPLE_BASIC_0001’.
case iv_user.
when ‘USER1’.
delete ct_system_aliases where system_alias <> ‘ERP_1’.
when ‘USER2’.
delete ct_system_aliases where system_alias <> ‘ERP_2’.
when others.
delete ct_system_aliases where system_alias = ‘ERP_1’.
delete ct_system_aliases where system_alias = ‘ERP_2’.
endcase.
endif.
endmethod.
- For the service GWSAMPLE_BASIC use the following assignments of system aliases using transaction /n/IWFND/MAINT_SERVICE
How does the destination finder works ?
If USER1 calls the service the destination finder will determine just one system alias, namely ERP_1.
If USER2 calls the service the destination finder will determine also just one system alias, namely ERP_2.
If any other user, for example a user USER3 calls the service the destination finder will determine two system alias entries, namely ERP_3 and ERP_4 where ERP_3 is marked as a default system.
Please note that we have assigned no roles since we want to determine the system aliases via custom code shown above.
How routing works can best be demonstrated by using the multi origin option to see which system aliases are selected by the destination finder. When three different users USER1, USER2 and USER3 are calling the service GWSAMPLE_BASIC using the following URI:
/sap/opu/odata/IWBEP/GWSAMPLE_BASIC;mo/ProductSet?$filter=ProductID eq ‘HT-1000’&$select=SAP__Origin,ProductID&$format=json
they would retrieve the following data:
User | http response |
---|---|
USER1 |
{ “d” : { “results” : [ { “__metadata” : { }, “SAP__Origin” : “ERP_1”, “ProductID” : “HT-1000” } ] } } |
USER2 |
{ “d” : { “results” : [ { “__metadata” : { }, “SAP__Origin” : “ERP_2”, “ProductID” : “HT-1000” } ] } } |
USER3 |
{ “d” : { “results” : [ { “__metadata” : { }, “SAP__Origin” : “ERP_3”, “ProductID” : “HT-1000” }, { “__metadata” : { }, “SAP__Origin” : “ERP_4”, “ProductID” : “HT-1000” } ] } } |
Please note that USER3 would retrieve data from two backend systems (ERP_3 and ERP_4) in case the multi origin option is used.
If this user would try to retrieve data from the same entity set without the multi-origin option the routing would use the destination ERP_3 which has been marked as default.
For USER1 and USER2 only one system alias was determined so the choice of the system alias is unique anyway.
Please also note that if no system alias is flagged as default the behavior is undetermined. You will find entries in the error log such as
No System Alias flagged as “Default” for Service ‘ZGWSAMPLE_BASIC_0001’ and user ‘USER9’
Using custom http header in your destination finder
The standard implementation of the destination finder allows to perform a routing based on user roles in the SAP Gateway Hub system or based on the hostname of the caller that calls the OData service.
If you have a look at the signature of the method /IWFND/IF_MGW_DEST_FINDER_BADI~GET_SYSTEM_ALIASES you find that the following parameters are available for input
- IV_SERVICE_ID, the service id of the service that has been called
- IV_USER, the name of the user that calls the service
- CT_SYSTEM_ALIASES, the list of system aliases that has been determined based on the service configuration (user role assignement)
and finally
- IT_REQUEST_ATTRIBUTES, that contains a list of name value pairs of the http header attributes.
If we add a customer http header such as mycustomheader with the value ‘42‘ to the request
we would be able to retrieve this value ’42’ from the table IT_REQUEST_ATTRIBUTES.
I hope this will help you if you have to implement a custom dynamic system alias calculation in SAP Gateway.
Best Regards,
Andre
hey,
your doc helped me alot, as per my understanding what i have understood is that you are marking system alias as default manually ..
can i set system alias as default according to the user in iv_user parameter ???
Hi Aishwarya,
setting the "default" flag for a system alias is a customizing task. The default system flag (as explained here in my post Support of multiple backend systems - How to use Multi Origin Composition and Routing ) "is needed to specify a specific system alias to be used if more than one system alias is found but only one is needed.".
So if you want to route a user to a specific system alias you could do so by writing appropriate coding as mentioned above.
For a more detailed discussion please create a question in the Gateway forum http://scn.sap.com/community/post!input.jspa?containerType=14&container=2130&contentType=1
Hi Andre,
Thanks for detail information ℹ
Sounds Fantastic, Really helpful in some cases 🙂 🙂
Kind Regards,
Pavan G
Hi Andre,
Thanks for an interesting blog. I want to create just one OData service registered on the gateway hub. Most of the entity sets contained within this service use just one backend but there is one entityset where the data will come from SuccessFactors in the cloud. I will use the SCP destinations to connect to the SF.
Is this possible to do it as an all in one OData service or should I just call the SF API and the Gateway registered OData service directly from a sap fiori application using 2 separate odata calls.
rgds
James
I would recommend to use 2 Odata service calls as described here
Hi Andre,
If i have standard system landscape ( development system - quality system - productive system ) and one front-end system for fiori. How a can add ODATA service in transaction /IWFND/MAINT_SERVICE on front-end server, to run fiori applications with dev, quality or productive data? Maybe I need 3 front-end servers ?
HI Andre,
The URL is destroyed i feel.
Dynamic System Alias Calculation Via /IWFND/ES_MGW_DEST_FINDER – SAP NetWeaver Gateway – SAP Library.
Regards
Tejas
I fixed the link. Thanks for telling me.
Hi Andre,
Thank you for your blog that is very informative.
Currently I am facing one issue where I seek your help.
We have implimented custom solution to determine backend system based on user persona using the same BADI which you have explained and it seems to working just fine.. though from quite some time we are facing issue in production system that too is intermittent where some time odata is giving error ‘resource not found’ for certain entities.. and this is happening for only those entities which are present in either of the system say we have two system Prod1 and Prod2 one entity taxID is relevant for Prod1 only so we have implimented it in Prod1 only.. now when user from Prod1 sometime getting Entity taxID does not exist. This can be resolved on adding same entity in Prod2. Though we are not able to understand why this error is coming at first place. Again this is intermittent issue and only happning in production environment.. we have checked the roles.. user who is trying to access this also has roles assined specific to Prod1 only…
Please help.