The projects section allows you to create and manage projects. Once a project has been created, multiple Apps can then be associated with those projects. If you have an existing App, the 'Import' feature can be used to import it into the Platform.

A Project consists of Apps for different platforms, and a Cloud App that they talk to.

As well as creating Apps, existing Apps can be imported into the Platform. When importing an App, you have the choice to either create a new project and add the App to it, or to simply add the App to an existing project. There are a number of different App types that can be imported into the Platform. These include Native iOS, Native Android, PhoneGap, Basic Web App, and Advanced Web App. There are also a number of different ways in which an App can be imported to the Platform. These include :

Step by step instructions will be provided, informing users of how to successfully import their Apps into the Platform. These steps will differ slightly depending on which import method was selected. For example, only the 'Cloning an existing Git repo' option has instructions on how to clone Git repositories.

The Apps, Cloud Apps & Services section allows for the managing of Client Apps and Cloud Apps within a project. Here, new Client and Cloud Apps can be added to a project. Cloud Apps serve as a gateway between the Client App and the cloud back-end storage and services.

You can add as many Apps to a Project as you like - you have three options to choose from:

The connections section provides an overview of Binaries built in the selected project, along with running Cloud code. A project contains both Client Apps, and Cloud Apps. A Connection dictates which Cloud Instance a Client App points towards. A connection will point towards a particular Cloud App in a given environment. The Dashboard provides an overview of connections that are present in all environments. From the dashboard, users can see how each Client App is connected to a Cloud Instance. Connections between Client Apps and Cloud Apps can be reconfigured or disabled as often as you like.

The Git QuickStart page shows how to access Client and Cloud code of an App on your local system by using Git. To access your project from your computer, you must first clone the repository. Cloning a repository creates an exact copy of an existing repository. All versions of all files in project are pulled down when a 'git clone' is performed. However before you can clone a repository, you need to upload your SSH Public Key. Once a Public Key has been uploaded, repositories can be cloned at will.

For more information regarding cloning a Git repository, see the Git Documentation on Getting started with Git.

For a more in-depth list of useful Git commands, see Git Reference.

The Resources section shows resource usage, such as CPU usage, Memory usage & Disk usage, for all Apps in the Project across all environments. If an App is not deployed in a particular environment, no resource usage will be shown for it. The status of deployed Apps can be managed from this screen as well. For example, if a particular App is showing high memory usage, it can be stopped. Resource graphs are based on live data, and as such may take a while to show trends while data is fetched periodically.

A Project typically starts as a single App (for example, a Cordova App) and a Cloud App (for example, Node.js Application). As a Project progresses, it goes through various stages, that is, a Project Lifecycle. Every Project moves at a different pace, and grows & varies in composition over time. The goal of the Lifecycle Management Dashboard is to make this process easier for both the developer(s) and the project manager.

The Dashboard provides a snapshot view of a Project at the current point in time. All Apps are represented by a row on the dashboard. Each Environment corresponds to a column on the dashboard. This grid can give a quick overview of the stage that each part of the Project is in, without having to consult with each team member.

If an App has been built, the most recent build will be shown in the column that represents the Environment it is targeting a Cloud App in. The App binary can be downloaded from here, or rebuilt from a different git branch or tag. The 'Promote' option is a shortcut to rebuild the same code, but connect it to a different Cloud App Environment.

If a Cloud App has been deployed, the most recent deploy details and status will be shown in the corresponding Environment column. The Cloud App code can be deployed (or redeployed) to any available Environment. The 'Promote' option for Cloud Apps is a shortcut to deploy an already deployed git branch or tag to a different Environment.

The Forms configuration page allows users to both associate Forms and Themes with a Project, and also configure Client Side AppForms settings. Users can manage settings relating to Camera Settings, Submissions, Admin Users, Client Logging, and Cloud Logging.

Submissions associated with a project can also be viewed from this page.

The reporting section offers high level graphical representation of analytical information for both Client and Cloud Apps in a given project. Users can access a variety of information, such as how many Device Installs were performed, how many App Startups occurred, and more. Any one of these areas can be further investigated to access analytical information based on Date, Platform, and Location.

In Studio, this information is represented via a number of different graphs. Date specific data is represented by a line graph. This allows users to see a breakdown of App activity for a specific date range. Users can see the volume of activity for any given date in the range. For example, users could see how many Cloud Requests were performed on any given date in a date range.

The donut graph shows a breakdown of activity per platform. For example, the number of installs performed per platform inside a specified date range. Location specific data is represented on a Geographical map. This provides users with a breakdown of App activity based on geographical location. Each graph has a corresponding legend. Hovering the cursor over any of these charts will provide more info on the corresponding value in the legend.

The date range from which the data is gathered can be altered. Predefined ranges display information based on the 'Last 7 Days', 'Last 30 Days', and 'Previous Month', however if none of these are applicable, it is also possible to manually select a start and end date for the Range. This enables users to retrieve App data for a specific date range by simply selecting a data category, and then entering a date range.

From the Project Settings page, projects can be renamed or deleted.

There are a wide variety of Apps that can be built via the Red Hat Mobile Application Platform Hosted (RHMAP), including hybrid, HTML5, or Native Apps. Both Client and Cloud Apps can be added to any project. Apps have access to a number of JavaScript API’s that offer access to features such as geolocation or back-end storage. Form based Apps can now be created via a simple drag and drop interface.

The Details page is opened by default when the Apps, Cloud Apps and Services screen is selected. Here users can access overview information regarding the currently selected App. This information includes:

Any of the App details can be updated from this page. In Studio, there is also an App Preview on this screen. Users can choose to preview how the App would appear on either a phone, tablet, or desktop. After one of the devices has been selected in the App preview window, the user can preview how the App would appear on specific device by selecting a specific device from a list of dropdown options.

Apps can also be deleted from the Apps, Cloud Apps & Services page.

The built in editor allows users to edit code within their Apps. The built in syntax highlighting feature makes it easier to distinguish between syntactical elements. Users can create new files and folders, with saved changes being automatically pushed back to the corresponding Git repository.

After a change has been made, the preview automatically refreshes so you can instantly see your changes take effect. Changes can also be pulled in from a Git repository by performing a 'git pull'. The following Git functionality is available in the Editor section of the Studio:

The App Preview in the Editor section allows users to view how the current App appears on a number of selectable devices.

If your App contains a README.md markdown file in its route, it will be rendered and shown here.

The Analytics section provides access to a graphical representation of App usage statistics. Data can be examined via a number of categories including Installs, Cloud Requests, StartUps, and Active Devices. This data can be further categorized by date, platform, and location. Graph content is displayed by platform, with the exception of the 'Installs by Location'. Each platform is represented by a different key in the legend. Content in the graphs can be toggled on/off by clicking on the respective platform in the legend.

The date range can be also be customized. Predefined ranges include 'Last 7 days', 'Last 30 days', and 'Previous Month'. Users can also apply their own start and end date to the range.

When an App starts for the first time, it makes a call back to the cloud and at this point, a Device Install is recorded. A Device Install is different from a User Install. A User Install is tracked by App Stores in the following ways:

The Push section allows users to configure push notifications for an App. Learn more about using push notifications in the Push Notifications chapter.

The Build feature enables users to build a set of binaries for a selected platform. When performing a build operation, the Cloud App you want the Binary to connect to must be selected. This can be any of the Cloud Apps associated with the project. Builds can be done for any of the following platforms:

One of a number of Build Types must also be selected. These include:

Depending on the platform that has been selected, along with the Build Type, a Credential Bundle may be needed to sign the Binary. For more information on Credentials, see the Credentials section below.

Once a build has been successful, its Artifact is added to the Artifact History. The Artifact History provides summary information of the build, including the Platform the binary was built for, the Build Type, and the Credential Bundle used for the build. Selecting an Artifact from the Artifact History gives the option to download the binary again.

The Export section allows the user to export an App via a number of selected platforms. When exporting an App, the Cloud App you want the Binary to connect to, the Platform, and the Version of the Platform must all be specified. Apps are exported as a zip file. When an export is complete, the export is added to the Artifcat History where it cab be redownloaded at any time.

The Credentials section enables users to manage Credential Bundles. New Credential Bundles can be added or imported. A list of existing Credential Bundles can also be viewed.

The Integrate section allows users to import an existing Client App into a RHMAP project. In order to import an app, you must clone the repo and integrate the app with the RHMAP SDK.

A Cloud App is a server-side application that runs on an MBaaS - our cloud execution environment. Client Apps communicate with Cloud Apps in order to access back-end functionality such as data storage, authentication, caching etc.

The Details section provides access to overview information regarding the Cloud App. This section allows users to edit and manage this data.

An App can be in one of two states, either Running or Stopped. The state of the App can be controlled by the Start App, Stop App, and Restart App buttons. If an App is Running, on device builds of that app will function as expected. However if the app is Stopped, on-device users will not be able to use the app if it relies on Cloud functionality.

There is also a list of general information such as the App ID, App API Key, name, etc. This information can be edited and updated from this section.

The built in Editor can be used to edit code within the Cloud App. The built in syntax highlighting feature makes it easier to distinguish between syntactical elements. Users can create new files and folders, with saved changes being automatically pushed back to the corresponding Git repository.

After a change has been made, the preview automatically refreshes so you can instantly see your changes take effect. Changes can also be pulled in from a Git Repository by performing a git pull.

The App Preview in the Editor section allows users to view how the current App appears on a number of selectable devices.

You can define environment variables using the Studio and those variables can be accessed in the cloud code. The Studio will show a list of current defined environment variables and current deployed environment variables for each cloud environment. You can also view the list of environment variables defined by the system.

// PIN_ENABLED is the environmental variable created in the Studio.
var pin_enabled = process.env.PIN_ENABLED  || true  // defaults to true if no value defined

// On the cloud side using node.js
exports.getEnvVariable = function(params, cb){
  var pin_enabled = process.env.PIN_ENABLED  || true

  return cb(null, {
    enabled : pin_enabled
  });
};

// On the client side
$fh.act({
  act : 'getEnvVariable',
  req : {}
  }, function(res){
   // run this in the event of success.
}, function(err){
   // run this in the event of failure.
});

The Data Browser section of the App Studio allows a developer to

For more information, see the Data Browser Guide.

The Deploy section allows a developer to:

The Deploy process for Node.js applications typically does the following:

The steps above will differ depending on the options chosen, the type of App and the presence & content of certain files.

There are 2 types of stats available in the Studio: App Endpoint stats and Custom Stats. These are found in the 'Stats' section for any Cloud Apps.

There are some common UI features in the charts that represent this stats data. The data can be downloaded in different formats (for example, csv). The date range can be altered using the scrollbar and sliders below each chart. Each line in a chart can be toggled on/off by clicking that item in the legend.

An app will generate events when certain actions are invoked against it. Those events will be recorded by the platform and presented to the developers through the App Studio and FHC. For example, when an app is deployed by an developer, the platform will record when the deployment happened, who invoked it and what are the results.

Each event has a category, a severity level and a name. The following events are generated by the platform at the moment:

Users can access current and archived App logs created in each App environment. Logs for Cloud App activity are retained with the following limits:

The endpoint security feature allows you to decide the level of security you wish to apply to your App’s endpoints.

A Service is a running Cloud App used by projects to integrate with back-end systems for example, an Oracle integration service. Services are added to one or more projects to make them available to Apps in that project.

In order to be able to create an instance of a Cloud Service, users must have either a Developer Admin Role or Developer Role assigned to their account, in order to be able to create and manage projects. Services can then be added to a project in the same way an App or Cloud Instance is added.

Service Administrators can provision new MBaaS microservices that allow developers access to various back-end systems. Users can choose from a number of available services. After a service has been provisioned, it is then available to be used within Projects on the Platform. By default, when a service is created, it is marked as private. In order for the service to be available to all projects on a domain, the 'Global Service' option must be enabled. This declares the service as being publically available.

Here you can access general overview information related to a specific service.

The Docs section contains an API documentation viewer, which clearly shows important aspects of the service’s API for each of its endpoints, such as:

All of this is automatically generated if the root directory of the service contains a README.md file adhering to the API Blueprint specification. To learn more about the specification, take a look at the API Blueprint Tutorial or refer to the Language Specification for a full reference.

The built in Editor allows users to edit cloud code related to their service instance. The built in syntax highlighting feature makes it easier to distinguish between syntactical elements. Users can create new files and folders, with saved changes being automatically pushed back to the corresponding Git repository.

After a change has been made, the preview automatically refreshes so you can instantly see your changes take effect. Changes can also be pulled in from a Git Repository by performing a 'git pull'.

The App Preview in the Editor section allows users to view how the current App appears on a number of selectable devices.

You can define environment variables using the Studio and those variables can be accessed in the cloud code. The Studio will show a list of current defined environment variables and current deployed environment variables for each cloud environment. You can also view the list of environment variables defined by the system.

The Data Browser section of the App Studio allows a developer to

For more information, see the Data Browser Guide.

The Deploy section allows users to manage the deployment of their current mBaaS code. Deployment targets can be created and selected, and deploys can be staged to either the live or development environments. As the Cloud Instance is being deployed, a deployment log is displayed, allowing users to closely examine all details of the deploy.

There are 2 types of stats available in the Studio: App Endpoint stats and Custom Stats. These are found in the 'Stats' section for any Cloud Instances.

There are some common UI features in the charts that represent this stats data. The data can be downloaded in different formats (for example, csv). The date range can be altered using the scrollbar and sliders below each chart. Each line in a chart can be toggled on/off by clicking that item in the legend.

An app will generate events when certain actions are invoked against it. Those events will be recorded by the platform and presented to the developers through the App Studio and FHC. For example, when an app is deployed by an developer, the platform will record when the deployment happened, who invoked it and what are the results.

Each event has a category, a severity level and a name. The following events are generated by the platform at the moment:

Users can access current and archived service logs created in each App environment.

The endpoint security feature allows you to decide the level of security you wish to apply to your App’s endpoints.

MBaaS is a runtime space for Cloud Apps and Cloud Services. Each MBaaS provides a Node.js runtime, a MongoDB database, a caching server, and all Cloud APIs.

Environments add an additional layer of isolation for Cloud Apps and Cloud Services to support application lifecycle management. An Environment is hosted on MBaaS.

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.

A single MBaaS can host one or more Environments. For example, you can host Development and Testing environments together on a single MBaaS, but have a separate MBaaS dedicated for a Production Environment. Multiple Environments hosted on a single MBaaS remain isolated on most levels. They share system resources but have separate Node.js runtime, database, caching server, and a separate host name.

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 notification is a mechanism that allows server-side applications to initiate communication with mobile clients, to notify the user about availability of new content on the server, or 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 notification networks. Through a single unified API, you can deliver notifications to all client devices, even across multiple different networks simultaneously with a single function call. Do note that individual push notification networks handle the actual delivery of a notification to mobile devices. 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 supported mobile platforms through their corresponding push notification networks:

RHMAP push notification acts as a broker that distributes notifications from your Cloud App to individual push networks, for example, FCM or APNS. Individual push notification networks handle the actual delivery to 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 and Apple - 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 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.

All forms are created from templates.

When creating a form, you have the option to create an empty form using the Blank Form template. There are also pre-populated form templates for different scenarios that may be more convenient to customize.

You can preview a template to see all its fields. Once you select a template, you can enter a form name, and an optional description.

When the form has been created using the Create Form button, you are taken directly to the Edit Form screen to customize the form.

Forms are created through the inclusion of fields. There are a variety of different fields that can be added, each with a different purpose. Listed below are the fields that can be added to a form, along with a brief description. Fields have a variety of different configuration settings. Depending on the field selected, different field configuration settings will be available. Red Hat recommends that you use a maximum of 100 fields in a form.

Fields are split into two categories:

Fields can be added to a form by:

After fields have been added to a form, they can be repositioned by dragging them to the desired place in the form.

If you created an App before RHMAP 3.20:

The Forms Projects screen allows you to view any projects that are associated with forms or themes and create a new forms project.

Projects can be searched by name in addition to viewing the number of forms related to each project.

You can create a Forms Project in one of two ways:

For more information, see the How to create a Forms Project guide.

You can create a new Forms project in one of two ways.

The Project Forms & Themes screen allows you to associate forms and a theme with the project.

You can associate a theme by selecting a theme from the drop-down list. To preview a theme, select the theme in the Project Theme list and click one of the forms in the Forms list. This will render the form into the preview area.

To add forms to the project, click into the forms list. You will be presented with a list of available forms. Typing part of the form name will filter the list. When you have found the form, select it from the list. You will now see it in the forms associated with the project.

When you are finished adding forms, click on the Save button to update the project.

The Advanced Config screen allows you to configure Client and Cloud Apps.

Fields in a form can be hidden or displayed dynamically based on values of one or more other fields.

Pages can also be hidden or displayed based on a predefined set of rules. When applying rules to pages, the 'object' affected by the rule will always be a page. This means that although the subject of the rule will be a field, a page will always be affected. Rules are applied in the same way they are applied to fields.

For example, a rule could be applied to an age field, where if the input is an age of 17 or older, a text field asking the user to list previous jobs appears. If the user is too young to have had a job, the field is hidden.

When constructing rules, different comparisons can be selected depending on the type of field the rule is being applied to. For example, a text field and a number field will have different comparison options. When applying a rule to a text field, a rule can be constructed based on whether an input begins with a particular letter, contains certain letters, or ends in a particular letter, whereas when applying a rule to a number field, rules are constructed based on whether or not input to a particular field is greater than, less than, or equal to a particular value.

Different types of fields have different rule comparisons available for selection.

To make your forms applications more dynamic, you can set certain field types in Forms to have values loaded dynamically. The values can be loaded from a database, from an external web service, from a back-end system, or any other source accessible through an MBaaS service.

Data sources are the mechanism which binds a form field to an MBaaS service which provides the values.

The following field types can have values loaded from a data source:

For a step-by-step guide to defining and using a data source, follow the guide Dynamically Populating Form Fields From an MBaaS Service.

The data source acts as a binding layer between the form field, and the MBaaS service endpoint. When a form definition is accessed, the data for fields backed by a data source are not retrieved directly from the MBaaS service. Instead, the data source always returns a version of the data cached in the environment.

For example, when a data source is invoked from a form deployed in a Dev environment, the associated MBaaS service must also be deployed in a Dev environment, and the data is cached only for the Dev environment.

When creating a theme, select a theme from a list of templates.

When a theme template is selected, a preview of the theme is displayed. Once a template has been selected, the user then enters a theme name, and description (optional). The theme can now be edited to customise the appearance of the form.

The Submissions page is used to view forms that have been submitted either via Studio or via a Client App. Submissions can be viewed on a per Form basis, per Project basis, or by Recent Submissions.

Form Submissions can be viewed using the Submissions Viewer, and edited by the Submissions Editor.

Submissions can be exported in Comma Separated Value (CSV) format using the Export Submissions button. When exporting Submissions, the headers for the exported fields can be

The Recent Submissions page also shows a list of forms that have been recently submitted. A variety of submission information is provided along with the Form and Project name. This includes the current environment the Project is deployed on, the date/time the submission was received, and the input to the form fields.

Clicking on a submission will display the details of the submission.

Advanced submission search allows for searching form submissions with customized criteria. Users can build up clauses filtering the values of fields to find the relevant submissions.

All non-admin fields submitted by the user are displayed along with any images and files the user uploaded.

In addition, Admin Only fields are displayed for adding additional information to the submission.

Images are displayed inline. To save the image to your computer:

Files can be opened by clicking on the link in each file entry.

To save the file to your computer:

The buttons at the bottom of the screen allow for 4 functions

Editing a submission can be performed by entering data into the field (for example, text, number).

Admin fields are indicated using the (Admin) icon.

If a field is repeating, additional values can be added to the field with the Add Input button.

The contents of a file or a photo field can be changed by clicking Choose File below the file or a photo. The file or the photo can then be added from your local computer. When the new file has been chosen, a message will appear showing the file is queued for upload.

To save any changes made to the submission, click the Update Submission button. This will update the submission data in addition to uploading any files selected.

Clicking Cancel will abort any changes entered into the submission.

The Notifications section allows users to manage email addresses that will receive an automated email once a submission is received.

Here, email addresses can be added to and removed from a notification list. Any email address that has been added to the list will receive an email whenever a copy of that Form is submitted.

This section of the Account area shows your account details such as Name, e-mail address and your account type. Account Preferences, such as re-enabling the Welcome introduction or always showing the context help, can be modified here. Your password can be changed on this page too.

Accessing your App repos via Git requires you to upload an SSH Public key. This section of the Account area helps you do just that. You can upload multiple keys if you have a different key on various machines, or want to allow someone access. Keys can also be searched, based on the label you gave it, or deleted.

Your SSH key is typically located in:

~/.ssh/id_rsa.pub

Or, to generate a new key use:

ssh-keygen -t rsa -C "your_email@example.com"

In a traditional web application the user authenticates with the server, and then a cookie is incorporated into all subsequent requests sent to that user. RHMAP replaces the traditional method and uses an API key which is similar to a cookie but is sent in a header called X-FH-AUTH-USER. This header must be incorporated into every request sent to the user.

User API keys can be viewed in the My Account → My Profile → API Keys section of the App Studio. In the API Keys section of the App Studio, users can create, list, edit and revoke their user API keys. When accessing the REST API programmatically, a valid user API key must be manually set in the "X-FH-AUTH-USER" header field for each request.

By default, you will have no User API keys (with the exception of any system created keys for example, FH_MBAAS_API_key). Multiple API keys can be created, so its a good idea to give each a unique label. The key value will be generated automatically. Labels can be modified later if required. If you no longer require a specific key or wish to prevent it from being used any more (for security reasons), simple Delete/Revoke it.

All aspects of User management from creating Users, assigning Roles, disabling Users to deleting Users are available to Administrators.

A full list of available options:

Hello User,

Your account has been created and is awaiting activation.

To activate your account, please click on the link below where you can also set your password.

  https://[your-studio-domain].feedhenry.com/studio/activate.html?t=123456789012345678901234

Regards

User Roles are added to user accounts in order to grant them different privileges within the Platform. Users can perform different tasks, and access different sections of the Platform, depending on what roles have been assigned to their account. For example, only a user with the Analytics role can access the Analytics section of the Platform. Only Admin or Domain Admin users have the authority to add or remove user roles to an account.

The Platform has a feature rich Authentication and Authorization mechanism. At the core of this is the concept of Auth Policies. An Auth Policy allows you to define how your Users will Authenticate themselves when accessing your Applications and App Store Apps, and also allows you to define various Authorization checks.

RHMAP supports the following Authentication providers:

RHMAP contains a built-in App Store for distribution of binaries to mobile devices. Integrations for some third-party mobile application management solutions are also supported and listed in the section Third Party MAM/MDM.

Audit logs are available for information about the number of downloads of App App binaries. In order to view the Audit Log, you must first have an existing App.

Click the edit button on one of your existing App Store Apps and then click the "Audit Logs" tab of the Update App page. This will show the current Audit Log entries for this App. The full list of Audit Log entries for all the Apps can be viewed and more comprehensively processed by clicking the "Audit Log" menu item in the "Mobile App Management" menu on the left hand side of the page.

App Store groups (formerly Store Item Groups) can be created to restrict Apps to a particular set of users. Apps can be marked as restricted to a particular set of groups, and only users in those groups will be able to view those items in the app store.

The App Groups Administration section of the App Studio allows an administrator to:

Active Devices can be viewed, assigned friendly names, blocked or marked for data purge. Active Apps and Users on a Device are also available.

Here are all the actions that can be performed:

Aggregated reporting provides a high-level cumulative view of all the reports in your domain over the selected date range. For example, the median number of active devices, or total number of app installations.

There are 4 types of Reporting available for a Project: Device Installs, App Startups, Cloud Requests, and Active Devices. Depending on the configuration of your domain, the Cloud Requests and Active Devices reports may not be available to you.

Each of the report types can be viewed in a number of ways, depending on which chart best shows the data you are looking for. In general, more info on individual chart points and areas is available by hovering over them. If a chart shows multiple items being compared, an item can be toggled on/off by clicking on the name of it in the legend (most charts support this). Chart data can often be exported in CSV, PNG or PDF format by clicking the export button associated with an individual chart.

The from and to date range can be changed for each chart, either by selecting a range using the calendars, or by choosing one of the quick date selections for example, "Last 30 Days", "Last 7 Days", "Previous 30 Days" etc.

The data for these charts is updated daily, so the latest data will be from yesterday.

The Teams and Collaboration section allows you to restrict access to specific features and entities within the Red Hat Mobile Application Platform Hosted (RHMAP).

The functionality in this section includes

Teams are split into two categories

A Team can be created by entering a name and description and selecting the Create Team button.

The Dashboard screen displays the details of the Team. In this screen, it is possible to

The Members section allows you manage the Members of a Team. In this screen it is possible to

The Permissions section allows you to set the Permissions associated with the currently selected Team. All Members of the team will be restricted to the Permissions associated with this team.