Skip to Content

SAP Mobile Platform and Apache Cordova

In a post I wrote last year ( I told you about how SAP had integrated Adobe PhoneGap with the Sybase Unwired Platform Hybrid Web Container (HWC).  Our HWC is a proprietary container we created to provide our customers with a hybrid container like PhoneGap, only…better for enterprises. At the time we created it (many years ago), the PhoneGap project wasn’t far enough along and we felt that we needed to take the approach we did to ensure we could deliver the capabilities we promised.

With last year’s announcements, we simply made it so that our customers could continue to use the HWC to run their HWC apps, but we also gave them the ability to execute their existing (or new) PhoneGap applications in our container as well. If you’d made an investment in the HWC, it was protected and if you were using PhoneGap for your development efforts, then that investment was protected as well.

Best of both worlds, right?

Over time, as PhoneGap became the open source Cordova project (PhoneGap remains as Adobe’s implementation of Cordova with some extra stuff added), the different mobile platform components of Cordova solidified into a more solid mass. Instead of inconsistent APIs across different mobile device platforms, there was a common API.  Instead of separate Ant-based tools for creating and testing Cordova applications for each mobile device platform, there’s a new node-based Command Line Interface (CLI) that gives developers one tool to manage a single project that works across multiple mobile device platforms.

One of the big issues in the distant past for Cordova was that if you wanted to use some native function in a Cordova application that wasn’t exposed through the core APIs, you were out of luck. Developers started building plugins for Cordova that added external functionality to the Cordova container, and the project team quickly solidified a plugin specification that made it easier for more plugins to be developed and for them to play nice with each other (and with the PhoneGap Build service). They’ve even taken it so far that in Cordova 3.0, the project team stripped out all of the core Cordova APIs and migrating them to plugins.  As of Cordova 3.0, the Cordova container is nothing but a container and all of the additional functionality an application can use is exposed through plugins.

On top of all of that, the PhoneGap Build service gives PhoneGap (and Cordova) developers the ability to package and upload up a web application and get 6 mobile device applications (Android, BlackBerry, iOS, Symbian, webOS & Windows) back from the service.

Awesome stuff!

The Cordova framework is robust enough, reliable enough and popular enough that it’s pretty much the standard for mobile hybrid application development. Our customers are telling us that they’re making the investment in Cordova, implementing some (or all) of their mobile applications using the framework. We’ve reached a point where it makes less sense for SAP to have its own proprietary hybrid container. In order to provide our customers with the enterprise grade tools they need to build their mobile applications, we are adding new capabilities to the SAP Mobile Platform (SMP) in the form of Kapsel, a set of SAP plugins for Cordova.

Kapsel, depending on which non-English language you’re looking at, means container, case, casing and/or capsule.

A Kapsel application is the Cordova container with one or more of the Kapsel plugins added. Kapsel is a suite of SAP developed plugins that make Cordova enterprise-grade and allows it to more seamlessly integrate with the SAP Mobile Platform Server. The Kapsel plugins will provide capabilities like application lifecycle management, implementation of a common logon manager and SSO, integration with SMP server-based push notifications & more. Coupled with the data access and administration capabilities of the SMP server, Kapsel provides customers and partners with the enterprise-grade hybrid development tools they need.

Kapsel will fit within a customer or partner’s existing Cordova development environment and processes. With the plugin management capabilities available with Cordova 3.0, managing the Kapsel plugins in a Cordova application will be a breeze. We may even bundle in tools that more tightly integrate Kapsel’s capabilities with the Cordova CLI to simplify application management, testing, deployment within the SMP server environment.

More details will be available as we get closer to releasing something; stay tuned for more information.

You must be Logged on to comment or reply to a post.
  • This seems like a solid decision. Please advise your marketing department in explaining yet another choice in the Enterprise Mobility roadmap of SAP... 😉

    As technologists, this all makes sense. Business and/or functional people may get the message wrong...

    • Well fortunately as the PM for Kapsel, I get to make sure Marketing has the right message. I will be publishing a whole series of blog posts on Kapsel, so the story should be told pretty well.

        • Ted, That's what I'm doing - providing the information I can about what we're doing with Cordova with Kapsel. As more information is available, I will publish it here.

          • Hi John,

            I know but the information you shared is very highlevel. I was hoping to get some more insights on how exactly this would work. I'll keep following this blog then and hope for more information...

          • Ted,

            Ask some specific questions as I'm not sure what you're looking for. I've tried to explain it in the post, but I guess I wasn't clear.

            Kapsel is a set of plugins for Cordova. As the HWC is proprietary, with Kapsel, we add to Cordova just like any other Cordova plugin. The Kapsel plugins provide some of the same services that the HWC does, only through Cordova plugins. You have application lifecycle management (application updates), implementation of a common logon manager and SSO, integration with SMP server-based push notifications & more - all stuff that was in the HWC to begin with.

            You code to the plugins using the JavaScript APIs exposed by the plugins.

          • Well, as we've not announced nor released Kapsel, there are no direct sessions on Kapsel at TechEd this year. I think however that there may be discussion of Kapsel in in MOB111 and MOB263.

  • Hi John,

    Will the Kapsel plugins be submitted to the Phonegap build service?

    That would be great for those of us that use the new REST API's of the SMP Cloud together with the Phonegap build service.

    • No plans at the moment, but it is something we know we need to think about.

      I'm curious, how many of you are using PhoneGap Build? I just finished writing a book on Cordova 3 ( and deliberately went light on the PhoneGap Build chapter thinking the CLI took care of many of the issues people needed Build for in the first place.

      What says the SCN?

      • Thanks for answering John,

        At least for us it is important. We have lots of customers and partners who mainly use the build service. The main reason is that companies/implementation partners find the online service very convenient. you still need to install all the SDK's with CLI and there are some projects where even getting hold of a mac can be an issue.

        EDIT: Just read up on the CLI and I guess the remote function takes away that argument, But still you need to customize each platform intead uf uploading a zip file 😉

        I know some developers frown upon the build service but then I don't think they understand the extra burden it adds to implementation projects with BOYD policies.

        Since the introduction of submitting plugins to the build service it has greatly improved it's usability.

        Also you guys at SAP get visibility in the PG community (Build part that is 🙂 ) and awareness of the SMP and Kapsel plugins.



  • We’ve reached a point where it makes less sense for SAP to have its own proprietary hybrid container.

    This needs more explaination. HWC is dead, feature complete, in maintenance mode, not recommended anymore, etc. What will happen to current HWC apps? Push notifications? MBO support? Local database? Option to have a list of local HWC apps? Any Cordova SMP app will be shown as a standalone app / icon?

    • Not trying to speak for John, but he said "less", not "no" 😉

      There is a definitve case for MBO apps, but the higher (in terms of number of programs) demand right now seems to be for lightweight REST based apps in Javascript against SAP Netweaver Gateway.

      I'm hoping that the upcoming blogs by John will provide some insight into how much of the gap will be bridged by Kapsel.

      • My question is about: what to do with HWC development and apps? HWC apps installed, training material created, distributed, user is used to UX, development workstream set up ... and what will happen to HWC?

        Cordova is different. While I can run Cordova apps on HWC, will I be able to run HWC apps on SMP enhanced Cordova without modification?

        You cannot simply say: hey, its Cordova now. Those upcoming blogs should be published rather soon, like today 😉

    • Tobias, My point was more about SAP providing non-proprietary solutions rather than making a statement about the life of the HWC. The HWC has been used by a lot of our customers and is a great solution; Kapsel is a different, non-proproetary option for developers.

      The HWC has the ability to run multiple web apps, Kapsel does not - it is a single app solution. The HWC has offline cache, Kapsel does too, but it doesn't provide the same capabilities (Kapsel provides an encrypted offline cache, but doesn't manage it like the HWC does for you).

      Let me get started on that next blog post. Stay tuned.

    • Yes, absolutely. It's on the roadmap. The OData SDK for SMP 3 was in progress as Kapsel development happened in parallel; there simply wasn't time to create the OData plugin before launch.