4

is there a good way to use not hardcoded RFC destinations?

Right now our solution is to check which system is used and then assign the destination to a variable 

IF cl_role EQ 'P'.
      p_dest = 'ESW300'.
   ELSE.
      p_dest = 'EAW300'.
   ENDIF.

which we use when calling our destination function.

CALL FUNCTION 'XYZ' DESTINATION p_dest

Is there a good way to not use the hardcoded destinations?

Thank you for the help!

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
Jen Mer
  • 101
  • 1
  • 3
  • 10
  • 2
    Store it in a table that is maintained correctly in every system? – peterulb Apr 08 '20 at 19:15
  • 2
    Why even bother? Just change the name to something functional that does not contain what seems to be the system ID and client and makes sense for its function. Then the actual destination is maintained in SM50. – Gert Beukema Apr 09 '20 at 02:09

2 Answers2

4

RFC destinations are already an abstraction of the endpoint so I would not recommend to abstract it yet again. For that reason I would suggest using the same name across systems as a leading practice and not change them to be instance specific.

Otherwise I would suggest instead of hard-coding that you determine the RFC destination dynamically if you really want to use different RFC destination names across systems (I would not). If you look at some SAP standard programs they use specific format to determine the expected RFC destination name for example <hostname>_<systemname>_<system number> is used by SolMan but there are many examples if you look at the standard RFC destinations you can find.

I would also recommend as a best practice that any hard coded values never be populated inline as your example shows but in a header constant.

I realize you were probably only trying to focus on your question but for others reading this.

Suncatcher
  • 10,355
  • 10
  • 52
  • 90
SAP Pro
  • 397
  • 2
  • 8
  • Can you explain how can SAP Solution Manager hardcode the "direct destinations" (`hostname_sysid_sysnr`)? It can't know the customer systems to be connected, the customers have to define them somewhere. What if you do a system copy? Can you give more information please? Note that SAP CRM defines an abstraction for RFC destination of ERP (tables behind FMs `CRM0_READ_RFC_DEST` and `SMOF_READ_SMOFERPSH`). NB: Note that these "direct destinations" are not defined in `SM59` and a trusted relationship (`STRUST`) must be defined otherwise a manual log in is requested. – Sandra Rossi Apr 10 '20 at 06:38
  • Sandra, sorry it probably was not clear, the coding in some programs within Solution manager dynamically determine the RFC destination to use using the pattern I documented, A simple example and I don't know the program but when you define a instance and clients in Solution manager for example and then go to develop the trust relationships it generates the RFC destinations using a pattern similar to what I showed to generate the RFC destinations it will create automatically – SAP Pro Apr 10 '20 at 20:40
  • 1
    I couldn't comment completely in the first comment but the CRM0_READ_RFC_DEST is actually required because there are attributes that are necessary before connecting to the external system. For example the FM checks the load type, download type etc, so the abstraction is necessary so that you can select a destination based on capabilities in that case. I would probably approach it the same way given the requirement to select one of several RFC destinations based on attributes that cannot be stored in the RFC destination (SM59) – SAP Pro Apr 10 '20 at 20:57
  • So, what I understand, is that SolMan stores all three hostname, sysid, sysnr, in a table, creates automatically the RFC destinations anyway via `STRUST`. So, concerning the OP question, I understand that you propose to create a custom table too. – Sandra Rossi Apr 11 '20 at 08:13
  • Concerning the solution of hard-coding the RFC destinations in the ABAP programs, it requires that all the systems are installed by choosing the same names in Development, Test, Production. It was not the case for the customers I was working on (for instance, for SAP ECC, the RFC names were EDxxx for Development, ETxxx for Test, EPxxx for Production, the letter "E" being for ECC). Hence, there were two solutions: either using the current logical system as the RFC name and the change the first letter to "E" to access ECC, or use a custom table or TVARVC or BD97 to store RFC names. – Sandra Rossi Apr 11 '20 at 08:22
  • Sandra, solman maintains tables of all connected systems, this is part of its functionality. If you look at my answer to the question I never recommend using a custom table. – SAP Pro Apr 12 '20 at 12:29
  • Obviously every system can be different, but even in the example you give you can dynamically determine the Instance so no custom table needed.. I would not recommend use of TVARVC, this is not it’s purpose, it is intended for saving report variant values. BD97 also is intended for another purpose and here you run a risk that it is already in use or it will be needed at some future date. Hope this helps. – SAP Pro Apr 12 '20 at 12:46
  • Thanks for the feedback. Honestly, if I ask these questions, it's because I never saw in 20 years a system landscape with the same names for RFC destinations in each Dev/Test/Prod system, and I don't see how to use direct destinations because they will be different in each Dev/Test/Prod system. Well, let see if someone can clarify that, or maybe it's an easy case but I don't get it. – Sandra Rossi Apr 12 '20 at 16:49
  • I agree, in the last 20 years I have seen every combination imaginable, but not really an issue for a developer, just figure out what the naming standard that customer used and your all set to dynamically determine it. – SAP Pro Apr 12 '20 at 19:32
  • 1
    For abstraction/alias, the tables `SSM_RFC` and `/UI2/SYSALIASMAP` are also available. More info at https://blogs.sap.com/2015/06/01/configuring-remote-systems-in-sm59/ One use case is to map SAP_CRM (or similar generic alias) to a specific instance in D, Q, P. Very similar to how it's done in Gateway or good old Portal. – Mikael G Apr 14 '20 at 12:46
3

I saw every company creating its own custom table containing the RFC destinations (maintained differently in every SAP system by administrators; eventually it can be custom entries in the standard table TVARVC), but nobody published anything about it. Eventually this blog post but it's a very complex solution, only documented, but no code provided.

An easier (and adequate?) way is to create a Logical System (transaction code BD54) for every system, and assign a RFC destination (transaction code BD97).

In your program, do this kind of thing:

SELECT SINGLE rfcdest
    FROM tblsysdest
    WHERE logsys = 'CRM' 
    INTO @DATA(crm_system).

CALL FUNCTION 'RFC_PING' DESTINATION crm_system
    EXCEPTIONS OTHERS = 1.

PS: prefer to abstract things, like creating a global class with one method GET_CRM_SYSTEM instead of hardcoding the SELECT in every program.

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
  • Someone who knows and mentions BD97... +1 Of course if the destinations are registered External programs we have a different game. But looks like a BD64/BD97 logical system / standard destination type problem to me too. – phil soady Apr 13 '20 at 23:18