Rob's SAP Integration musings: ODBC on Linux Power workaround Pt 1

A few years ago while working on an SAP CRM Social Services implementation we had an opportunity to work with one of the developers from the SAP Social Services development team on a particularly (read needlessly) obfuscated functionality of the system that was giving us problems. I remember asking him which other languages he programmed in and he replied "I only program in ABAP, all other programming languages are the devil's work!" (I swear it was quite funny in a thick German accent ?? )

I was reminded of this retort recently when we ran into a problem at one of our clients which required dusting off my trusted C# hat and devise a workaround to an annoying integration issue. The general requirement was to integrate SAP MM and SD with a third party POS system. Users who have worked with both SAP SD and any traditional POS system will unanimously agree that the SD sales order process makes you jump through a lot of hoops to perform what should ideally be a quick process (in implementations where you don't have the luxury of SAP IS-Retail POS). Since our client had such a scenario there was need to interface SAP MM and SD with the third party POS system and exchange Stocks and Sales data.

Sounds simple enough right? Not so much. Parameter number one was that the integration was to be between SAP and the POS SQL Server database. If we were integrating at Application level then our options would have been many and varied (RFC, webservices etc) but since on the POS side there was only a database it meant we had to connect to the SQL database from ABAP and execute Native SQL queries for the data transfer. Again this is simple right? Simply make use of ADBC through a DBCO connection to the external SQL Server instance and within minutes you're connected.

When doing SAP integration it's important to make sure that your Basis team is also aware of whatever approach you opt to use because they will be able to tell you what is and what isn't supported in the particular system landscape you have to work in. Lesson learnt. The hard way. So at one end I developed the necessary ABAP framework for retrieving the required data, using a DBCO connection and executing the queries to persist that data into a SQL Server DB. The final step was to now have the actual DBCO connection created for use by my ABAP program. Now this is where all hell broke loose...

For an ABAP program to use ADBC to connect to SQL Server it needs a DBCO connection to that remote SQL Server. That all important DBCO connection works if and only if the Microsoft ODBC Driver for SQL Server is installed on the SAP Application Server. Microsoft have developed versions of that driver for various operating systems (Windows, of course, Mac and CERTAIN versions of Linux). In our case the Application Server was installed on Linux on IBM Power architecture; an architecture which as of the time of writing this article was not yet supported. All that work done in blind faith that there would be a DBCO connection as the final link; NOT SUPPORTED!

My task then was to now find an alternative way of facilitating this integration in the absence of SAP PI/PO within the exact same architectural parameters. To borrow from the legal world, if party A and party B are in dispute it is possible to engage a trusted party C to act as a mediator/ arbitrator to resolve the dispute. Applying this analogy to our problem it meant that since SAP and the POS database were having an architectural dispute, there was a need to bring in an arbitrator to act as a data broker between the two systems. This superhero arbitrator can be written in any language as long as its able to communicate with both SQL on Windows and SAP on Linux Power. 

In my case I chose to employ C# using the SAP .Net Connector 3.0 to develop a windows service which connects to SAP, executes custom data retrieval BAPIs (RFC enabled function modules) to get the required data and then use Entity Framework 6 to connect to SQL Server and persist the data. This way there are no restrictions on the OS versions and the integration is achieved without having to alter the system landscape.

In Part 2 of this article I will outline the actual coding of the SAP BAPIs and C# windows service for the solution we chose.