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
- SAP Managed Tags:
9 Comments
