SAP ECC 6.0 - Using BAPIs for C# to extract data out

[MPGraziano]

I have had a client recommend a strategy of extracting data usin C# (Visual Studio 2005) to extract data from SAP ECC using BAPIs.

We do have an existing methodology in place using flat files to extract data to non SAP systems

We have purchase XI which we intend to implement next year.

I basically wanted to keep things tidy and continue with the flat file interface strategy just to keep things simple going forward to XI.

THen there is also the security piece, the developer has had to slowly build a profile / roles that alows him to come in thru visual studio to access these BAPIs

I am looking for anyone who has had experience with this and what your experiences are. As well, what are the SAP best practicies concerning this strategy

Thank YOU ALL who will reply

[Former Member · Accepted solution]

I think that SAP's strategy toward exposing BAPI is leaning toward leveraging their AS-JAVA stack. With the AS-JAVA Enterprise Services and standard delivered web content, SAP is already exposing many existing BAPI/Business Functionality outside of the ABAP world. However, that's not saying that traditional flat files have no place in the future. Matter of fact, I don't see flat/delimited files going away any time soon.

It all really comes down to what you are doing, you may even end up with a landscape that's a mix of files/RFCs. Here inhouse, we leverage file based transfers for large data sets such as SAP BI OHS extracts, and daily R/3 FI extracts. Why file? because it's simple, easy to control, and you can see the data being transferred. A file can be "hold in my hands" if you will, at best there's just a few characters in-flight.

As for RFCs, any type of RFCs in fact (Anything from sap .net connector to AS-JAVA ESOA Based ES), are basically designed for transactional data. Here, you are looking at things that are high in transactional count but small in individual size. Your client's call using C#, it all really depends on how you are doing it. MOST IMPORTANTLY: Make sure you are using a proven, standarized, and SAP supported way, PERIOD. NEVER EVER go into production with a "hack".

For the high-transactional-count-small-individual transactions, we leverage BizTalk Server (BTS) here. I'll be frank, we are not using BTS because we wrote it. We are using BTS because it just works better for us, in our environment. BTS now support SAP 2.0 connector (registered program ID) and SAP 3.0 (WCF based, direct SAP RFC call, supported by Microsoft AND SAP). We are leveraging these adapters and BTS (as distribution and transformation) in our environment more and more.

So, long story short: Determine the transaction type, multiple solutions is ok, make sure the solution is supported!