This is the first of a 4-part discussion on my journey with delivering a mobile app using Pega Mobile Client 8.5.x for a Pega 8.4.x platform/strategic application.  While some resources (human and otherwise) existed for Mobile Client 7.x apps, finding the same for  8.x  was a bit of a challenge.  From how to best structure the application and ruleset stack to implementation, build and delivery of the mobile app many questions were presented that were not in any documentation or collaborative sites. Hopefully this series will help fill some of the missing pieces together for other Pega peeps…

The topics to be discussed are:

Mobile Client: Part 1, Development Application Stack and Mobile Channel Interface

Mobile Client: Part 2, Design and implementation for mobile app content

Mobile Client: Part 3, Testing and Release Management

Mobile Client: Part 4, Additional topics/tips/tricks

Part 1 details the application and ruleset stack which enabled separate release pipelines for the mobile app and its desktop version as well as making it easy to develop with a large team and multiple branches.  Additionally, the Mobile Channel Interface landing page and build configuration will be discussed.

Part 2 will be more interesting as a deep dive into how to implement the content of the mobile app will be done.

Part 3 will cover the release management of the mobile app with nuances particular to using mobile client. It will also discuss different options for testing the mobile app.

Part 4 will cover topics like security (especially questions raised by client around Android permission settings) as well as tips and tricks for the mobile UI.

Scenario

Platform:  Pega Cloud 8.4.2, Pega Customer Service, Pega Mobile Client 8.5.x

A Pega CRM/CS application requires a mobile version of its Employee Portal which allows employees to create and monitor internal service requests.  Access is online only and SSO is used for authentication.

Solution

Using Pega Mobile Client both iOS and Android mobile apps were built and distributed to end users.  Fig. 1 shows the final app delivered.  This is the first of a 4-part series to discuss how this was achieved.

Figure 1:  CMS Mobile Client app

Development Application Stack

For this discussion we will refer to the main CS application as CMS, its dev version is CMSDev and the dev version of the mobile client app is CMSDEVMobile

When creating a mobile channel interface the following 3 rules are autogenerated:

• An instance of Rule-Channel-Mobile rule is created which holds the landing page for the mobile channel (Fig. 2)
• Navigation rule which represents the menu items added to the channel configuration (Fig. 3)
• A portal rule for the mobile app.  This portal must be part of the Access Group of mobile users (more on that later).

During development it was discovered that the Channel and Navigation rules need to be in an open ruleset (not a branch). See Fig. 4.  If not changes to the rules could not be saved, or even worse if any another open ruleset existed in the stack they would get saved there causing problems.  It is also best to add/remove/modify the Menu items in the Channel rule.  Then the Navigation rule can be used to set the action(s) that each menu item will perform. Adding a menu item in the navigation rule does not create it in the channel rule.

These observations led to the application and ruleset stack for CMSDEVMobile illustrated in Fig. 5.1.  It has the CMSChannels ruleset which has the Channel and Navigation rules of Fig. 3 and is built on the main CS application, namely CMS_DEV.  As Fig. 5.2 shows the CMS_DEV application is as expected built on CMS and has the additional CMSMobile ruleset.  It also uses branch development.

The CMSMobile ruleset holds only those rules that are specific to the mobile app or specializations of rules from CMS rulesets. Ideally this ruleset would be one of the CMSDEVMobile application rulesets instead of the CMS_DEV application. However, since the development of the CMSMobile app often involved simultaneous changes to the underlying CMS application rules, using the same branch for all rulesets was desired. Unfortunately putting CMSMobile ruleset a layer up in CMSDEVMobile does not allow you to save the CMS_DEV application rule as it is not aware of a branch of CMSMobile since CMSMobile is not part of its stack!

This is not a problem during the final packaging and release though of CMS Mobile.  As Fig.6 illustrates (and Part 3 of this series will further elaborate) the CMSMobile ruleset is simply added to the CMSMobile application rulesets for final deployment. Furthermore, it does not cause any issues for CMS_DEV as none of the rules in CMSMobile are used in the CMS_DEV application.

Figure 2:  CMS Mobile interface landing page

Figure 3:  CMS Mobile navigation rule.

Figure 4:  Open CMSChannels ruleset.

Figure 5.1: Development Application rule for CMS Mobile.

Figure 5.2: Development application rule for CMS application.

Figure 6:  Production Application rule for CMS Mobile.

Mobile Channel Interface and Build

The Content tab was discussed above.  Moving on to the Configuration tab:

Mobile app name - what will appear on the phone under the app icon

Role - this dropdown list is a list of all Access Groups that are using CMSDEVMobile.  When the mobile app is built this Role needs to be correct for the intended users. Only users that have the selected Access Group (Role) will have access to the version of the app built with this Role. Please see Fig. 6 and 7 below for reference.

Figure 7:  Configuring role for mobile app.

Figure 7: Access group corresponding to CMS Mobile Users Dev role.

Security Tab

OpenID and SAML were both used and tested as authentication services.  Configuation is straightforward as Fig. 8 illustrates.  A dropdown list of available auth services is presented.  NOTE:  Using SSO a redirect page is still observed on mobile app.  This is expected behaviour.

Figure 8: Mobile security configuration.

Hosting

If a DNS server exists for an environment use this as the alternative host.  It simply redirects the Pega app server URL for the given environment the mobile app is built.

Figure 9:  Hosting URL configuration.

Building the Mobile App

1. The Android certificate required is simply a p12 cert that can be generated commandline.  It is not created in the keystore and one has to be imported in each environment. This and a chosen bundle id are all that are required to build the necessary .apk file for installation on an Android device.
2. For iOS a signed certificate is required to build and install on iOS.  If the customer does not provide a signed certificate then mobile preview is the only option for viewing and testing.  That said, it may be possible to get a signed dev certificate from GCS if the customer won't give one which will allow for building and installing the app on real device. NOTE: This is recommended only for testing purposes; signed cert should be removed from the environment after testing is completed.

To build either version a licence must be purchased by the customer to use mobile client.  With this GCS can provide the required account details for Pega Mobile Build Service.  Once obtained add these details to Admin Studio->Mobile->Settings:

In Dev Studio an Authentication Profile already exists which will use the details provided in Admin Studio.  No modifications are required:

That concludes the first of this 4-part series.  Stay tuned for more!