我编写了许多 SAP RFC 应用程序。我相信 .Net 连接器与 Java 连接器一样位于其 RFC 协议之上。根据我的经验，最佳实践取决于您向 SAP 询问的人。他们确实有一个 Web 应用程序服务器（我认为现在它被称为 WebAS……它被重命名了几次），它可能可以托管 Web 服务，但这取决于您安装的内容。我认为许多人仍然选择 .Net 或 Java 连接器。 （我个人更喜欢 C++ 库，因为它相当快，但这仅适用于极其愚蠢的人；））
I've written many SAP RFC applications. I believe that the .Net connector sits on top of their RFC protocol as does the Java connector. In my experience, the best practice depends on who you ask at SAP. They do have a web application server (WebAS I think it is called these days....it was renamed a few times) that can probably host a web service, but it depends on what you have installed. I think many people opt for the .Net or Java connector still. (I prefer the C++ library personally since it is quite fast, but that is only for the extremely foolish ;) )
My information may be dated, but if they have been consistent then the RFC communication layer is not encrypted out of the box. There is a third party plugin that is used on SAP GUI and all RFC type connectors (.Net/JCo) to encrypt the data stream. You have to set it up in the rfc .ini file.
Then there are IDOCs, which I don't think you want to play with. It is a flat file format much like EDI but dumber.
About the security part, if you're using the equivalent of JCO with .Net, you have a user on the SAP backend to connect with.
This user should be of type "Connection" (so that no-one can use it with the SAPGUI), and should have authorizations that are limited to what is needed (so that no program can use it to perform others operations that you did not thought). While the chance that someone manage to get this user/password are low, you don't take chance with productive datas. Also, password should not be a simple one.
This may sound like basic security, but since i just found the exact opposite on a productive system, i prefer to state it.
发布评论
评论（2）
我编写了许多 SAP RFC 应用程序。我相信 .Net 连接器与 Java 连接器一样位于其 RFC 协议之上。根据我的经验，最佳实践取决于您向 SAP 询问的人。他们确实有一个 Web 应用程序服务器（我认为现在它被称为 WebAS……它被重命名了几次），它可能可以托管 Web 服务，但这取决于您安装的内容。我认为许多人仍然选择 .Net 或 Java 连接器。 （我个人更喜欢 C++ 库，因为它相当快，但这仅适用于极其愚蠢的人；））
我的信息可能已过时，但如果它们一致，则 RFC 通信层不会立即加密。 SAP GUI 和所有 RFC 类型连接器 (.Net/JCo) 上使用第三方插件来加密数据流。您必须在 rfc .ini 文件中进行设置。
然后是 IDOC，我认为您不想使用它。它是一种平面文件格式，很像 EDI，但更笨。
I've written many SAP RFC applications. I believe that the .Net connector sits on top of their RFC protocol as does the Java connector. In my experience, the best practice depends on who you ask at SAP. They do have a web application server (WebAS I think it is called these days....it was renamed a few times) that can probably host a web service, but it depends on what you have installed. I think many people opt for the .Net or Java connector still. (I prefer the C++ library personally since it is quite fast, but that is only for the extremely foolish ;) )
My information may be dated, but if they have been consistent then the RFC communication layer is not encrypted out of the box. There is a third party plugin that is used on SAP GUI and all RFC type connectors (.Net/JCo) to encrypt the data stream. You have to set it up in the rfc .ini file.
Then there are IDOCs, which I don't think you want to play with. It is a flat file format much like EDI but dumber.
关于安全部分，如果您在 .Net 中使用 JCO 的等效项，则 SAP 后端上有一个用户可以连接。
该用户应该是“连接”类型（以便任何人都不能将其与 SAPGUI 一起使用），并且应该具有仅限于所需内容的授权（以便任何程序都不能使用它来执行您未执行的其他操作）想法）。虽然某人设法获取此用户/密码的机会很低，但您不会冒险获取有效数据。另外，密码不应该是简单的。
这听起来像是基本的安全性，但由于我刚刚在生产系统上发现了完全相反的情况，所以我更愿意这么说。
问候
About the security part, if you're using the equivalent of JCO with .Net, you have a user on the SAP backend to connect with.
This user should be of type "Connection" (so that no-one can use it with the SAPGUI), and should have authorizations that are limited to what is needed (so that no program can use it to perform others operations that you did not thought). While the chance that someone manage to get this user/password are low, you don't take chance with productive datas. Also, password should not be a simple one.
This may sound like basic security, but since i just found the exact opposite on a productive system, i prefer to state it.
Regards