Alternatives to SAP .NET Connector (for data import/export)

[Former Member]

Hi all,

Our company plans to integrate our product (based on MS .NET platform) with SAP. On the first stage it will be simple data import (materials, customers, etc.) and on the second stage also data export (e.g. pushing POs, etc. to SAP). As for now I found 3 technologies which seem rather suitable for the SAP/.NET integration:

1. SAP .NET Connector

2. 3d Party SAP/.NET Connectors (e.g. Librados)

3. Microsoft .NET Data Provider for mySAP Business Suite (part of Feature Pack for Microsoft SQL Server 2005)

Could you please advise me which of the technologies (maybe also some other options) is the best choice for data import/export?

[Former Member]

Slava

in addition to the answer from André I would like to state that the following Microsoft Technologies exist today to access (import/export) data from SAP Systems:

1) Microsoft .NET Data Provider for mySAP Business Suite

(use for mass amount of data, needs custom RFC installation on the SAP side, direct table access as well as object execution ), not certified today but in the process of certification

2) Microsoft .NET Data Provider for NetWeaver BI

Import and Export of BW content using the BW XMLA interface, certified and available with SQL Server SP1

3) BW Open Hub Services, (OHS) allows to import/export data to SQL

4) Web Services via WAS <= 6.20 (no transactional support, limited QoS and delivery once support but official supported and usable) we have a paper how to use this with Visual Studio

5) BizTalk Server and the free of charge BizTalk Server Adapter for mySAP Business Suite (supporting schema generation, serializition/deserialization, transcations, tracking, monitoring, management, mapping etc.). This is certified as well.

Please find many papers about the above options on msdn, sdn and www.microsoft-sap.com/interop.aspx

Kind regards

-Tilo

[Former Member]

Thank you Tilo for you detailed answer. Now we have the complete picture and can make the decision.

Best Regards,

Slava

[former_member192611]

Tilo,

for the sake of completeness I need to add a few comments from SAP's perspective, in particular for options 1) and 4) of your contribution:

re 1)

the .NET Data Provider comes with some modules that need to be installed on the SAP application server. These modules access data in the database circumventing official and supported APIs. The solution is unsupportable as SAP might change database schemas and internal functions at any point in time, even within a support pack or correction. Therefore SAP cannot recommend this approach. Option 2) and 3) are the better choice here.

re 4)

here you mention certain limitations regarding the web services approach, which are not entirely correct:

- BAPI-Transactions are supported using a cookies. You simply need to use a common CookieContainer for calls that belong to one transaction. Moreover the new ESA services are stateless and don't require a transaction bracket.

- QoS depends on the transport and the features that both sides can negotiate on. Until standards like WS-RM is supported by both - Microsoft and SAP - propriatary extensions like the XI QoS / "excatly once" can be used, but may require some extensions to the client side code.

...Thomas

[Former Member]

Allow me to add a few comments with regard to the .NET Data Provider and the ABAP modules it is utilizing. To properly read and interpret data from tables and views in the mySAP system, the provider makes use of data dictionary RFCs and tables that are delivered in the standard mySAP system. These are the same RFCs and tables that are used in standard SAP screens, such as the Table Browser or Data Dictionary tools.

We have tested the .NET Data Provider against the last three major releases of R/3 (4.6C, 4.7 and mySAP ERP) to ensure proper functionality of the component.

Should any of the underlying schemas or modules in the standard SAP system change, we are committed to providing a fix for our customers very quickly.

Christoph Schuler

Microsoft Office Business Applications

[tfxz]

Hi Tilo,

regarding your options 1 and 4: simply exporting data w/o the semantics translates into rebuilding those semantics in the system that receives the data. Consequently, all semantic (application) changes in mySAP Business Suite will require a synchronization, i.e. a model adaption, on the other side. This is a TCO nightmare and a major distinction to options 2 and 3.

There is a summary of risks associated with low level data access compiled for NW BI (aka BW) but most things generall yapply to approach described above:

http://service.sap.com/~sapidb/011000358700000819442003E/3rdparty_data_access.htm

And by the way: Microsoft has published a nice introduction to UDM that contains a nice motivation why low level data is not sufficient for reporting. Have look under http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/IntrotoUDM.asp

Regards

Thomas

[Former Member]

Hi Thomas,

I want to know what SAP thinks now about using the Microsoft BizTalk .NET Data Provider approach for accessing the database data directly.

Best regards,

Eric Hernandez Pardo

[Andre_Fischer]

Hi Slava,

Option 1. and 2. can be used.

Option 3. can only be used to extract data from SAP BI. It is not a certified interface by the way.

Depending on the SAP Release your company is using there are other options such as Web Services that can be used since every SAP NetWeaver Application Server starting from basis release 6.20 unwards is able to consume and provide web services.

Moreover it would be interesting to know which components of SAP NetWeaver your company is using (SAP XI ?).

So the answer can be more detailed if you describe what compents are used by your company.

Best regards,

Andre

[Former Member]

Andre, thanks for your answer.

Are you sure that "Microsoft .NET Data Provider for mySAP Business Suite" can be used only with SAP BI? From its manual (see also http://msdn2.microsoft.com/en-us/library/ms141761.aspx) I understood it can be used to call any RFC/BAPI.

Regarding SAP components: since we are an ISV (Independent software vendor) company which develops software not for a concrete but for multiple customers we would certainly like to make our application compatible with as many SAP installations as possible.

Best Regards,

Slava

[Former Member]

Slava,

have a look here: http://www.erpconnect.net/EC_EN/

./. Krishtan

[Former Member]

Thanks Krishtan, it seems what we need.