Hy everyone,

i recently came to a point where i had to adapt rfc destinations in various code fragments. E.g rfc destinations where set during initalization of an abap report program – that was working fine & everything was ok until the system was changed & rfc destinations were renamed due to new requirements. Unfortunatly the rfc destinations were not maintainable using customizing for specific abap code fragments. Therefore i had to change a lot of programs and function modules and had to transport everything in sap system landscape. I found this not so pretty. It was a lot of work finding & adapting all the source code’s that used or set rfc destinations. Therfore i thought about a way how rfc destinations could be handled in a more flexible & customizable way. Now i would like to describe the solution that i thought about and implemented at a customer.

Step 1: Set up the customizing tables

I wanted to group rfc destinations. Therefore i introduced scenario’s for rfc destination and sub scenario’s to be more flexible at customizing level. Usually also the system which calls an rfc function module is a key for getting the right rfc destination. System customizing could be enhanced by MANDT and/or other key fields. This depends much on the requirements you have. I’m sure you all know how view clusters are created and therefore i do not further explain it here and just show the results in the following printscreens. If you have problems creating a view cluster let me now by pm or in comments and i’ll add some content about view clusters.

Result of step 1:

rfc scenario definition:

/wp-content/uploads/2015/02/rfc_scenario_646923.png

rfc subscenario definition:

/wp-content/uploads/2015/02/rfc_subscenario_646938.png

rfc systems per subscenario and scenario:

/wp-content/uploads/2015/02/rfc_system_646939.png

rfc destination per system, subscenario and scenario. This table is the place where the rfc destination which we want to use in our abap code is stored.

/wp-content/uploads/2015/02/rfc_destinations_646940.png

I’ve added begin and end dates so rfc destinations could also change at a specific day and or period without a developer that has to think about timing or transporting something.

With this approach we have a pretty flexible way to configure our rfc destinations. At this point i want to mention, that productive use of this approach is possibly but the description here is not yet a 100% solution. So some thinking about productive use would have to be done especially for additional requirements (e.g. key fields in customizing and so on). At a customer i continued a solution with this approach with some further requirements but the general idea stayed the same. As i wanted to transport my idea i tried to kept customizing example as simple as possible.

Step 2: Use rfc destination customizing in abap sources:

This is quite simple. Create a class eg. ZRFC_CUST and add required methods within. I would call this class a helper or utility class & would not declare it as final so new classes could inherit from this class. This has the nice effect, that i can add further attributes in the class (e.g. ZRFC_CUST_INVOICE) that inherited from the helper/utility class (ZRFC_CUST) to call super methods within redefined methods using the added attributes for scenarios, subscenarios and so on. Like this the code stays small and required time for implementations also.

For the customizing in the printscreen above i would provide  eg. the following methods all dependig on your requirements:

1) Read RFC Scenario

ZRFC_CUST=>GET_SCENARIO_DESC( IMPORTING iv_scenarioid = ‘SCEN1’ ).

2) Read RFC Subscenario(s)

ZRFC_CUST=>GET_SUBSCENARIO_DESC( IMPORTING iv_scenarioid = ‘SCEN1’ iv_subscenario = ‘S1_SUB1’ ).

ZRFC_CUST=>GET_SUBSCENARIOS( IMPORTING iv_scenarioid = ‘SCEN1’ EXPORTING et_subscenarios = lt_subscenarios ).

3) Read RFC System(s)

ZRFC_CUST=>GET_SUBSCENARIO_SYSTEMS( IMPORTING iv_scenarioid = ‘SCEN1’ iv_subscenario = ‘S1_SUB1’ EXPROTING et_systems = lt_systems ).

ZRFC_CUST=>GET_SUBSCENARIO_SYSTEM( IMPORTING iv_scenarioid = ‘SCEN1’ iv_subscenario = ‘S1_SUB1’ iv_system = sy-sysid ).

4) Read RFC Connection(s)

ZRFC_CUST=>GET_DESTINATION( IMPORTING iv_scenarioid = ‘SCEN1’ iv_subscenario = ‘S1_SUB1’ iv_system = sy-sysid ).

ZRFC_CUST=>GET_DESTINATIONS( IMPORTING iv_scenarioid = ‘SCEN1’ iv_subscenario = ‘S1_SUB1’ iv_system = sy-sysid EXPORTING et_destinations = lt_destinations ).

I hope you like this post & get some ideas how to handle rfc destinations in your code.

Feedback & comments are welcome & i appreciate good input a lot to improve this post.

Have a nice day & enjoy it.

Best regards,

Michael

To report this post you need to login first.

2 Comments

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

  1. Suhas Saha

    If i understand your design correctly, it is very similar to how SAP handles logical & physical  (read: application server)filenames.

    Is it possible for you to describe how the RFC tables look like and what are the binding conditions you used while building the view cluster?

    BR,

    Suhas

    (0) 
    1. Michael Albrecht Post author

      Hy Suhas,

      i can provide the db tables & maintenance view fields incl. the structure of the view cluster as soon as i’ll find some free time. pls follow me or bookmark this post to get the update.

      Best regards,

      Michael

      (0) 

Leave a Reply