What happens to RFC destination name when transported to different systems?

[Former Member]

Hi Experts,

Creating an Odata service using RFC function module, Service has been developed in system A which is dev system where as RFC function module is developed in system B which is also a dev system, There is a RFC destination created in between 2 systems say BCLNT001. While creating service in system A I used RFC destination as BCLNT001.

My doubt is RFC destination is created between 2 dev systems, same RFC destination will not be available in Quality and prod systems. So how to handle this scenario.

Is there any way where we can assign RFC destination based on system while creating service.

[former_member184867]

This is the reason we have System alias concept in Gateway. You should avoid coding based on RFC destination in DPC.

Your code should remain same everywhere, however system alias needs to be configured separately in the Production/Quality/Dev systems. here are some links for you

Assigning SAP System Alias to OData Service - SAP NetWeaver Gateway - SAP Library

http://scn.sap.com/community/gateway/blog/2013/05/30/system-alias-and-routing-of-request-in-sap-netw...

Regards,

Atanu

[former_member184739]

Hi Atanu,

I do understand System alias is a viable option. But for each system we need to create a alias. Especially for bigger clients we are not given access to production systems. So why not use below approach as explained above ?

"Another optimal approach would be create a custom Z-Table with following fields.

1.SID - System ID (Key field)

2.RFC_DEST - RFC Destinaion

Fill the table with DEV,QA,PRD RFC Destinations.

Now before executing the FM based on the system select the entry from the table as follows.

lv_sid = sy-sysid.

Select RFC from z_config  into lv_rfc_dest where sid = lv_sid.

if sy-subrc eq 0.

Call RFC lv_rfc_dest.

endif.

Note:

Make sure you transport the table along with the entries.

http://scn.sap.com/docs/DOC-44138

http://****************/Tips/Basis/Transport/TableEntries.htm

"

Let me know if there are any drawbacks in this method. Also we arent hard coding the RFC dest. instead maintained in a custom table.

Regards

Prabaharan Asokan

[former_member184867]

Yes there are drawbacks of this approach. This may work for your scenario if you developing a custom service and writing your own custom logic.

For SAP Delivered service I think you need to configure proper system aliases even in production system(may  be you can verify once).

Integration scenarios such as SPI, Easy query, MDX, OSCI  depend on the system alias setting. They will fail in production in absence of proper system alias.

[former_member184739]

Great piece of information. Thanks Atanu.

[AshwinDutt]

Hello Mounesh,

Usually System Alias and RFC Destination would be different across the landscapes with different naming conventions. So RFC Destinations and System Alias can be manually created and service can be finally registered and activated as well.

I suggest the below.

Transport the GW objects. Say from Dev to Quality. Later in Quality create RFC Destination and System Alias manually and register the service.

Below will help for more info and other ways->

Regards,

Ashwin

[former_member184739]

Hi Mounesh,

Use System Id of the current system to differentiate and handle it appropriately.

If SY-SYSID ="DEV"

   Call Dev RFC Dest.

elseIf SY-SYSID="QA"

Call QA RFC Dest.

endif.

Let me know if this works. Thanks.

[former_member184739]

Hi Mounesh,

Another optimal approach would be create a custom Z-Table with following fields.

1.SID - System ID (Key field)

2.RFC_DEST - RFC Destinaion

Fill the table with DEV,QA,PRD RFC Destinations.

Now before executing the FM based on the system select the entry from the table as follows.

lv_sid = sy-sysid.

Select RFC from z_config  into lv_rfc_dest where sid = lv_sid.

if sy-subrc eq 0.

Call RFC lv_rfc_dest.

endif.

Note:

Make sure you transport the table along with the entries.

http://scn.sap.com/docs/DOC-44138

http://saptechnical.com/Tips/Basis/Transport/TableEntries.htm

Regards

Prabaharan Asokan