Does a mixed .net/sap system make sense?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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.