Skip to Content

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

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

 

01 show enhancement spot.png

  • Start to create a BadI implementation by pressing the Create Enhancement Implementation pushbutton.

 

02 create badi implementation.png

 

 

  • In the next screen enter the following values for the enhancement implementation

    03 create badi implementation enter values.png

  • and now you can enter the values for the implementing class for your BAdI impelmentation
    03 create badi implementation 03.png
  • Now you can start to implement the class

    /wp-content/uploads/2016/08/implement_class_1011222.png

 

 

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

    MAINT_SERVICE_SETTINGS.png

 

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 42to 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

To report this post you need to login first.

6 Comments

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

  1. aishwarya chand

    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 ???

    (0) 
    1. Andre Fischer Post author

      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

      (0) 
      1. Pavan Golesar

        Hi Andre,

        Thanks for detail information ℹ

        if you want to route a user to a specific system alias you could do so by writing appropriate coding as mentioned above.

        Sounds Fantastic, Really helpful in some cases 🙂   🙂

        Kind Regards,

        Pavan G

        (0) 
  2. James Ian Moyes

    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

    (0) 
  3. Alexander K

    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 ?

    (0) 

Leave a Reply