Skip to Content

How Adobe PhoneGap with SAP Gateway creates Affordable Mobility

SAP-PhoneGap-Demo.jpgAt last year’s SAP Press conference, the partnership between SAP and Adobe PhoneGap was announced. The reason is apparent; SAP wants to expand their developer footprint in an effort to increase the amount of quality apps available for customers in the SAP app store. Sanjay Poonen said it best by admitting, “(Mobility) is a movement going around us that’s well outside of our control” (see video).

The anniversary of this announcement is just another reason to talk about all of the cool stuff that’s been happening in SAP Mobile Solutions. The combination of NetWeaver Gateway embracing REST-based web services, SAP’s blessing of PhoneGap, and touch-optimized user interfaces like SAPUI5 and jQuery Mobile created an opportunity in SAP mobility worth getting excited about.

We’ve seen too many SAP customers delay their mobility efforts because of the licensing costs presented by the Sybase Unwired Platform (SUP). The hidden truth is that customers can avoid these costs by connecting devices to SAP via NW Gateway. If you own the appropriate user licenses for the users consuming the data, you’re covered. For instance, companies with ESS/MSS user licenses can create Gateway services against data within the scope of the ESS/MSS user license and without reaching for their wallet.

Watch this example of a PhoneGap app that we created against demo Gateway services or download the app here to try it for yourself. (iOS is not available since the device UDID is required for development provisioning.)

NetWeaver Gatway (Available to SAP customers)

The NetWeaver Gateway team has done a great job providing a simple way to create REST-based OData web services. After installing the Gateway add-on you can quickly and securely expose your SAP data to both SAP and non-SAP platforms via your choice of XML or JSON (JSON is faster) ℹ watch my tutorial

Adobe PhoneGap ($10 /month)

Adobe PhoneGap is a great example of a non-SAP platform that can consume these Gateway services. With PhoneGap, you can develop an app that leverages the native features of the device (e.g. Camera, Notifications) by simply using web languages like HTML, JavaScript and CSS. The best part is that you only have to write the mobile application once; PhoneGap’s new build service will compile the files needed to deploy your app to multiple devices.

UI Technologies (free)

Since using NetWeaver Gateway and Adobe PhoneGap to create our mobile apps will save us a bunch of time, we can now focus on creating a beautiful UI. That’s where SAPUI5, Sencha Touch and jQuery Mobile come into play. These free tools help us create beautiful touch optimized interfaces.

Learn how we can kickstart your mobility effort: Mobility Rapid Enablement Services | hyperCision, Inc.

hyperCision, founded in 2001, is an SAP and SuccessFactors partner. hyperCision consultants have assisted in hundreds of successful implementations and provided expert advice to professionals in every industry.

SAP NetWeaver Gateway demo services: Gateway Demo System | SCN

You must be Logged on to comment or reply to a post.
  • Thanks Brandon. Great blog.

    This is a great starting point to mobility, especially as we’re looking at the Gateway services as our dev route.

    Look forward to the rest of your contributions….don’t stop there.


    • I’m glad this information was helpful AVIK. I didn’t go very in-depth on Sencha Touch since I was using jQuery Mobile in the demo. As mentioned, Sencha and SAPUI5 will also work with Adobe PhoneGap. I’d be interested to know what other UI tools the community is using.

  • Brandon is right, pairing Apache Cordova (the open source project; PhoneGap is simply Adobe’s implementation of Cordova) with SAP technologies helps simplify many aspects of mobile development.  You can build an app using Cordova/PhoneGap that consumes OData sources directly from NetWeaver Gateway or can leverage a proxied connection provided by the SAP Mobile Platform (SMP – what was formerly known as the Sybase Unwired Platform (SUP)). SMP provides some additional enterprise features not included with Gateway, plus provides features for connecting to non-SAP and non-OData data sources, so you’ll choose to go direct or leverage SMP depending on your organization’s specific needs and requirements.

    One of the interesting capabilities provided by SMP is that its Hybrid Web Container (HWC) allows an organization to leverage a hybrid container deployed to a device (similar to a PhoneGap application) then remotely manage the content running in the container. What you get is a single application icon which can have one or more web applications (including Cordova/PhoneGap applications; we added support for PhoneGap to the HWC in SUP 2.1.3) running within it. The customer gets one application icon on the home screen, but can provision, upgrade and decommission apps remotely.

    Keep in mind that Apache Cordova and Adobe PhoneGap are free; the $10 per month he talks about in the article is for the PhoneGap Build service which is an optional service which allows you to quickly build multiple versions of your Cordova/PhoneGap application (Android, iOS, BlackBerry, Symbian, webOS and Windows simultaneously) during development. You can build any Cordova/PhoneGap application using local SDKs without spending any money on the Build service.

    Just in case you’re not familiar with PhoneGap, you can read about it in my book entitled PhoneGap Essentials (  Apologies for the shameless plug 😉

    • Hi John, thanks for your feedback. “Shameless Plugs” are much more acceptable when embedded in a very informative response such as yours. Regarding the Hybrid Web Container (formally known as Sybase Workflow), the reason HWC can manage apps remotely is because the HTML, JavaScript, CSS and Images are all generated from the backend server. This means, at the very least, the initial navigation of a HWC app must be downloaded onto the device (likely creating a less than desired experience for non-wifi connections).

      Regardless of the mobile development framework a company decides to go with, the first app is typically the most expensive to build. Knowing that, I think it’s important to choose a technology that will satisfy both immediate and future mobile development requests. Maybe HWC makes sense for the simple approval app currently requested by the business, but does it also makes sense for more complicated, multi-functional app that’s going to be requested the day after your go-live? That’s why I believe the Gateway and PhoneGap Combo wins; there’s a lot of flexibility without a substantial investment.

      Sure, I might not be able to decommission an app remotely, but I don’t see how that’s relevant in terms of enterprise security. Every time a user requests a gateway service a valid user account is required. I doubt most companies would take the time to decommission the SAP GUI from a BYOD laptop after an employee departure; just like a Gateway mobile app, it’s completely harmless without an active SAP account.

      Is it still true that none of the SAP Standard Apps are HWC based?

      • SUP 2.2 added the ability to pre-load a HWC App with v1.0 of an application – the application is deployed with content, so the user’s first experience is as expected. Once the application/user have authenticated with the server, an updated version of the application’s content (the web app), if it exists, is deployed to the container application OTA .

        The web application isn’t ‘generated’ by the back-end server – they’re created by a developer (using whatever tools they want to use), packaged and deployed to the SMP server so the SMP server can deploy the app to remote clients. I’m not sure what ‘generated’ means in this context.

        I’ve never bought into the ‘complicated’ vs. ‘simple’ apps distinction between hybrid apps and native apps. There is a component of that that affects your choice, but at the end of the day you’re going to build a mobile app while trying to leverage the skills you have and the tools you have expereince with first and try to match them against the application requirements. You can make a big, honking sophisticated app using web technologies or native technologies – what matters when you’re evaluating PhoneGap or the HWC vs. Native is whether the hybrid approach provides access to the features the application requires. If not, you go native.

        For example, you can try to build a sophisticated, complicated app using PhoneGap, but as soon as you want to manipulate a large data set within the application, the PhoneGap app breaks because of the size (and performance) constraints of the local storage model supported by the Browser (and therefore PhoneGap). The HWC on the other hand includes an enterprise grade database, so you can work with a much larger data set within a HWC app – and that helps eliminate constraints of HWC over native.

        I think you think I’m arguing against the Gateway and PhoneGap approch – I’m not, I love that option. I was simply responding to your statement that customers ‘delay their mobility efforts because of the licensing costs’ of SUP and instead try to explain why customers might find SUP beneficial alongside Gateway. Customers can do it either way, direct to Gateway or through SUP/SMP – the question to answer is are there requirements of the application that are not accommodated by Gateway/Cordova (I have to stop calling it PhoneGap) approach alone? If so, then SUP is valuable and delivers real value to customers. The Cordova approach is a great solution – but Cordova doesn’t have the enterprise features that the HWC does (like support for large data sets or offline caching).

        As Cordova offers a subset of the capabilities of the HWC (the HWC runs Cordova applications out of the box, plus adds enterprise features on top of it), so any perceived limitation in the HWC applies also to the Cordova approach. Hybrid applications ‘work’ for some apps, but native is better for others. The good news is that SAP offers support for both.

        • I totally agree that customers should invest time researching what solution best accommodates the requirements of their business app. Though the support of large data sets is not a PhoneGap limitation. Via a free PhoneGap plugin you can access native classes that enable us to store unlimited data in the native database.

          Available Options:

          LocalStorage (10MB)

          SessionStorage (10MB)

          SQLite databases (50-80MB)

          Native Database (unlimited) *plugin required

          With this access to unlimited storage, offline caching is very possible. Also, as of PhoneGap 2.5, appcache is fully supported.

          I enjoyed this discussion, thanks again for your input. It sounds like there’s been a lot of recent improvements to HWC. If you wouldn’t mind, please share a link to the latest features and pricing so other readers and I can further evaluate HWC’s latest offerings.

          • Support of large data sets is a modern browser, and therefore a PhoneGap, limitation – if it weren’t, you woudn’t need a plug-in to get around it. I’ve not worked with a database plug-in for PhoneGap – you may want to share the name of the plug-in so others can try it out.

            New product features are documented in the product documentation – for SUP 2.2, refer to the following What’s new document:;jsessionid=1p5lsomo2gadx

          • Plugins are a core benefit to the large developer community Sanjay seemed so excited about in the mentioned press release. Something I failed to mention, the BarcodeScanner plugin was used in the demo app featured in this post.

            Even PhoneGap Build currently supports multiple third party plugins like BarcodeScanner and Adobe is undergoing an infrastructure change to allow users to submit their own plugins (a change that cannot come soon enough!)

            Here are the Native SQLite plugins worth checking out:



            A here is a cool sync tool that tracks and syncs to a server when a connection is available:



          • Absolutely – plug-ins benefit the community; they add capability to Cordova that Cordova doesn’t offer directly. Going forward, everything in Cordova will bea  plug-in and the Cordova container/application will just be a framework that everything runs under – both the web application and any plug-ins used by the app.

            My point is that Cordova out of the box doesn’t support the enterprise grade database that the HWC provides. That’s it and nothing more. All I’m trying to do is highlight just one of the reasons why someone would want to use the HWC over direct connection to Gateway. There are many more.

            As I understand it, on most platforms, the Cordova implementation of local database is simply a pass through to the local database supported by the local browser container. Its only on mobile devices that don’t support the standard web browser local database (are they any of them anymore) that Cordova even implements any code. To provide a consistent API across all supported devices.

            As soon as you start talking about plug-ins you prove my point. Cordova, out of the box, does not provide a hybrid application with the enterprise grade capabilities that is needed. That’s all I’m saying. Of course you can use plug-ins to add that capability, nothing wrong with that and that’s a great solution – but it’s not core Cordova/PhoneGap. Again, you started by complaining about customers’s issues with the cost of a SUP/SMP license and I’m simply trying to point out some of the benefits, nothing more.

            You can add plug-ins and third party solutions to any product or open source framework to give it capabilities it doesn’t have today, that’s the beauty of open source. That’s what you’re describing here – and that’s a great option and I’m not arguing against it – I’m simply trying to point out why someone would want to use SUP/SMP, nothing else. You can add plug-ins to Appcelerator Titanium, jQuery Mobile and many other frameworks to make those products do something more than they do out of the box. But you’re cobbling together components from many different sources and , not that there’s anything wrong with that, I’m simply describing a single solution that provides many of the features enterprise customers want.

            From the start I simply said pick the solution that makes the most sense for you (whether you’re an individual developer, small business or large business) – there are many options avialble to you they all have strengths and weaknesses against the others – you mentioned that companies didn’t like the cost of our mobile platform while I’m simply trying to explain why (and where) the solution adds value.

  • Hi Brandon,

    Nice information.

    I followed the your youtube link and copied the below project.


    and i changed the url in the index.html file. When i am executing in chrome i am getting a pop up error message “The authorization you provided does not work on ES work place”

    and “Origin null is not allowed by Access-Control-Allow-Origin.”



    • Hi Suresh,

      Chrome does not allow you to do cross domain requests by default. If you want to test (simulate) your app from chrome you need to disable web security. Close down all your chrome windows and start chrome.exe from the command line and add –disable-web-security as an argument.

      When you use Cordova to actually create the apps you need to white list your server url for iOS.


  • I would like to mention the option of using the SMP Cloud edition as an affordable approach (A few $ per month per user). The new REST API in the SAP Mobile Platform is a perfect way for Hybrid Phonegap applications to securely connect to your backend system.

    Also SAP is working on some great Cordova plugins called Kapsel that will help with authentication, encryption and offline storage etc.

    John Wargo knows a lot more about these plugins than I do though 😉