An MBaaS (Mobile Backend as a Service) is a runtime space for Cloud Apps and Cloud Services. Each MBaaS provides a Node.js runtime, a NoSQL database, a caching server, and all the Cloud APIs.

To support application lifecycle management, there’s an additional layer of isolation provided for Cloud Apps and Cloud Services, called Environments. You can configure an environment for every life-cycle stage of your project, such as Development, Testing, and Production. Cloud Apps, Cloud Services and Forms are always deployed in a particular Environment, and can be easily promoted from one Environment to another.

One MBaaS can host one or more Environments. For example, you could host Development and Testing environment together on a single MBaaS, but have a separate MBaaS dedicated for a Production Environment. Even when multiple Environments are hosted on a single MBaaS they only share system resources but still remain isolated on most levels — separate Node.js runtime, database, caching server, and also a separate host name.

Navigate to the Admin > MBaaS Targets section.

There are three types of MBaaS targets: FeedHenry, OpenShift 2 and OpenShift 3. Each type requires its own specific configuration as described below.

Navigate to the Admin > Environments section.

First, create a new environment using the Create Environment button. You need to set the following parameters:

Cloud Apps, Cloud Services and Forms can now be deployed to this new Environment.

In the Platform, when an app is staged or deployed, it will be running inside a container, also known as a Cloud Environment. Environment resource usage at both the container level and the app level can be managed and viewed here.

The summary view displays the Cloud’s resources at a summary level, and each summary view is expanded by clicking on it. Available cloud environments and also CPU, memory, disk and inode usage is displayed.

You can view the detailed usage of memory, CPU and disk resources in this view. The "Dashboard" view contains an overall view of all three resources and each resource’s tab contains both the environment and per-app usage.

You can see all the apps that are currently running inside the environment, see their status, resource usages and manage them as well. Note you will be able to control embed apps (deployed through the build embed app wizard) here as well.

You can see the current cache usage of the environment, flush the cache and reset maximum cache size.

Push notifications are a mechanism which lets server-side applications initiate communication with mobile clients - to notify the user about availability of new content on the server, or even to send a short message. This is commonly used, for example, in messaging and social network applications, or any other situation where the user might wish to be informed at all times, even when not handling the mobile device.

Red Hat Mobile Application Platform Hosted (RHMAP) has integrated support for push notifications. Through a single unified API you can deliver notifications to all client devices, even across multiple different networks simultaneously with a single function call. Push notification support in RHMAP is based on the open-source project AeroGear UnifiedPush Server (UPS).

In the Studio, there are 4 sections that provide information about push notifications:

To start using push notifications now, see the Push Notifications Client API and Cloud API documentation, or try the step-by-step guide Developing An Application Using Push Notifications.

Support for push notifications is available for all supported mobile platforms through their corresponding push notification networks:

The push notification server inside RHMAP acts as a broker that distributes notifications from your Cloud App to individual push networks, which subsequently try to deliver messages to registered mobile devices.

The simplest use case is delivering a mass notification to all devices, as demonstrated in the following example:

$fh.push(
  {alert: "Hello from {ProductShortName} to all devices!"},
  {broadcast: true},
  function (err, res) {
    if (err) {
      console.log(err.toString());
    } else {
      console.log("status : " + res.status);
    }
  }
);

The Platform is capable of several modes of delivery: all devices, a filtered set of devices, or a single device. You can also choose which Client Apps in your project receive push notifications.

For the built-in UnifiedPush Server (UPS) to be able to access the push notification networks of individual providers - Google, Apple and Microsoft - it needs to supply credentials for authentication with the provider’s push server. The required credentials and the ways to obtain them are very different for each provider. Follow the guide for your target platform and save or make note of the required credentials, which you’ll need to supply to RHMAP when setting up push network variants for your app.

Statistics about push notifications sent to a Client App can be found in the Studio. Navigate to a Client App’s Push section and then to the Analytics tab. The available statistics include:

The Push Analytics screen also provides charts for:

Support for push notifications in Cordova apps is provided through the aerogear-cordova-push plugin. When a push-enabled app is built in the RHMAP Build Farm, this plugin is added automatically for the particular build if it’s configured in the www/config.json file. All RHMAP Cordova templates have this plugin configured.

When building the app locally, you need to add the plugin manually using the following command:

cordova plugin add aerogear-cordova-push

See Using Cordova Plugins for more information.

The open-source community version of AeroGear UnifiedPush Server (UPS) can still be used in your apps, by deploying UPS to OpenShift and connecting it to the Platform through the Cloud Service AeroGear Community Push Connector which is available in the Platform for this purpose. However, note that the community version is only available for evaluation purposes and is not officially supported.