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.
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
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.
Few general advices.
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.
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.
Think well of the reasons behind using .NET:
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 from theobald software to execute bapi/RFC functions directly and since it not mentioned in this discussion, I thought you might benefit in knowing.直接执行 bapi/RFC 功能,由于在本讨论中未提及,我认为您可能会受益于了解。
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.
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 (ie 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.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.