SAP and Xamarin

None

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

20. May 2015 in ODATA by Alex Gönczy


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!

Lightweight Mobile Consumption of SAP BW

9. March 2015 in ODATA by László Mészáros


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.