Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Disclaimer: Views expressed here are strictly personal and present only one approach for mobile app development using Sybase Unwired Platform (SUP)  and SAP NetWeaver Gateway (GW). Please consult with the SAP Integration and Certification Center (ICC) to learn more about other available integration scenarios.

This blog describes the integration scenario when developing mobile apps using GW 2.0 and SUP 2.1.

Sybase Unwired Platform is at the heart of SAP’s mobile strategy. It has seen tremendous growth and just recently, the company announced an impressive milestone as it hit the €500M mark in mobile pipeline with more than 350 new customers and 17.5 million total seats in 2011.

With the recent release of SUP 2.1, SAP and Sybase are promoting seamless integration and closer alignment of their technology stacks with the introduction of SAP NetWeaver Gateway integration. This new architecture of combining SUP and GW promises not only to ease but accelerate the development cycle of mobile apps and facilitate integration to the SAP back-end by exposing processes as easily consumable OData services. For mobile app developers who have experienced first-hand the challenges of interfacing with SAP back-end processes, this comes as a welcomed addition to an already impressive platform.

With such promises and encouraging claims, many are eager to jump onboard and be part of the burgeoning ecosystem which by SAP’s estimate, should contribute upwards of 80% to future SAP-related mobile app development.  As often the case with anything new, there’s some confusion on this new approach and many are wondering how it works and more precisely what this architecture translates to in terms of development effort when compared to the current main approach for integrating backend SAP processes with Mobile Business Objects (MBOs).  Certainly, there’s a lot of information on the respective websites of SUP and Gateway yet there is little information generally available on the integration of these two components (at the time of writing in January 2012).  This state of affairs combined with the launch of the Mobile App Certification for partners and ISVs by ICC has compelled me to shed some light on this new approach and share my experience.

In this blog, I will introduce mobile app development using SUP 2.1 and Gateway 2.0* by providing an overview of this architecture and more importantly, how to enable the integration between these two components.

*restricted to online native apps only, hybrid apps will not be discussed here.


First, let’s start with the basics. Prior knowledge of mobile app development using SUP is clearly indispensable in understanding the topics discussed here and how this new approach differs from current standards.  Before I proceed, I invite you to review some basic concepts of mobile app development with SUP (including MBO) and SAP NetWeaver Gateway (including OData) if you are not familiar with them. Here are a few links to help you get started on the right track.

If you’re new to developing on SUP altogether, there is a nice starter page on SDN compiled by Stan Stadelman, Product Manager for SUP:

To that, I would add the following compilation of resources:

In a nutshell, SUP is an integrated platform that enables mobile devices to access back-end enterprise data. Prior to version 2.1 of SUP, the primary development approach for creating native mobile apps with SUP to connect to SAP systems was through MBOs. MBOs encapsulate back-end business logic which is made accessible on mobile devices. When integrating to an SAP back-end, MBOs are usually derived from a BAPI (via WS or JCO). Consequently, the integration scenario that I present here will be compared to what I refer to as the “MBO approach” since it’s the most common one and it provides a good point of reference.  As for SAP NetWeaver Gateway, it is essentially a component that exposes SAP Business Suite processes as OData services (OData & Generic channels will not be discussed here). This is perhaps an oversimplified summary so please take a look at the resources mentioned above for more information.


Let’s now discuss this new architecture in comparison to the previous model of MBOs and highlight some key differences. First off, when developing a mobile app using SUP you have the choice to adopt (or not) SAP NetWeaver Gateway, in case this was not clear. MBOs have always been at the core of SUP and they still have their merits. They remain an interesting option, even a better choice for some scenarios.  With SUP 2.1, SAP is proposing a complementary approach to ease the development effort but furthermore, SUP and GW tackles the challenges posed by a specific class of application defined as “online apps” (as opposed to offline apps). This approach is specific to this class of application (in this release anyhow).

“Online apps” are defined as lightweight apps with rather simple business use cases or processes that are almost always connected and store little or no data on the device. Technically speaking, this category of applications usually relies on synchronous messaging based on the request-response pattern. If your application fits this model than the general consensus is to use SUP in conjunction with SAP NetWeaver Gateway as a scalable and viable mobile strategy. If you want to know more about which mobile architecture to use, take a look at this blog from Sybase.

The SUP and Gateway integration is enabled by the Online Data Proxy.  The primary focus of this blog is highlighted in blue.


Surprising claims aside, the integration of SAP NetWeaver Gateway does provide some very interesting benefits. First of all, it should be stated that the vast majority of mobile development projects at SAP rest on Gateway. The slew of SAP-delivered mobile apps out there (or upcoming) is based on this architecture so there is most certainly merits to this manner. Simply, I would say that the best reason for adopting this approach is OData and how it can easily allow information from SAP systems to be easily consumed on a variety of devices. This protocol is extremely appealing as it is based on open standards, it’s easy to consume  and simple to use (think in terms of http). Since OData is meant for all types of clients (not specifically mobile apps), nothing prevents your gateway services to be reused and consumed by a variety of other devices or applications if engineered properly.

Another good reason to favor this approach is the fact that all the data modeling is encapsulated at one level, the backend (contrary to the MBO approach where business logic also resides on the middleware). Needless to say, if your company is already a SAP Services Partner then you are better off investing in the in-house ABAP skills and perform all the programming in the back-end vs. having to program custom Java code (such is the case with SUP’s result set filters).

Finally, one common issue that developers encounter most when modeling MBOs to interface with the SAP back-end is that MBOs are generated based on existing BAPIs and this can pose quite a challenge. The inherent problem with this method is that existing BAPIs are not necessarily best suited for the purpose at hand as they have been designed for desktop-grade applications with different requirements in mind (think heavy and complex processes). This makes the modeling task far more complex than the trivial exercise it is supposed to be.  Indeed, in this particular case the modeling task is neither straightforward nor confined to using the MBO generation tool.  Linking MBOs and mapping attributes is now a tricky exercise.  And so more often than not, developers decide to implement custom ABAP code to meet the specific needs of their mobile application. I think this is one of the most compelling reasons for adopting GW. If there is a clear requirement to develop your own BAPI then it’s easy to see why it makes a lot of sense to implement them in the back-end within the context of Gateway services and benefit from reusability, extensibility and scalability.

Now that you understand the benefits of using SUP and GW, let’s take a look at how to enable the integration between both.


A complete pre-packaged SAP NetWeaver Gateway Trial version is available in the Downloads section of SDN (note that Linux or Windows Server 2008 is required). Or, you can proceed with the easy route and opt for the SAP NetWeaver Gateway Demo system. This is more than enough if your goal is to understand the basics.


At the time of writing, a trial version of SUP 2.1 is only offered to Sybase partners or customers.  SAP partners should consult the SAP Service Marketplace or their partner manager.

The first thing you will notice if you are familiar with SUP 2.0 is that the software installation package for SUP 2.1 has been split into two 2 distinct components: SUP Platform Runtime and Mobile SDK. This is a good thing since it is purposely addressing the needs of deployment vs. development. You will need to install both packages.


The focus of this blog is really about the technical aspects of the integration scenario. Personally, I did not encounter any major issues by following the installation guides and so I will not cover the installation process. There’s already some good sources of information on this topic, check them out:

-          SAP Developer Network: Installing Gateway

-          Sybase Online Documentation: Installing SUP 2.1


A typical development flow can be initiated using a top-down or bottom-up approach (in the same way as MBO design). This is still true when developing online apps using GW and SUP. Actually, the development flow does not differ much from the standard way but you have to keep in mind that all the modeling and adaptation tasks that were required for SUP have now been moved to GW.  Essentially, you will develop your client code, expose Gateway services and configure your SUP server to allow your device to consume OData services. Since, we do not have any MBOs with this approach, there’s no modeling, mapping of attributes or generation of device-specific client code to interface with the MBOs.


SAP NetWeaver Gateway is an OData provider meaning it exposes existing SAP Business Suite processes as OData services.  Simply put, it takes RFC data from SAP back-end and “adapts” it into OData. For developers familiar with MBOs, this implies that your business logic will reside solely on the back-end and not on the SUP server. For the purpose of this blog and to showcase an end-to-end scenario, I invite you to use the SAP NetWeaver Gateway demo system.  Most development projects will probably require creating your own Gateway services and in this case, the how-to guides on SDN cover a wide range of possibilities on how this can be achieved.


On the client side, you must develop your client code using the OData SDK in order to enable your mobile device to consume OData services (OData SDK is shipped with SUP 2.1). The OData SDK currently supports iOS, Android and Blackberry platforms. The installation steps are described on the Sybase documentation website (see the OData SDK Developer Guide).

It is also worth noting that as of SUP 2.1, the OData SDK only supports native mobile application development. This is certainly a deal breaker if you are building apps using the mobile workflow package (hybrid apps running on the hybrid web container).


Once OData services are exposed and provide access to back-end SAP processes, the remaining step is to enable the client application to access them by configuring SUP via the Sybase Control Center (SCC). When used in conjunction with Gateway, the SUP server is no longer a container for business logic but acts as a dispatcher of requests from mobile devices located outside the corporate firewall to Gateway and provides more infrastructure-centric functionalities, such as user handling, security and so forth. To give you a clear idea of how this is done, here is a step-by-step guide:

Open SCC (https://localhost:8283/scc/)

Sybase Control Center Welcome Page:

Select Applications à Select Application Connections tab à Press button Register…

Applications Connections:

Fill in information specific to your app to register a new application connection (*pre-requisite: your application has already been created/defined in the “Applications” tab of SCC)

New Application Connection Registration:

Select the newly created item and press button Properties à Select Proxy à Enter value for field “Application endpoint” to direct to your OData service (for GW demo system, simply fill in the URL of the sample consumption model here).

Application Connection Properties:

Click OK and we are done configuring the connection to the Gateway OData provider in SCC.

As you can see, once the client code has been implemented using the OData SDK and the OData service has been made available from Gateway, integrating GW and SUP is simply configuration work.  This is quite different from the MBO approach as there’s little development effort required on SUP.  With this approach, there’s essentially no more business logic residing on this component (tasks such as managing devices/users and security remain).    


With the release of SUP 2.1, SAP is offering a compelling integration scenario to easily access complex SAP processes and help mobilize the workforce. Developing mobile solutions using SAP NetWeaver Gateway and SUP offers many benefits such as the ability to leverage existing ABAP skills and confine the complexity of business logic in the back-end layer.  More importantly, the main advantage of this approach and key differentiator is the ability to expose information using the OData protocol.

A few years ago, SAP established a bold strategic goal of reaching a billion people by 2015 and this release is a step in that direction. It provides scalability in distributing critical business information stored in SAP systems across multiple devices and platforms.  Furthermore, the recent launch of the SAP Store for Mobile Apps illustrates the ambitions of the company in promoting a rich and vibrant ecosystem for enterprise mobile apps. And ICC is certainly aligned with this effort as it rolls out the Mobile App certification for partners and ISVs.

The New Year is off to a great start and should be a thrilling one for mobile app developers as news of new developer resources have already been announced.  Decidedly, it’s a great time to build enterprise mobile apps. Get started now by getting in touch with ICC and learn how simple it is to get your mobile app certified and on the SAP Store!


Allow me to reiterate that the approach discussed here is only one of many integration scenarios available to partners and ISVs. If you are interested in learning more about the Mobile App certification, please contact SAP ICC at to discuss your interest more in-depth.