混合使用.NET/SAP系统是否有意义？

Question

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

我们公司正在推出SAP系统。我知道现在他们做Web Services，所以我们可以同时推出.NET，对于我们知道可以用C#完成的任何事情。

在SAP - .NET集成的过程中有哪些陷阱？我知道SAP的逻辑与“标准”编程有很大不同，但我希望将“业务”部分与“展示”部分分开，以便在ASP.NET中编写。

- ilya n.

Answer 1

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

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

SAP有一个称为Business API's（也称为BAPI's）的标准API。您可以在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，则可以调用设置为RFC启用的SAP中的任何BAPI或其他功能。

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

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

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

这主要是由于使用SAP .NET连接器或WebServices时发生的许多抽象层次所导致的。

因此，如果您希望系统对日常交易（例如从电子商务应用程序每天创建5,000个客户或在线销售约40,000次）可用，我强烈建议您使用Java连接器，或自己实现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

- Bruno Lucattelli

---

我赞同你的评论，尽管我不同意其中的一句话：“对一个简单的RFC函数调用来说，它将两个数字相加并返回结果可能需要1到5秒，这取决于服务器的可用性。” 如果出现这种情况，那么就有人在环境规模方面犯了错误，但我从未在任何客户端看到过这种情况。 - tomdemuyt

我发现客户端的初始调用通常会很缓慢，后续的调用则会快很多，因为连接已经建立。 - Gareth

Answer 2

如果您的应用程序不需要SAP门户集成，且您的客户不需要SAP般的外观和感觉，则可以自由选择任何表现层。我不同意如果您选择做SAP集成就必须使用SAP工具的立场。像NWDI或旧版NWDS等产品会带来明显的麻烦（我这里不会详细阐述，这是一个长故事），培训人员学习Webdynpro在我的看法中不值得花这些钱，除非您是一名100％专注于SAP集成的人。

- Stefan Ernst

---

太棒了，你有没有使用非SAP演示层的经验？有些人肯定会使用SAP本身，所以我有点担心要支持两个系统... - ilya n.

是的，我曾经是一名Java开发人员，从事该职业已有3年时间，直到我转向SAP开发。现在，我正在为各种客户开发100%的Webdynpro，甚至包括一些Webdynpro ABAP。让我说，这与基于Java的普通演示层有很大的区别。我曾经使用过Struts、JSF和纯JSP，但花费了相当长的时间才适应Webdynpro。由于我们销售完整的SAP解决方案，所有我们的应用程序都具有门户集成，Webdynpro是首选的演示层，因为它可以很好地与门户样式表和门户角色集成。 - Stefan Ernst

当然，另一个优点是当您使用非 SAP 表示层时，您可以自由选择任何应用服务器。但是我对 .NET 与 SAP 的集成了解不够，无法在此明确推荐。 - Stefan Ernst

顺便问一下，你是如何“掌握”SAP的业务部分的？您可不可以也看一下我的另一个问题：https://dev59.com/bEnSa4cB1Zd3GeqPOXw7 - ilya n.

像NWDI或旧版NWDS这样的产品真是让人头疼啊！+1000！仍然把它们当作噩梦回忆。 - Suncatcher

Answer 3

一些通用建议。

• 我认为你正在寻找某种“黄金路径”或类似的东西。忘了吧。SAP世界里没有什么是容易、直接或正常的。每个方向都有路障和陷阱。但不要绝望。痛苦过后，SAP会出色地完成其企业工作。
• 对于硬核的SAP用户（财务、人力资源、库存等），你必须使用SAP提供的内容。图形用户界面将很糟糕，但人们非常适应。如果他们没有其他选择，他们会喜欢SAP所提供的内容。
• 对于普通用户（例如费用报告），在SAP提供的GUI中（Web或桌面SAPGUI）执行是浪费资源的。用户会想出创新的方法来避免这些应用程序。.NET是正确的选择。你会遇到许多问题。但请记住，另一个选项更糟糕。

回复评论： 首先，我认为报告不应该在SAP中完成。报告本质上就是丑陋的，而SAP在这方面做得非常好。我考虑的是那些不是用户主要工作的小应用程序。像报销、管理批准采购请求等等。 至于在哪里可以找到有关这些路障的材料。你找不到。你必须首先用自己的头脑找到它们。

- Igal Serban

---

谢谢！我一直觉得报告最好不要用SAP来写。你觉得有什么我可以阅读的东西，了解一下可能遇到的问题和障碍吗？ - ilya n.

Answer 4

不要抵制它。如果你正在实施SAP，就只需实施SAP即可。与其费力反抗，这几乎是不值得的。

如果你不喜欢GUI，SAP有工具来处理展示（BSPs、WDJ、WDA）。除非你非常需要，否则我不会尝试实现第三方前端。

- Bryan Cain

---

我宁愿不去实现第三方前端，而是说服管理层购买另一个前端... - ilya n.

Answer 5

考虑使用.NET的原因：

• 不要仅仅因为你知道如何使用.NET就使用它，这并不是一个好的理由。但如果有有效的业务理由需要使用.NET，那么就去用吧。
• 保持一致性。定义在哪些情况下需要使用.NET作为表现层，哪些情况下不适合使用。
• 不要试图通过强制SAP标准功能以不同于其本意的方式运行来“智取”它。(我并不是说不要进行定制 - 我的意思是使用SAP首选选项，如增强、用户退出等，你将得到更好的产品和更好的SAP支持。你不能在不尝试充分了解其提供内容的情况下实施SAP)
• 没有"只有一个规则"，你需要了解你的用户/客户的需求。仅仅因为你在面向客户的网站上使用.NET并不意味着你不能在管理报告中使用业务对象或者在大部分报告中使用简单的ALV网格。
• 对于ABAP开发人员来说，WEB Dynpro并不难学习。如果你必须培训来自SAP领域之外的开发人员，那么WEB Dynpro将是最容易掌握的工具。SAP业务逻辑要难得多，如何在不破坏核心的情况下以受支持的方式重用SAP标准内容是一个更大的挑战，比学习ABAP工具集更具挑战性。

- Esti

Answer 6

我参与了许多.NET / SAP的实现。一方面，我建议不要使用.NET，而是直接在ABAP中编写所需内容，但另一方面，它可以相当好地发挥作用。正如某人上面提到的，Web服务的开销对于小交易来说可能很高，因此尽量设置事物以便一次传递大量数据（即整个屏幕）。这样做也意味着SAP可以在内部处理整个事务或更多，并且无需一次处理少量内容并必须处理状态。业务逻辑应在SAP中实现，.NET部分仅处理数据的展示/交换。

我赞同关于“费用”接口所说的内容。大多数人都会使用另一个供应商的软件在外部处理它，但您不必使用复杂的实时.NET工具来导入费用数据，只需有一个简单的批处理作业每天导入即可。有时，最简单的方法是最好的。

- Noah

Answer 7

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

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

我们正在使用theobald软件的ERP Connect直接执行bapi/RFC函数，因为它没有在这个讨论中提到，所以我想你可能会受益于知道这一点。

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

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

- Adrian Hedley