混合的.NET/SAP系统有意义吗?

如果您的应用程序不需要SAP门户集成,并且您的客户也不要求像SAP那样的外观和感觉,那么您可以自由使用您喜欢的任何表示层。

我不同意在选择进行SAP集成时必须使用SAP工具的观点。像nwdi或旧nwds这样的产品是一个明显的头疼问题(我不会在这里详细说明,这是一个很长的故事),如果您不是一个100%专注的SAP集成商,我认为培训人员学习WebdynPro是不值得的。

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

由于您的公司正在开发SAP,您应该获得ECC6.0后端,它可以使用RFC或WebServices。

SAP有一个称为业务API(即BAPI)的标准API。您可以在BAPI事务中尝试它们。

一个很好的例子是: BAPI_USER_GET_DETAIL .

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

在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在其ABAP应用服务器上附加了一个Web服务器,以便运行ITS、BSP和WebDynPro for ABAP等服务。通过使用此Web服务器,您可以将任何RFC发布为Web服务。

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

这主要是因为当您使用SAP.NET连接器或WebServices时,会发生许多级别的抽象。

所以,如果你想让你的系统能够日常事务(比如每天从你的电子商务应用中创建5个客户,或者在线销售大约40个),我强烈建议你使用Java连接器,或者自己来实现RFC API。

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

希望这有帮助!

(请在下面的链接中添加http://prefix,因为我没有足够的信誉发布链接:()

RFCAPI:help.sap.com/printdocu/core/print46c/en/data/pdf/bcfesde4/bcfesde4.pdf

SAP.NET连接器:help.sap.com/sap help nw04/helpdata/en/e9/23c80d66d08c4c8c044a3ea11ca90f/content.htm

SAP Java连接器:Apple .SAP.COM/SAPPLANDSNW04/HeldDaa/En/6F/1BD5C6A85 B11D6B25500 508B5D5211/CONTEN.HTM

使用abap:wiki.sdn.sap.com/wiki/display/stage/service+enabling+in+abap创建Web服务

别打了。如果您正在实施SAP,只需实施SAP即可。几乎可以肯定的是,不值得为之付出那么多的努力。

如果您不喜欢图形用户界面(BSPS、WDJ、WDA),SAP有工具来处理演示。我不会尝试实施第三方前端,除非你真的需要。

一般性的建议很少。

• 在我看来,你在寻找一些“黄金之路”或类似的东西。算了吧。在萨普兰,没有什么是简单的,直接的,或者,嗯,正常的。每个方向都有路障和陷阱。但不要绝望。痛苦平息后,SAP的进取心(无论是什么)表现得非常出色。
• 对于核心SAP用户(负责财务、人力资源、库存等事务的用户),您必须遵循SAP提供的服务。图形用户界面将是可怕的,但人们的适应性是惊人的。如果他们没有其他选择,他们会爱上SAP的产品。
• 对于临时用户(例如开支报告),使用SAP提供的图形用户界面(Web或桌面sap gui)进行操作是浪费资源。用户将找到避免这些应用程序的创新方法。所以.net是一条必经之路。你会遇到很多问题。但请记住,另一个选择更糟。

评论回复: 首先,我不认为报告不应该在SAP中完成。报告本质上是丑陋的,SAP在其中表现出色。我在想一些不是用户主要工作的小应用程序。如报告费用、管理层批准采购申请等。 关于在上述路障上哪里可以找到材料。你不能。你必须先用你的头找到它们。

好好想想使用.NET的原因:

• 不要只使用.NET 因为你知道你能做到 这不是一个很好的理由,但是如果使用.NET有一个有效的商业理由,那么就去做吧。
• 保持一致。定义表示层必须是.NET的时间和不合适的时间。
• 不要试图通过强迫SAP标准功能以不同的方式工作来“智取”它。(我不是说不要定制-我是说使用SAP预先提供的选项,如增强、用户退出等,您将获得更好的产品和更好的SAP支持。如果不完全理解该产品,就无法实施SAP)
• 你不需要“只有一条规则”来理解用户/客户的需求,仅仅因为你将.NET用于面向客户的网站并不意味着你不能将业务对象用于管理报告,也不能将简单的ALV网格用于大部分报告。
• 对于ABAP开发人员来说,Web Dynpro并不难学习,如果必须从SAP Space外部培训开发人员,Web Dynpro将是学习曲线中最少的一个。SAP业务逻辑非常困难,如何在不破坏核心的情况下以受支持的方式重用SAP标准比学习ABAP工具集更具挑战性。

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

我将接着介绍关于费用接口的内容。大多数人都是在外部使用另一个供应商的软件来实现这一点的,但您不必使用花哨的实时.NET工具来导入支出数据,只需做一个简单的批量作业,每天导入一次即可。有时最简单的方法是最好的。

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

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

我们正在使用 ERP连接 从Theobald软件直接执行BAPI/RFC功能,由于本讨论中没有提到它,我认为您可能会受益于了解。

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

请注意,我与Theobald软件没有任何关联。