Abap 最佳实践，而不是硬编码的RFC目的地？

是否有一种使用非硬编码RFC目的地的好方法

现在我们的解决方案是检查使用哪个系统，然后将目标分配给变量

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

调用目标函数时使用

调用函数“XYZ”目的地p\u dest

有没有不使用硬编码目的地的好方法

---

谢谢你的帮助

我看到每家公司都在创建自己的自定义表，其中包含RFC目的地（管理员在每个SAP系统中以不同的方式维护；最终它可以是标准表

TVARVC

中的自定义条目），但没有人发布任何关于它的信息。最终，这是一个非常复杂的解决方案，只有文档记录，但没有提供代码

一种更简单（且适当）的方法是为每个系统创建一个逻辑系统（事务代码

BD54

），并分配一个RFC目的地（事务代码

BD97

）

在您的程序中，执行以下操作：

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

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

---

PS：更喜欢抽象事物，比如用一个方法创建一个全局类

GET\u CRM\u SYSTEM

，而不是对每个程序中的SELECT进行硬编码。

RFC目的地已经是端点的抽象，因此我不建议再次对其进行抽象。出于这个原因，我建议在所有系统中使用相同的名称作为主要实践，而不要将它们更改为特定于实例的名称

否则，我建议，如果您真的希望跨系统使用不同的RFC目的地名称，而不是硬编码，那么您可以动态地确定RFC目的地（我不会这样做）。如果您查看一些SAP标准程序，它们使用特定格式来确定预期的RFC目的地名称，例如SolMan使用了

。

，但如果您查看可以找到的标准RFC目的地，则有许多示例

我还建议，作为一种最佳实践，任何硬编码的值都不能像您的示例所示以内联方式填充，而是以头常量填充

---

我知道你可能只是想把注意力集中在你的问题上，但是对于其他阅读本文的人来说。

将它存储在每个系统都正确维护的表格中？为什么还要麻烦呢？只需将名称更改为功能性名称，不包含系统ID和客户端，并且对其功能有意义。然后在SM50中维护实际目的地。您能否解释一下SAP Solution Manager如何硬编码“直接目的地”（

hostname\u sysid\u sysnr

）？它无法知道要连接的客户系统，客户必须在某个地方定义它们。如果你做系统拷贝呢？你能提供更多的信息吗？请注意，SAP CRM为ERP的RFC目的地定义了一个抽象（FMs

CRM0\u READ\u RFC\u DEST

和

SMOF\u READ\u SMOFERPSH

后面的表格）。注意：请注意，SM59中未定义这些“直接目的地”，必须定义信任关系（

STRUST

），否则将请求手动登录。Sandra，很抱歉，可能不清楚，Solution manager中某些程序中的编码使用我记录的模式动态确定要使用的RFC目标，这是一个简单的示例，我不知道该程序，但当您在Solution manager中定义一个实例和客户端，然后开发信任关系时，它会使用类似于我所展示的生成RFC目的地的模式来生成RFC目的地，它会自动创建。我无法在第一个示例中完全进行注释注释，但实际上需要CRM0_READ_RFC_DEST，因为在连接到外部系统之前，有一些属性是必需的。例如，FM检查加载类型、下载类型等，因此需要进行抽象，以便在这种情况下，您可以根据功能选择目的地。考虑到需要根据RFC目的地（SM59）中无法存储的属性从几个RFC目的地中选择一个，我可能会采用相同的方法进行处理。因此，据我所知，SolMan将所有三个主机名sysid、sysnr存储在一个表中，通过

STRUST

自动创建RFC目的地。因此，关于OP问题，我知道您也建议创建一个自定义表。对于抽象/别名，表

SSM\u RFC

和

/UI2/SYSALIASMAP

也可用。一个用例中的更多信息是将SAP_CRM（或类似的通用别名）映射到D、Q、P中的特定实例。这与Gateway或旧门户中的做法非常相似。知道并提到BD97的人+1当然，如果目的地是注册的外部程序，我们有一个不同的游戏。但在我看来，这也是BD64/BD97逻辑系统/标准目标类型的问题。