Need to integrate SAP with .NET applications. Is .NET Connector the best choice? What about NetWeaver? Simply looking to push data to and pull data from SAP.
+4
A:
I haven't used the NetWeaver objects, so I can't say much about that, but I can say that the .Net connector does a pretty good job of proxying the SAP BAPIs for use in .Net. A few additional comments:
- Drawback - AFAIK, you're stuck with developing your proxies in VS2003
- Drawback - the documentation of the BAPIs is pretty slim. I spend a lot (I mean a lot) of time in SE37 inside SAP looking at the RFC documentation and stepping through the functions
- Positive - it took me a while to realize that you could rename and remove parameters and rename methods in VS2003 before building the proxy
- Drawback - if you do the above-mentioned renaming you need to redo it every time you repopulate the RFC from the SAP server (like if your SAP developer makes changes to a BAPI)
Overall, complicated functions are difficult with the .Net Connector (I just spent 3 weeks getting customer creation and modification working), but simple functions are pretty transparent, and if you have an ABAP developer available to you on the SAP side and can develop custom BAPIs it works really well.
cori
2008-09-16 22:45:07
+2
A:
SAP .Net Connector is okay but it only supports Visual Studio 2003, but they haven't updated it in a while.
There is another product called SAP Explorer and Proxy Generator that I've used to connect to SAP from VS2005. It uses version 1.1 of the SAP .Net Connector to do all the dirty work, so I copied and pasted the contents of the SAP .Net Connector 2.0 folder into the SAP Explorer folder to get it to use the newer version of the proxy libraries (this added support for case-sensitive passwords). I haven't tried it in VS2008 yet, but I suspect it will still work.
SAP Explorer is certainly a nice replacement for the SAP product, but it doesn't look like it's been updated recently.
X-Cubed
2008-09-16 22:51:11
That's pretty cool - is it worth the $$? Especially when it relies on the .Net connector anyway?
cori
2008-09-17 02:20:56
+2
A:
I understand that Web Services is the way to go to achieve Netweaver / .Net integration. This is why the .Net Connector has not been updated from VS2003 days.
We used this to great effect in our last venture, which saw a .Net 2.0 client connecting to custom SAP-CRM RFCs using Web Services.
Raithlin
2009-02-20 13:27:49
+1
A:
There's a new version available from the guys at Aconcagua IT, with better prices and more flexible options than other competitors.
Visual Studio 2008 and Visual Studio 2005 versions available: http://www.aconcaguait.com/explorerproxygen2008.php or
VS2008 version includes support for the latest librfc32.dll (password lenght, case-sensitive, etc.)
Worth a look.
Pedro de Mendoza
2009-09-23 15:30:43
A:
As written above, SAP proposes to go the SOA road, which means to use the SOAP tool chain instead of the RFC tool chain (.Net RFC connector, ...).
For .Net that means to use the WCF functionality and connect it with the SAP backend, hence using SOAP on both sides: find your business needs in one of the many SOA services delivered by SAP (ES Wiki on SDN) or create a service of your own and create the client side functionality based on the proxy generated from the services WSDL file via WCF's svcutil.
As a bonus, doing this is not dependent from any Visual Studio version, csc and svcutil on the command line is just enough.
Frank Bechmann
2009-10-06 09:58:54
A:
We have bought "SAP Explorer and Proxy Generator for VS 2008" and we have been disappointed, because this tool has not worked well. So far, we still await a solution to the problems (from Aconcagua). Unfortunately we had to re-generate proxies in VS2003 with the free version of the SAP Connector, and then use them in VS2008.
Mathews
2009-10-30 15:43:24
A:
Hey, check this step-by-step video!
http://www.youtube.com/watch?v=72nM-vuYfFI
A tutorial on how to create proxies using AIT tool...
Sarah Dow
2010-02-21 21:21:33