这可能是一个比较模糊的问题,但现实生活就是这样。
我们公司正在推出SAP系统。我知道现在他们做Web Services,所以我们可以同时推出.NET,对于我们知道可以用C#完成的任何事情。
在SAP - .NET集成的过程中有哪些陷阱?我知道SAP的逻辑与“标准”编程有很大不同,但我希望将“业务”部分与“展示”部分分开,以便在ASP.NET中编写。
这可能是一个比较模糊的问题,但现实生活就是这样。
我们公司正在推出SAP系统。我知道现在他们做Web Services,所以我们可以同时推出.NET,对于我们知道可以用C#完成的任何事情。
在SAP - .NET集成的过程中有哪些陷阱?我知道SAP的逻辑与“标准”编程有很大不同,但我希望将“业务”部分与“展示”部分分开,以便在ASP.NET中编写。
我是一名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中完成。报告本质上就是丑陋的,而SAP在这方面做得非常好。我考虑的是那些不是用户主要工作的小应用程序。像报销、管理批准采购请求等等。 至于在哪里可以找到有关这些路障的材料。你找不到。你必须首先用自己的头脑找到它们。
不要抵制它。如果你正在实施SAP,就只需实施SAP即可。与其费力反抗,这几乎是不值得的。
如果你不喜欢GUI,SAP有工具来处理展示(BSPs、WDJ、WDA)。除非你非常需要,否则我不会尝试实现第三方前端。
考虑使用.NET的原因:
我参与了许多.NET / SAP的实现。一方面,我建议不要使用.NET,而是直接在ABAP中编写所需内容,但另一方面,它可以相当好地发挥作用。正如某人上面提到的,Web服务的开销对于小交易来说可能很高,因此尽量设置事物以便一次传递大量数据(即整个屏幕)。这样做也意味着SAP可以在内部处理整个事务或更多,并且无需一次处理少量内容并必须处理状态。业务逻辑应在SAP中实现,.NET部分仅处理数据的展示/交换。
我赞同关于“费用”接口所说的内容。大多数人都会使用另一个供应商的软件在外部处理它,但您不必使用复杂的实时.NET工具来导入费用数据,只需有一个简单的批处理作业每天导入即可。有时,最简单的方法是最好的。