SAP and Xamarin

Watch our new Xamarin Training at Pluralsight


Building Native Mobile Apps for SAP Business Warehouse - Part 2



Watch it at Pluralsight

Introduction

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.

Challenges of Mobilizing SAP MM with Xamarin - Create Service in SAP Netweaver Gateway


Overview

In the previous post, we finished our last page, called Purchase Order Items Confirm. For the next few weeks, the plan is to implement the back-end features one-by-one, and in parallel we will link these features under our existing mobile app, SAP Goods Receipt. Today, I'm going to demonstrate you, how easy is to create a simple OData service within SAP Netweaver Gateway. Ready to go?

Then, let's get started!


Create New Project

Our first task is to create a new project in the transaction, SEGW by clicking on the highlighted button.


In the popup window, we are going to set a unique Project ID, a Description, and if you don't have any specific requirements, you can leave the rest of the properties as it was by default. At last, we need to assign it to a Package, or mark it as a Local Object.


Generate Project

In the next step, we are going to generate the project, namely generate the different helper classes, such as Model Provider Class, or Data Provider Class.


In the popup window, the system fills the different class names out automatically, so our task is only to approve them.


Register Service

In the next step, we are going to register our newly created service. In order to do this, first let's select a system (in my case the SAP ECC and SAP Netweaver Gateway is installed together, but it can differ in your case).

For the case, if you don't have any entry in the list, you can find the relevant settings under the following path: SPRO -> SAP NetWeaver -> Gateway Service Enablement -> Backend OData Channel -> Connection Settings to SAP NetWeaver Gateway -> SAP NetWeaver Gateway Setting.

At last, push the button, Register in order to register our service.


In the popup window, the system gives us a prefilled screen again, so we only need to assign a Package, or mark our service as a Local Object, and approve the settings.


If everything went fine, you should see the same green traffic light.


Test Your Service in Browser

Now our service is active and running, so there is nothing left, then Test it! In order to test it in the simplest way, let's click on the button, Maintain.


If you have more than one service, then let's select the one with the technical name, ZGOODSRECEIPT_SRV.


At the bottom side of the window, we can find the different testing tools: we can test it in simple browser or using the built-in Gateway Client (that is actually an OData client). For the sake of the simplicity, let's push the button, Call Browser that opens a browser up for us with the appropriate service URL.


We can go further and test it in a browser directly with the following service URL (please replace xxxx.xxxx.com corresponding to you system settings):

http://xxxx.xxxx.com/sap/opu/odata/sap/ZGOODSRECEIPT_SRV/$metadata

Since our service doesn't do anything (it's an empty service), we got the following results back:


Summary

Our service is up and running. It doesn't do anything, but from now on, we can simply use it to authenticate into our system.

Next, we are going to move back to our Xamarin mobile app, and try to call this service using the URL (http://xxxx.xxxx.com/sap/opu/odata/sap/ZGOODSRECEIPT_SRV/), to login into our system.

I hope, you could follow me, and everything went fine. If not, then don't hesitate to leave me a comment below!

Stay tuned, keep reading! If you want to get notification about the newest posts, follow us or subscribe to our newsletter! If you liked it, please share it! Thanks!

Challenges of Mobilizing SAP MM with Xamarin - Introduction


Introduction

Information Technology is constantly changing and evolving. In this rapid world of change, we can not afford to be idle, and wait for miracles. We must learn and be up-to-date in Information Technologies, and we must keep up-to-date our IT infrastructures as well. What we find effective and modern today, can be obsolete tomorrow, which may lead to miss future opportunities!

For example in the early days, "Warehouse Management" happened in simple checked notebooks, after the Industrial Revolution, storekeepers used check out systems with punch cards to keep up the pace with their competitors, followed by, they started using bar-coding and inventory management systems to make their tasks easier, precise and efficient, today, we use modern ERP systems to automatize and integrate everything with everything, besides this we use RFID to keep track and find our goods in our warehouses.

Moving Forward

To keep up the pace with you competitors, you must move forward and break away from your computers. If you like it or not, mobile apps are integral part of business by now. Today, many companies already use business apps in Field Service, Human Resource, Inventory, IT, and Customer Relationship Management.

Using business mobile apps, we are able to make our processes more transparent, and get real-time feedback from our colleagues that accelerates and improves our processes, and eliminates human errors.

Challenges of Mobilizing SAP MM with Xamarin - Introduction

At Experties Team, Laszlo and me have decided to share our experiences with you about integrating Xamarin mobile apps with SAP. For this, today we have launched a blog post series - Challenges of Mobilizing SAP MM with Xamarin -, where we are going to build a native Android and iOS app that is integrated with the standard SAP MM (Material Management). During this blog post series, we will give you insights into:

  • designing and building native Android & iOS mobile apps
  • providing and consuming SAP OData web services
  • caching and synchronizing data back and forth

If you are interested in this adventure, there is nothing to do, than to subscribe to our newsletter and follow our guides regularly on every weeks.

Stay tuned!

Lightweight Mobile Consumption of SAP BW


Overview

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.

Characteristics

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.

Mobile interface

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.

Query Features

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.

Conclusion

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.