当前位置： 文江博客话题详情

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

发布于 2024-08-05 05:26:32 字数 195 浏览 6 评论 0原文

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

我们公司正在推出SAP系统。我知道他们现在做 Web 服务，这样我们就可以同时推出 .NET 来完成我们知道可以用 C# 做的任何事情。

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

原文

This might be a bit vague question, but real life is like this.

Our company is rolling out SAP system. I know they now do Web Services so we could simultaneously roll out the .NET thing for anything we know we can do in C#.

What are the pitfalls along the way of SAP - .NET integration? I understand that SAP's logic is quite different from "standard" programming, but I hope to separate "business" part from "presentation" part, to be written in ASP.NET.

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（7）

清晨说晚安 2024-08-12 05:26:32

我是 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 Connector 或 SAP Java Connector。

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

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

发生这种情况的主要原因是，当您使用 SAP .NET Connector 或 WebServices 时，会出现许多抽象级别。

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

否则，如果您的应用程序将由较少的人在内部使用，我建议您使用 SAP .NET Connector 或 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/1bd5c6a85b11d6b2 8500508b5d5211/ content.htm

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

I'm a SAP ABAP and Microsoft.NET developer. I work for a company that creates software using SAP and other platforms, such as Microsoft.NET, Java and RoR.

Since your company is rolling out SAP, you should get the ECC 6.0 backend, which can use RFC or Webservices.

SAP has a standard API known as Business API's (aka BAPI's). You can try them out at BAPI transaction.

One good example is this: BAPI_USER_GET_DETAIL.

This BAPI is responsible for returning information about any SAP user. The BAPI requires only a single input parameter, called USERNAME, and returns different data structures with information about the user, such as e-mail, First and Last name, user profiles, etc.

Inside ABAP, a template for calling this BAPI should be something like this:

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 =.

Now, every BAPI is also RFC (Remote Function Call) enabled. This means that, if you implement the SAP RFC API inside your application, you can call any BAPI or other function inside SAP that is setup as RFC enabled.

In older versions, you could use the standard SAP RFC API, or use SAP Wizard Connectors, like SAP .NET Connector or SAP Java Connector.

On the newer versions, SAP has attached a webserver to it's ABAP Application Server, in order to run services such ITS, BSP and WebDynpro for ABAP. By using this webserver, you can publish any RFC as a WebService.

But, taken from my daily experience, the SAP R/3 performance isn't that good. A simple RFC call to a function that sum two numbers and returns the result may take from 1 to 5 seconds, depending on the avaliability of the server.

This happens mostly because of the many levels of abstraction that happens to get on the way when you are using SAP .NET Connector or WebServices.

So, if you want your system to be avaliable for daily transactions (such as creating 5.000 customers daily from your e-commerce application, or making about 40.000 sells online) I deeply recommend you to use Java Connector, or to implement the RFC API by your own.

Otherwise, if your app will be used internally by fewer people, I recommend you to use SAP .NET Connector or WebServices, just because they are completelly GTD oriented.

Hope this helps!

(please, add the http:// prefix to the links bellow, cause I don't have enough reputation to post links :( )

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

SAP .NET Connector: help.sap.com/saphelp_nw04/Helpdata/EN/e9/23c80d66d08c4c8c044a3ea11ca90f/content.htm

SAP Java Connector: help.sap.com/saphelp_nw04/helpdata/en/6f/1bd5c6a85b11d6b28500508b5d5211/content.htm

Creating WebServices using ABAP: wiki.sdn.sap.com/wiki/display/stage/Service+Enabling+in+ABAP

回复 原文
怪我太投入 2024-08-12 05:26:32

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

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

If your apps dont require SAP Portal integration and your clients dont ask for SAP-like look and feel then you are free to use whatever presentation layer you like.

I disagree with the stance that you have to use sap tools when you choose to do a SAP integration. Products like NWDI or old NWDS are a clear headache (im not gonna elaborate on that here, its a long story), training people to learn Webdynpro is in my opinion not worth the money if you arent a 100% dedicated sap integrator.

回复 原文
ㄖ落Θ余辉 2024-08-12 05:26:32

很少有一般性建议。

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

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

Few general advices.

  • It seems to me that you are looking for some "golden path" or something like that. Forget it. Nothing in sapland is easy, straight forward or, well, normal. There are roadblocks and pitfalls in every direction. But don't despair. After the pain settles, sap does its enterprisey(whatever it is) thing amazingly well.
  • For hard-core sap users ( users who handle finance, hr, inventory and such) you will have to go with what sap offers. The gui will be terrible, but people are amazingly adaptable. And if they don't have other options thay will grow to love what sap has to offer.
  • For casual users ( expense report, for example) doing it in what sap offers as gui ( web or desktop sapgui) is a waste of resources. Users will find innovative way to avoid those application. So.net is the way to go. You will encounter many problems. But remember that the other option is worse.

Response to comment:
First of all I don't think that reports shouldn't be done in sap. Reports are ugly by nature and sap excel in them. I was thinking of little applications that are not the main work of the users. Thing like reporting expenses, Management approving purchase request and so on.
About where can you find material on the said roadblocks. You can't. You have to find them with your head first.

回复 原文
大海や 2024-08-12 05:26:32

不要对抗它。如果您正在实施 SAP，就实施 SAP 即可。几乎可以肯定，不值得费力去对抗它。

如果您不喜欢 GUI（BSP、WDJ、WDA），SAP 提供了处理演示的工具。我不会尝试实现第三方前端，除非你真的真的必须这样做。

Don't fight it. If you're implementing SAP, just implement SAP. It's almost guaranteed not to be worth the trouble to fight it.

SAP has tools to handle the presentation if you don't like the GUI (BSPs, WDJ, WDA). I wouldn't try to implement a 3rd party front end unless you REALLY REALLY have to.

回复 原文
究竟谁懂我的在乎 2024-08-12 05:26:32

仔细考虑使用 .NET 背后的原因：

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

Think well of the reasons behind using .NET:

  • Don't just use .NET because you know you can do it that's not a good reason, but if there's a valid business reason for using .NET then go for it
  • Be consistent. Define when the presentation layer has to be .NET and when it's not appropriate.
  • Don't try to "outwit" SAP standard functionality by forcing it to behave in a different way that what it's meant to. (I'm not saying don't customise - I'm saying use the SAP preffered options like Enhancements, user Exits etc you'll get a better product and better SAP support. You can't implement SAP withouth attempting to understand the offering fully)
  • There isn't "just one rule" you need to understand the needs of your users/customers and just because you use .NET for a customer facing website doesn't mean you can't use business objects for management reporting or a simple ALV grid for the bulk of your reporting
  • WEB Dynpro isn't that hard to learn for an ABAP developer and if you have to train up developers from outside the SAP space WEB Dynpro will be the least of the learning curve. SAP business logic is a lot harder and how to reuse SAP standard in a supported way without breaking the core is more of a challenge than learning the ABAP toolset.
回复 原文
泪之魂 2024-08-12 05:26:32

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

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

I have been involved in a number of .NET / SAP implementations. On the one hand, I recommend against using .NET instead of just writing what you want in ABAP, but on the other hand, it can be made to work reasonably well. As someone mentioned above, the overhead for web services can be high for small transactions, so try to set things up so that a fair amount of data is passed at once (i.e. a whole screen full). Doing that also means that SAP can process an entire transaction or more internally, instead of passing small amounts of stuff at a time and having to handle the state. The business logic should be implemented inside SAP, with the .NET part only handling presentation/exchange of data.

I'll second what was said about the Expenses interface. Most everyone does that externally with another vendor's software, but you don't have to use fancy real-time .NET stuff to import expense data, just have a simple batch job that imports it once a day. Sometimes the simplest way is the best.

回复 原文
久光 2024-08-12 05:26:32

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

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

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

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

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

At my company we are in the same situation. We are carrying out integration projects with SAP using .NET

You can avoid avoid webservices by executing BAPI functions directly from .NET. Today I learned that standard RFC functions can be exposed as BAPI functions as well.

we are using ERP Connect from theobald software to execute bapi/RFC functions directly and since it not mentioned in this discussion, I thought you might benefit in knowing.

It is not free, but I think it will make a developers's life much easier.

Please note i am not affiliated in any way with theobald software.

回复 原文
~没有更多了~

关于作者

聽兲甴掵

暂无简介

0 文章
0 评论
22 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

1CH1MKgiKxn9p

文章 0 评论 0

ゞ记忆︶ㄣ

文章 0 评论 0

JackDx

文章 0 评论 0

信远

文章 0 评论 0

yaoduoduo1995

文章 0 评论 0

霞映澄塘

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文