SAP and Xamarin

If we want to connect our SAP data to mobile platforms we need to plan our interface carefully. Now, I am going to discuss the mobile integration options and my preferences for SAP Business Warehouse. SAP Business Warehouse is SAP's main backend system for reporting and until now it was not easy at all to connect the main reporting objects, BW queries to mobile. Although we can create BW queries very fast and they are very easy to use, the result behind the scenes is not so simple as we think. A BW Query is not directly connected to the underlying database but it's a logic generated with ABAP and consuming its interface is heavy for mobile scenarios. For many years, we could access and run BW Queries only with OLE DB for OLAP that allowed us to run MDX on the top of XML for Analyses interface so we had to write MDX and the resulting structure was an in-memory infocube instead of a simple table that is quiet challenging to convert to a simple table.

If you look at the screenshot from the Query Designer, you can see that from SAP BW verison 7.3 on we can use Easy Query with SOAP and ODATA that are optimized for mobile devices. In a short period of time we got 2 possible approaches for mobile integration, that is very good, but which method is the best one ? I think it’s worth to analyze the context and driving factors that help us to decide which approach is appropriate for us.

I have collected some characteristics that we can compare and that helped me to set my preference of choice between the 2 mobile options.

The main driving factor of our choice is the existence of SAP Netweaver Gateway. Easy Query with SOAP doesn’t need any additional components installed for your default SAP Business Warehouse setup, you can use this approach immediately. If you want to use ODATA, you need to add SAP Netweaver Gateway to your system landscape.

Compared to other interface approaches, both Easy Query and ODATA are for lightweight, mobile consumption. Both approaches support simple BW queries to lightweight consumption providing a simple table interface. This is a great benefit because it’s not easy to read BW queries since they are generated ABAP programs at the back end side working on a star schema and not on a single table. Easy Query and ODATA do the hard job of converting a complex database schema to a simple table.

If we take a look at the Query Features, we can see a big difference: Query Features like “Sorting, Filtering, conditions, paging” are not supported by Easy Query with SOAP. The chance that you need to write custom Function Modules in ABAP is much higher, because you might need to create a simple TOP list for example. So using Easy Query might result in higher development cost compared to ODATA. ODATA supports all of these features out-of-the-box so the chance you need to write custom logic is very low.

Service maintenance cost is also higher with the Easy Query with SOAP, because we need to generate and maintain the SOAP service manually on the top of our custom function module, but the ODATA approach generates the necessary models for our service we need only to publish the generated service.

So to sum up my analyses, if you have SAP Netweaver Gateway or you can install it, I recommend using ODATA, otherwise use Easy Query and Custom Function Modules.