.net/sap 混合系统有意义吗？

Question

这可能是一个有点模糊的问题，但现实生活就是这样。

我们公司正在推出SAP系统。 我知道他们现在做 Web 服务，所以我们可以同时推出 .NET 的东西，我们知道我们可以用 C# 做任何事情。

SAP - .NET 集成过程中的陷阱是什么？ 我知道SAP的逻辑与“标准”编程有很大不同，但我希望将“业务”部分与“演示”部分分开，用ASP.NET编写。

Answer 1

我是一名 SAP ABAP 和 Microsoft.NET 开发人员。 我在一家使用 SAP 和其他平台（例如 Microsoft.NET、Java 和 RoR）创建软件的公司工作。

由于您的公司正在推出 SAP，您应该获得 ECC 6.0 后端，它可以使用 RFC 或 Web 服务。

SAP 有一个标准 API，称为业务 API（又名 BAPI）。 您可以在 BAPI 交易中试用它们。

一个很好的例子是： BAPI_USER_GET_DETAIL 。

此 BAPI 负责返回有关任何 SAP 用户的信息。 BAPI 只需要一个名为 USERNAME 的输入参数，并返回包含有关用户信息的不同数据结构，例如电子邮件、名字和姓氏、用户配置文件等。

在 ABAP 内部，调用这个 BAPI 的模板应该是这样的：

CALL FUNCTION 'BAPI_USER_GET_DETAIL'
EXPORTING
USERNAME = sy-UNAME
* IMPORTING
* LOGONDATA =
* DEFAULTS =
ADDRESS = L_IT_RETURN1
* COMPANY =
* SNC =
* REF_USER =
* ALIAS =
* UCLASS =
* LASTMODIFIED =
* ISLOCKED =
TABLES
* PARAMETER =
* PROFILES =
* ACTIVITYGROUPS =
RETURN = L_IT_RETURN
ADDTEL = i_Tel
* ADDFAX =
* ADDTTX =
* ADDTLX =
* ADDSMTP =
* ADDRML =
* ADDX400 =
* ADDRFC =
* ADDPRT =
* ADDSSF =
* ADDURI =
* ADDPAG =
* ADDCOMREM =
* PARAMETER1 =
* GROUPS =
* UCLASSSYS =
* EXTIDHEAD =
* EXTIDPART =
* SYSTEMS =.

现在，每个 BAPI 也启用了 RFC（远程函数调用）。 这意味着，如果您在应用程序中实现 SAP RFC API，则可以调用 SAP 中设置为启用 RFC 的任何 BAPI 或其他函数。

在旧版本中，您可以使用标准 SAP RFC API，或使用 SAP 向导连接器，如 SAP .NET 连接器或 SAP Java 连接器。

在较新的版本中，SAP 已将 Web 服务器附加到其 ABAP 应用程序服务器，以便为 ABAP 运行 ITS、BSP 和 WebDynpro 等服务。 通过使用此 Web 服务器，您可以将任何 RFC 发布为 WebService。

但是，从我的日常经验来看，SAP R/3 的性能并不是那么好。 对两个数字求和并返回结果的函数的简单 RFC 调用可能需要 1 到 5 秒，具体取决于服务器的可用性。

发生这种情况的主要原因是在使用 SAP .NET 连接器或 Web 服务时碰巧遇到了许多抽象级别。

因此，如果您希望您的系统可用于日常交易（例如每天从您的电子商务应用程序创建 5.000 个客户，或在线销售大约 40.000 个），我强烈建议您使用 Java Connector，或通过以下方式实现 RFC API你自己。

否则，如果您的应用程序在内部被较少人使用，我建议您使用 SAP .NET 连接器或 WebServices，因为它们完全面向 GTD。

希望这可以帮助！

（请在下面的链接中添加 http:// 前缀，因为我没有足够的声誉来发布链接:(）

RFC API：help.sap.com/printdocu/core/Print46c/EN/data/pdf/BCFESDE4/BCFESDE4.pdf

SAP .NET 连接器：help.sap.com/saphelp_nw04/Helpdata/EN/e9/23c80d66d08c4c8c044a3ea11ca90f/content.htm

SAP Java 连接器：help.sap.com/saphelp_nw04/helpdata/en/6f/1bd5c6a85b11d6b28500508b5d5211/content.htm

使用 ABAP 创建 Web 服务：wiki.sdn.sap.com/wiki/display/stage/Service+Enabling+in+ABAP

Answer 2

如果您的应用程序不需要 SAP Portal 集成，并且您的客户不需要类似 SAP 的外观和感觉，那么您可以随意使用您喜欢的任何表示层。

我不同意在您选择进行 SAP 集成时必须使用 sap 工具的立场。 像 NWDI 或旧的 NWDS 这样的产品显然是一个令人头疼的问题（我不会在这里详细说明，这是一个很长的故事），如果您不是 100% 专门的 sap 集成商，那么培训人们学习 Webdynpro 在我看来是不值得的。

Answer 3

很少有一般性建议。

• 在我看来，您正在寻找一些“黄金之路”或类似的东西。 忘了它。 萨普兰没有什么是简单的，直接的，或者，好吧，正常的。 每个方向都有障碍和陷阱。 但不要绝望。 痛苦平息后，sap 会出色地完成它的事业（无论它是什么）。
• 对于核心 sap 用户（处理财务、人力资源、库存等的用户），您将不得不选择 sap 提供的服务。 gui 会很糟糕，但人们的适应能力惊人。 如果他们没有其他选择，他们会越来越喜欢 sap 所提供的东西。
• 对于临时用户（例如费用报告），使用 sap 作为 gui（网络或桌面 sapgui）提供的内容进行操作是一种资源浪费。 用户将找到避免这些应用程序的创新方法。 So.net 是要走的路。 你会遇到很多问题。 但请记住，另一种选择更糟。

回复评论：首先，我认为报告不应该在 sap 中完成。 报告本质上是丑陋的，而 sap 在其中表现出色。 我在考虑不是用户主要工作的小应用程序。 诸如报告费用、管理层批准采购请求等。 关于您在哪里可以找到有关上述路障的材料。 你不能。 你必须先用你的脑袋找到它们。

Answer 4

不要打它。 如果您正在实施 SAP，只需实施 SAP。 几乎可以保证不值得为它而烦恼。

如果您不喜欢 GUI（BSP、WDJ、WDA），SAP 有处理演示的工具。 除非您真的必须这样做，否则我不会尝试实施 3rd 方前端。

Answer 5

好好想想使用 .NET 背后的原因：

• 不要仅仅使用 .NET，因为你知道你可以这样做，这不是一个很好的理由，但如果使用 .NET 有正当的商业理由，那就去做吧
• 始终如一。 定义表示层何时必须是 .NET 以及何时不合适。
• 不要试图通过强迫 SAP 标准功能以不同于其意图的方式运行来“智取”SAP 标准功能。 （我不是说不要定制 - 我是说使用 SAP 首选选项，如增强、用户退出等，您将获得更好的产品和更好的 SAP 支持。如果不尝试了解产品，您就无法实施 SAP完全）
• 了解用户/客户的需求并不需要“只有一条规则”，仅仅因为您将 .NET 用于面向客户的网站并不意味着您不能将业务对象用于管理报告或简单的 ALV用于大部分报告的网格
• WEB Dynpro 对于 ABAP 开发人员来说并不难学习，如果您必须从 SAP 空间之外培训开发人员，WEB Dynpro 将是学习曲线中最少的。 SAP 业务逻辑要困难得多，如何在不破坏核心的情况下以受支持的方式重用 SAP 标准比学习 ABAP 工具集更具挑战性。

Answer 6

在我的公司，我们处于同样的情况。 我们正在使用 .NET 与 SAP 进行集成项目

您可以通过直接从 .NET 执行 BAPI 函数来避免使用 Web 服务。 今天我了解到标准 RFC 函数也可以作为 BAPI 函数公开。

我们正在使用 theobald 软件中的ERP Connect直接执行 bapi/RFC 功能，由于在本讨论中未提及，我认为您可能会受益于了解。

它不是免费的，但我认为它会让开发人员的生活更轻松。

请注意，我与 theobald 软件没有任何关联。

Answer 7

我参与了许多 .NET/SAP 实现。 一方面，我建议不要使用 .NET 而不是只在 ABAP 中编写您想要的内容，但另一方面，它可以运行得相当好。 正如上面提到的，对于小型事务，Web 服务的开销可能很高，因此请尝试进行设置，以便一次传递相当数量的数据（即整个屏幕充满）。 这样做也意味着 SAP 可以在内部处理整个事务或更多事务，而不是一次传递少量内容并且必须处理状态。 业务逻辑应该在 SAP 内部实现，.NET 部分只处理数据的表示/交换。

我将讨论关于费用界面的内容。 大多数人都使用其他供应商的软件在外部执行此操作，但您不必使用花哨的实时 .NET 内容来导入费用数据，只需每天导入一次简单的批处理作业即可。 有时最简单的方法就是最好的。