Watch it at Pluralsight
In the first part, we already built a ProjectRanker app for iOS Tablet and Android Smartphone. Now, I’ll show you how to change our current solution for using more tools but less code without affecting the user experience.
First, I am going to show you a second architecture as an alternative to our first approach. This architecture uses more tools proposed by SAP for reducing the need of custom development in connecting your SAP landscape to mobile devices. This course enables you to evaluate SAP tools through the example of the ProjectRanker project.
I discuss the following technologies in the course:
- I will show you how to prepare SAP Business Warehouse as a backend system for mobile projects.
- You will be able to answer questions why to use OData and how to introduce it in SAP mobile projects.
You will have a general understanding about the role of the SAP Netweaver Gateway that revolutionize the SAP backend systems for mobile communications.
I will be also answering why SAP recommends the SAP Mobile Platform and how it fits into this big picture.
Last year, Xamarin and SAP announced their partnership and SAP SDK for SAP Mobile Platform was born. You will see, how can we change an already working Xamarin solution by replacing the job of data collection to SAP SDK without having any side effects on the user experience.
You will see many examples and a ready-to-use app that works with SAP backend systems, so you will get a picture about the implementation details of such a project.
Who is this course for?
This course covers many tools and technologies from SAP and Xamarin. Please take this course as a journey that gives you an insight about the opportunities for SAP mobile projects implemented with Xamarin.
I highly recommend this course for
- SAP mobile project members who need a general understanding how the different pieces fit together.
- SAP professionals of SAP backend systems who want to benefit from the recommended architecture in the course.
- C# developers
who want to understand how SAP SDK works with the backend systems.
I hope this course helps you find orientation and gives information for your SAP mobile projects.
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.
SAP Netweaver Gateway
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
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.