iPAD App for SAP without Middleware

[Former Member]

Hi experts,

I am new about mobility topics and I am involved in a new project that consists in developing iPAD apps using data from SAP ECC and saved into the tablet.

In my business scenario there will be about 1.000 users that need to synchronize data from SAP ECC with the following characteristics:

Volumes

Basically there are 2 type of data to store into the iPAD:

Clients assigned in Portfolio (about 1500 clients per User to download)

Static data (i.e. configuration table/parameter)

Let's assume that the size of data exchanged is about 3 Megabyte

Frequency

The initial upload has to be made once a year and thereafter once a day it should be checked for updates

At the very present time we are supposing to use web services calling SAP ECC in order to retrieve and store data.Is there any particular drawback in doing it without a Middleware?

I have heard about Sybase, but I cannot find the real advantage since it seems to be another database where data can be replicated into it. As for the device management console, my client is adopting yet AirWatch.

I have also heard about SAP Netweaver Gateway but I cannot catch the real advantage into using it.

Thanks

E.

[Former Member · Accepted solution]

Hallo,

you can have a look to the Application ISEC7 Mobility for SAP. You can find the Application in the APP Stor or Google Store or Blackberry Store under the name "Mobility for SAP". The hole IMplemention is in ABAP.

www.isec7.com

best regards

Stephan

[koehntopp]

Hi Emanuele,

this is the kind of requirement that SUP is made for.

There are different areas where you can benefit by SUP/Gateway.

SUP will make it extremely easy to

• identify and expose the ERP tables & services to the mobile channel
• manage caching & exchanging data between iPad & ERP (people might change data when they're not online)
• manage the devices (what happens if one of the iPads gets lost or stolen?)
• extend the solution to another device (Android, Blackberry?)

It will also make sure exposing the services does not expose your ERP system to the outside accidentally.

• Only required services are being exposed to the outside
• Only registered devices with authenticated users can connect with ERP
• All communication is encrypted
• All data stored on the device is stored encrypted and protected

Of course it's "just software" and all of that can be implemented otherwise, but the investment will pay off once you start doing more than one mobile application.

Frank.

[Former Member]

Hi,

some other little questions about Gateway.

1.

Let's suppose we have 2 developers. The first is an expert XCODE developer and the second an SAP developer skilled in SOAP Web Services.

We want to create a Rest Web Services thaat retrieve data to be stored into the iPAD and used by a new App.

The SAP developer i supposed to learn how to use Gateway or it is a "technic configuration" made once for all?

How is supposed to use gateway, the SAP developing the Rest WS or the XCODE developer thata has to call that web service?

2.

I think that if I have only to retrieve data from SAP, Gateway could be sufficient. I do not understand how (and if) DOE (Data orchestration engine) is related to gateway and if in general netweaver support the creation of a data model suite for the data to be replicated and if it can be used to manage "delta" syncroniziation with the ipad. In other words, is Gateway a middleware too, like SUP, even though communicating only with SAP modules/platform?

Thank you in advance.

E,

[Former Member]

Hi,

1. The SAP developer will have to use Gateway to generate the REST Web Services. It's not difficult at all especially if the SAP developer already knows how to generate SOAP Web Services using the tools provided on an ABAP system. The iPhone developer will then have to write the iPhone client application to consume these Web Services. The generated Web Services are like any other REST Web Services and the iPhone developer doesn't need to have any SAP knowledge. This is the main value of Gateway : you don't have to be a SAP developer to use the generated Web Services.

2. Gateway is a framework that provides tools to help generate Web Services that can easily be consumed by a non SAP application written by a non SAP developer. SUP is a middleware which provides development tools to generate mobile apps, client APIs for iPhone/BlackBerry/Windows Mobile, a synchronization engine etc.

Regards,

Pierre

[Former Member]

Hi Pierre,

thank you for the answer.

Keeping in mind that I am not a developer profile, I ask you to help me understand the main capabilities of Gateway or SUP and what are the risks I run by using SOAP Web Services.

Quick answer:

1 - Why is it useful to have a middleware (i.e. another Database with data replicated), instead of quering directly SAP ECC? Is it only to avoid to call tha back-end system or what else?

2 - What are the difference between a REST Web Service and a SOAP Web Service (I know only the second type).

3 - Considering that the client has Netweaver 7.0 and Gateway standalone and that, overall, it appears skeptical with SUP . I think that Gateway is the maximum we can aim to. What are the high level steps to configure Gateway? What are the main advantage in using Gateway since, I suppose, it is not a middleware? Or I am wrong?

Basically I have undertsood that I can also start with SOAP WS and then, if client appreciate mobile device, pass to a more complex architecture using Gateway or SUP. In that scenario SOAP web services will be in somewhat way re-usable?

Thanks in advance

[Former Member]

Hi,

1. As I said a middleware can be very useful when you start having multiple backends and multiple apps. Let's say your mobile application needs to get data from your SAP CRM and SAP BI system and from another legacy system. Instead of having to make multiple calls to each system, the middleware could connect to the systems and replicate the data. Then your mobile application would only need to make a single call to get the data from the middleware. This is just an example.

2. REST Web Services are much more lightweight than SOAP Web Services and this becomes really interesting in a mobile scenario when you need to optimize everything to avoid draining the battery or exchanging too much information over the wireless network.

3. Gateway is a framework that will ease the development process and will allow you to quicly create REST Web Services.

I wouldn't use SOAP Web Services for a mobile application, even for a POC or for my first application.

I cannot explain all the benefits of these products in a single forum message. There are lots of resources related to Gateway and SUP, please read them to get a better understanding of what SUP and Gateway are : [Sybase Unwired Platform - An Introduction (Part 1) |http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/19385] [original link is broken] [original link is broken]; and [Getting Started with SAP NetWeaver Gateway|http://www.sdn.sap.com/irj/sdn/gateway?rid=/webcontent/uuid/1093f76f-e35b-2e10-61ba-a67b6dc089d5]

Regards,

Pierre

[Former Member]

Hi Emanuele,

In your case, SUP would provide the development tools, framework and APIs to easily handle the authentication, synchronization etc. You wouldn't need to define your own synchronization mechanism, it's in the product. Now if the updates are only sent from the server to the mobile devices, this shouldn't be to difficult to handle even without SUP.

You could easily create REST Web Services using Gateway and then consume them using the mobile devices. You don't want to consume SOAP Web Services using a mobile application, trust me. You could do this using the ICF (Internet Communication Framework) to achieve this but again it would be easier with Gateway.

You don't necessarily need SUP or Gateway to create only a simple mobile application. But then if your customer is happy with their first mobile application, they'll want more. And then products such as SUP or Gateway can make the difference. These products prodvide a standard development environment, tools to manage the apps and the users etc. With multiple mobile apps connected to multiple back-ends with more and more users, you'll need a middleware to manage all this and make sure the performance is great.

Usually people don't use SUP or Gateway for their first mobile application but then they start to see the benefits of mobility and they want more. And then they start to realize the benefits of these products and they understand that a real mobile strategy has to be defined etc.

Regards,

Pierre