15. Extending Cordova to the Enterprise

As demonstrated throughout this book, Apache Cordova is a great tool for allowing developers to build mobile applications using web technologies. The Cordova team provides the native container that runs the web applications, a suite of JavaScript APIs developers can use to allow the application to interface with native APIs, and tooling that allows developers to manage Cordova applications and Cordova application content.

Cordova doesn’t offer any fancy UI controls, and it implements mostly only core APIs, which will someday become web browser standards. The Cordova team focuses on their specific goals and leaves everything else to third-party developers.

If you think about mobile developers, there are different types of developers and developer organizations. There are independent developers, college students, and hobbyists who create apps and games and sell them to consumers. There are professional developers, small, medium, and large organizations focusing on producing productivity applications and games for consumers. There are also many companies focused on building mobile applications for businesses, delivering prebuilt applications that address the needs of many companies, such as customer relationship management (CRM), field service, expense management, time tracking, and more. There are even companies that produce mobile application development platforms, which allow enterprises (a fancy name for business customers) to more easily build mobile applications for their employees, their business partners and even their customers.

In this short chapter, I cover the world of enterprise mobile development, describe the capabilities of mobile application development platforms, and introduce you to the product I am involved with in my day job as a product manager at SAP (www.sap.com). This chapter is in here because most platforms offer some sort of hybrid application approach and several of them use Apache Cordova.

For a long time, one of the world’s leading analysts categorized mobile development platforms on the basis of the target audience for the applications built using the platform. Platforms for building consumer applications were called mobile consumer application platforms (MCAPs), and platforms for building mobile applications for the enterprise were called mobile enterprise application platforms (MEAPs—pronounced meeps). As the different platforms added features that addressed the needs of both platform types, the industry consolidated the two platform types into a single category called mobile application development platforms (MADPs).

A platform typically includes a server component plus some development tools and a management console. The server component of the platform acts as middleware and  manages requests coming in from mobile devices and acts on them, either authenticating the user against a company directory or brokering requests for back-end data (data retrieved from internal or external application servers or databases). Figure 15.1 shows the architecture at a high level.

Figure 15.1 MADP Architecture

A platform’s management console is used to administer the platform, manage users and applications, and define the connections to back-end data sources.

A platform’s development tools are typically designed to simplify a mobile application’s connection to one or more back-end data sources, exposing data from one or more data sources to an application. The tools also help mitigate some of the problems associated with cross-platform mobile development, either enabling a developer to write one application that runs on multiple device platforms or providing a single API that can be consumed across multiple device platforms.

SMP consists of multiple components:

The SMP server, which provides a suite of services mobile applications can consume such as authentication, provisioning, security, data access, and more

An administrative console, which is used to manage applications, users, and application connections to back-end data sources

Multiple mobile application types specifically designed to help address cross-platform development issues

Figure 15.2 illustrates the platform’s component architecture.

Figure 15.2 SMP Component Architecture

The server’s Data Access Services provide connectivity to both SAP and non-SAP data sources, connecting to those back-end data sources in different ways, as driven by the data source. The data is exposed to mobile devices in OData format (www.odata.org), a standard data format created by Microsoft, published as a standard, and used by many software products. This approach dramatically simplifies how a mobile application accesses data because all data sources are exposed as OData, and therefore the developer only has to learn one way of accessing it.

The SMP server provides many more services than what are shown in the figure. There are services for managing the authentication of a user against a corporate directory (using Microsoft Active Directory or LDAP, for example) as well as services for registering applications, provisioning content and configuration settings, and more.

SMP supports multiple client types, as shown in the figure. Native applications access SMP services using a common API, which is available across multiple device platforms. The server also exposes many of its services as RESTful services, so if you are developing an application that isn’t directly supported, there is still an interface your application can use to interact with the server.

For hybrid applications, SMP provides a suite of plugins called Kapsel, which is described in the following section.

For metadata-driven applications, SMP offers the Agentry application player. Developers build applications using the Agentry tools, and the application consists of a meta-application, the description of an application’s screens, forms, flows, and more, abstracted into what is essentially XML. When the metadata application is deployed into the Agentry Player application, the application’s description is rendered in real-time on the device. This approach provides the ability to build a single version of the application that can be run on multiple mobile device platforms.

Kapsel applications are created using the Cordova CLI. You simply create a Cordova application using the procedures highlighted in this book, then add one or more of the Kapsel plugins. Kapsel supports Android and iOS today, but support for other mobile device platforms is planned for future releases.

In the following sections, I highlight a few of the features of Kapsel and how they help make a Cordova application ready for the enterprise. You can read more about Kapsel in my SCN blog at http://scn.sap.com/blogs/johnwargo.

To help developers deal with this problem, SAP has implemented the Kapsel Logon plugin for Cordova, which allows an application, using essentially a few lines of code, to determine the correct server settings for the environment, connect to the SMP server and register the client application with the server, deal with subsequent locking and unlocking of the application, and even share credentials between multiple applications signed with the same certificate.

Using the Logon plugin, what could be hundreds or potentially thousands of lines of code is abstracted down into just a few simple method calls, which dramatically simplifies the process. The plugin consists of both JavaScript and native application code that manage the whole process.

SMP includes a Client Hub application that, when signed with a company signing key, is deployed to mobile devices and allows Kapsel applications and other applications built with the SMP native libraries to share credentials and stores password information in a secure data vault on the device. This approach makes users happy because they don’t have to enter user names and passwords in all of their applications: they do it once, and the information is shared across applications.

With Kapsel, the initial version of an application is packaged with all of its web application content like a normal Cordova application. Whenever updates are available for the web application, those updates can be packaged and deployed to the SMP server for distribution to users.

In this scenario, the developer or an administrator packages the complete, updated web application into an archive (.zip file) and uploads it to the server. When the server receives the file, it unzips everything, then compares this version of the application against the previous version and makes a package containing only the changes from the previous version of the application.

Kapsel includes an AppUpdate plugin, which manages the application update process for the application automatically. A developer adds the plugin to a Kapsel application, then, when the application starts and whenever the application resumes from being suspended, the AppUpdate plugin wakes up and checks with the server to see if there have been any updates to the application. If there is an update available, the server sends the update package, which contains only the changes to the application, to the Kapsel application behind the scenes. Once the Kapsel application has downloaded the entire package, the user is prompted to apply the changes, and the application is restarted once the update is complete.

As you can see, this is a very important feature that can benefit organizations because it can help deal with some of the challenges associated with application lifecycle management. Having the ability to automatically update Cordova applications without requiring an app store update or disturbing the user helps ensure that your users are always running the latest version of your application.

In Kapsel, SAP has implemented an EncryptedStorage plugin, which adds encryption to the existing key-value pair local storage option provided by the mobile browser and Cordova. Using Kapsel, developers can now easily save their application data locally in an encrypted format and protect it from discovery if a device is lost or stolen.

With Kapsel, SAP includes a Push plugin, which allows an application to register for push notifications. Once the device is registered, the SMP server can send push notifications to the application whenever needed based on the appropriate triggers on the back-end. A corporate sales application can send a notification to a mobile sales application whenever a new PO arrives, or the app can be alerted when an order has been shipped. These types of notifications could be sent to an email account, but it’s sometimes more useful to be able to view these things in the context of the application instead.

Developers can build a logging mechanism that enables a debug mode within the application, causing the application to collect information about what is happening within it and upload that data to the SMP server for analysis by administrators or developers. Getting the user to enable the debug mode and upload the data when ready can be a challenge.

To help developers with this scenario, Kapsel provides a Logger plugin, which a developer can use to collect information while the application runs and upload the data to the SMP server automatically. Applications make calls to a simple set of methods and passes in content that needs to be written to the log. Administrators can even enable logging from the server without involving the application user in the process.