Offline-enabled mobile apps allow users to create cases and work on assignments while their mobile

devices are disconnected from the network.

You can use a decision shape with a Boolean expression—it does not require server processing.

Shaking the device opens the Client Clipboard.

Offline processing
Using offline-enabled apps, mobile users can create cases and process assignments while working
offline. Data synchronization between the mobile device and the server occurs automatically when
the mobile device is online.

App end users must complete an initial synchronization before using the offline capability.

They can create a case, perform work on an assignment, return completed assignment to the
worklist, and begin working on the next available assignment.

Offline-enabled mobile apps save all work to a queue. A status indicator keeps track of the number
of items added to a queue.

When the network connection state changes and the device comes back online, data
synchronization is triggered automatically for the offline-enabled application, and any saved data is
updated to the server. An indicator displays whether you are online, offline, or currently
synchronizing with the server.

The indicator in the offline-enabled application does not display SYNCING or SYNCED if
synchronization takes less than four seconds or when the server is unavailable. The indicator also
does not display the FAILED status when the network has been disconnected or the server becomes
unavailable; it only displays this status when another type of data synchronization issue has
occurred.

Data synchronization also occurs if the device is online and five minutes have passed since the last
data synchronization operation, or when a user submits an assignment or creates a new case.

] When using an offline-enabled mobile app, what happens when a user saves work on an
assignment?

The saved work joins a queue for synchronization. When the mobile device connects to a network,
the application server processes the queue.

 Enabling offline support for users by configuring the appropriate access groups

 Enabling the appropriate case types for offline processing

to enable access group caching, on the Advanced tab of the access group, in the Offline
Configuration section, select the Enable caching check box. This option is displayed after you
select the Enable offline support check box.
Use a case worker default portal

Make sure that the mobile device displays a user portal. On the Definition tab of the access group,
in the Available portals section, set the default portal to a user portal such as pyCaseWorker.

You can create your own portal for offline use. As a best practice, customize
the pyCaseWorker portal. This portal contains design elements that are optimized for offline use with
a Pega mobile app.

How do you enable offline access for an access group?

You select the Enable offline support check box on the access group's Advanced tab.

Enable offline processing for case types

In the Case type column, click a case type link to open the case type in the Case Designer. On the
case type Settings tab, select General. Select the Enable offline check box to enable offline
capability for a case type.

Enable offline capability for at least one case type in an application.

How do you enable offline access for a case type?

On the case type Settings tab, in the General section, you select the Enable offline check box.

Optimistic

Unless otherwise required(Если не требуется иное), use optimistic locking for case types that are
enabled for offline processing. When a user opens a case in offline mode, the system cannot obtain
a lock on the case. When the mobile app is synced back to the server, the system attempts to obtain
a lock on updated cases. Optimistic locking helps avoid conflicts if the updated cases had been
worked on by other users.
What requirement must a case type satisfy before you enable the case type for offline processing?
The case type must be initialized and instantiated with the pyStartCase starting flow.

Process design considerations

Pega applications rely on the server for various UI and processing features. An unavailable server
disrupts those features. For example, when a user submits a case for approval, the process may use
a decision shape and decision table to determine where to route the case. The server normally
performs decision and routing processing. That processing cannot start in offline mode. In addition,
the synchronization process can affect performance.

 Make essential elements available offline for a consistent user experience.

 Ensure that synchronizations are fast and efficient.

What are the two key considerations when configuring a mobile app for offline use?
You consider which essential elements should be available offline and how to ensure
synchronizations are fast and efficient.

How to create a cache manifest for offline

use
To enable users to continue interacting with mobile apps and documents even when their network
connection is unavailable, you can provide a cache manifest that lists the files needed for the mobile
app to work offline. The cache manifest is a simple text file defined using an HTML rule form
named pyCustomAppCache. Each line in the cache manifest refers to a single static resource such
as an HTML file, an image file, a CSS file, a font file, or a JS file.

The cache manifest is different from the application rules cache created when you enable offline
support for an access group. The application rules cache includes common application rules used by
all the operators in the access group. The cache manifest is a list of resource files referenced in
the application rules.

What types of resources do you add to the cache manifest?

Cache manifest resources include images, icons, and font families.

To define the cache manifest, save a copy of the pyCustomAppCache record to your application
ruleset.

Do not change the context of your copy of pyCustomAppCache. The record must be applied to Data-
Portal.

Cache manifest syntax

To add a resource file to the cache manifest record, add each resource file on a separate line.

For example, upon inspecting the http request in the DOM, the requested resource is displayed, in
part, as <img src="webwb/Custom-Logo_1662150348.svg!!.svg">. Add the resource file to
the cache manifest using the <pega:binaryfile> element with the name, app,
and keepCase attributes:

<pega:binaryfile name="Custom-Logo.svg" app="webwb" keepCase="true"/>.

The value you specify in the app attribute is the value specified in the App Name (Directory) field of
the binary file record in . In the DOM, this value is the nnnn/ string preceding the file name.

For example, upon inspecting the http request in the DOM, the requested resource is displayed, in
part, as <img src="webwb/webwb/Custom-Logo.svg">. Add the resource file to the cache
manifest using the <pega:binaryfile> element prefaced with webwb/:

webwb/<pega:binaryfilename="Custom-Logo.svg"app="webwb"keepCase="true" />.

If the name of the requested resource file is the name of the resource file, enter the path and name
of the file as displayed in the DOM. For example, upon inspecting the http request in the DOM, the
requested resource is displayed, in part, as <img src="webwb/Custom-Logo.svg">. Add the
resource file to the cache manifest using:

webwb/Custom-Logo.svg.

How to manage data for offline use

You identify and sync the rules specific to the mobile app. You manage the rules to sync with
whitelists and blacklists.

A whitelist is a set of rules requiring synchronization between a mobile app and the server.
A blacklist is a set of rules that is not synchronized between a mobile app and a Pega application.
You update the whilelists and blacklists for an application on the Offline rules tab of the Mobile:
Offline landing page. To access the Mobile: Offline landing page, open the Designer Studio menu
and select Mobile > Offline.

What is the difference between a whitelist and a blacklist?

A whitelist contains rules that must be synchronized between a mobile app and a server. A blacklist
contains rules that are not synchronized.

Manage whitelists to synchronize data rules

By default, the offline mobile app includes in any synchronization the data transforms, data pages,
field values, and validate rules used in the UI. Rules not referenced directly in the UI are left out
of the synchronization. This may impact functionality of the mobile app. To include rules in the
synchronization, add the rules to a whitelist.

For example, automatic synchronization excludes rules called from a script using a Run Script action
or from a custom Javascript function.

Pega provides a set of four whitelists for you to customize for your applications. Each whitelist
manages instances of a specific rule type: data pages, field values. data transforms, and validate
rules.

To add or delete a rule from a whitelist, select the appropriate link to open an HTML record that lists
the rules to include. Каждый рул, своей отдельной строчкой.

Copy each record to your application ruleset. The record must be applied to @baseline. Это
отдельные HTML рулы, должны лежать в @baseclass

Manage blacklists to exclude data pages from synchronizations

You use a blacklist to exclude specific data pages from mobile app and server synchronization.

Data pages used on both the mobile app and the server require synchronization. Those data pages
belong on the whitelist if appropriate.

Manage delta-sync blacklists

You use the delta-sync blacklist to exempt from a delta-sync a data page that contains a large
amount of data that changes infrequently. Language dictionaries fall into this category.

By default, a mobile app performs a full synchronization when a user logs in for the first time, or
when an application developer forces a manual sync to push changes to mobile users.

After an offline device comes back online, the mobile app performs a delta-synchronization, or delta-
sync, with the server.

A delta sync incrementally exchanges smaller amounts of data to reflect user activity, such as
performing assignments or creating cases. Delta-syncs improve mobile app performance by
reducing the data exchanged between the mobile app and the server.

You can further improve performance of the delta-sync process by exempting data pages that
contain a large amount of data that changes infrequently. Use the delta-sync blacklist when record
to specify the data pages you want to exempt. The system skips analysis of blacklisted data pages
during the sync.
You can further improve performance of the delta-sync process by exempting data pages that
contain a large amount of data that changes infrequently. Use the delta-sync blacklist when record
to specify the data pages you want to exempt. The system skips analysis of blacklisted data pages
during the sync.

For example, you may add a data page listing countries of the world to a delta-sync blacklist.

To update the delta-sync blacklist, select Modify delta-sync blacklist on the Offline rules tab to
open the when record. Save a copy of the record to your application ruleset. The record must be
applied to Embed-SIIP.

Add a condition for each data page to exclude from the delta sync on the Advanced tab of the when
rule.

You can also choose to skip backward chaining to increase the sync speed. Select Skip backward
chaining on the Advanced tab of the delta-sync blacklist when rule.

How is a delta-sync difference from a full sync?

A full sync forces the mobile app to overwrite an entire rule or data record. Delta-syncs incrementally
exchange smaller amounts of data to reflect changes.

How to manage reference data with large

data pages
Using large data pages to store reference data in your application can help improve the performance
of a mobile app. Only individual records of the large data page that have changed are synced, not
the entire set of records. Large data pages also enable more efficient memory management. Only
records needed to render a specific screen on the mobile device are loaded to the device's memory,
leaving the remaining parts of reference data in the device's permanent store.

Large data pages are created using the standard data page record type. After the data page is
created, you declare it as a large data page by adding it to the pyDataPageWhiteListForOffline rule.
Large data pages can be automatically sourced from report definitions.

Large data pages can also be sourced from a connector, activity, or data transform, but a custom
JavaScript populator function is required.

Before you configure the data page, confirm the value of

the datapages/addReportDefinitionToDatapage Dynamic System Setting on the system. To source
the data page from a report definition, set the value to true. If the setting is not present on the
system, Pega assumes the value is true. If the setting is false, create a custom JavaScript function
to source the data page.

In the report definition used as the data page source, add the following two columns in addition to
the columns needed to retrieve the reference data:

 pyModificationDateTime – This column returns the time when the large data page was previously
synchronized to the client.

 pyIsRecordDeleted – This column returns true only for records that have been removed.

After you create the data page, declare it as a large data page. To do this, edit the whitelist for
the List of data pages that are available offline but are not referenced directly in the UI. Add the name
of the data page followed by ;large. For example, to declare the data page D_FieldMappings as large,
enter D_FieldMappings;large in the HTML source.
In the pyDataPageWhiteListForOffline rule, declare both the target large page as well as any source
large data pages (if applicable). Each large data page is defined as a separate entry in this rule.
Ensure that every large data page always contains at least one record.

What are the two key benefits of using large data pages for reference data?
Performance and memory management improvements are the two key benefits of using large data
pages for reference data.

You can add or delete locales for offline use by selecting Modify locales list from the Mobile Offline
landing page. Selecting Modify locales list opens the pyLocalesListOffline rule. On the HTML tab,
set the format to generate for, the supported browser, and accessibility.

Where do you configure the locales for offline apps?

You use the Modify locales list link from the Mobile Offline landing page to edit
the pyLocalesListOffline rule.

How to manage requestor pooling for a

mobile app
Pega Platform provides a Service Package specifically for offline data synchronization. The Service
Package contains settings that define the requestor pool. The requestor pool is a set of requestors
reserved for use by the services in the Service Package. Requestor pooling often improves the
performance of a service. Requestor pooling enables requestor reuse, shares allocated resources,
and eliminates server wait time for requestor creation.

Requestors associated with a pool belong in one of two categories:

 Idle requestors are currently in the pool, waiting for a service request.

 Active requestors are currently out of the pool, managing service requests.

The Service Package contains pooling settings that let you adjust the maximum number of idle
requestors, the maximum number of active requestors, and the maximum time the system waits for
an idle requestor.

What are the three ways that requestor pooling improves service performance?
Requestor pooling enables requestor reuse, shares allocated resources, and eliminates server wait
time for requestor creation.

The Maximum idle requestors setting defines the size of the pool. To allow an unlimited number of
idle requestors by keeping them until they time out, set Maximum idle requestors to -1.

The Maximum active requestors setting defines the maximum number of concurrent requestors to
allocate to the service. To allow an unlimited number of active requestors, and eliminate wait time,
set Maximum active requestors value to -1. If requestor pooling is disabled, set Maximum active
requestors to 1.

The Maximum wait (in seconds) specifies how long the system waits for a requestor to return to
the pool when a service request arrives and the number of active requestors has reached
the Maximum active requestors value.

Which three pooling settings can be configured on the Settings tab of the Designer Studio Offline
landing page and the Offline Service Package rule?
The three pooling settings are Maximum wait (in seconds), Maximum active requestors, and
Maximum idle requestors.
Notifications
All Pega applications can send users automatic notifications - when an assignment is ready, when
an SLA is violated, and as a programmatic user notification when using a Utility or Send Email shape
in a process flow.

When you build a mobile app in Designer Studio you can set up automatic push notifications to a
mobile device. These notifications can indicate that an action might be required, a status update is
available, or a case was approved. Push notifications sent from the Pega Platform are delivered to
all the devices to which a user is logged in to your custom mobile app, regardless of the device
platform.

Communication is one-way from the app to the user's device. Users can act on, but not respond to
the notification.

Which notification feature is specific to mobile apps?

Push notifications are the notification feature specific to mobile apps.

Case-event notifications extend existing notification behavior to a mobile delivery model. Case-event
notifications are specific to case processing events such as SLAs violations and new worklist
assignments. You can send an event announcement to a subset of a user group and verify the
message date and time. You can also review the list of intended recipients, along with detailed
message status for each of the recipients.

Case-event notifications extend existing notification behavior to a mobile delivery model. Case-event
notifications are specific to case processing events such as SLAs violations and new worklist
assignments.

Status update notifications are similar to case-event notifications. Status update notifications provide
flexibility because you determine when to send the notification. Status update notifications provide
information on a task. For example, you can notify a user of purchase request approval, or that an
expense report is in review.

Pega Mobile Web applications do not support push notifications.

Which tool do you use to manually push a notification to users?

You can use the Push Console to manually push notifications to users.

When you design push notifications, consider the notification trigger events and user groups.

Push notifications are only available when creating a mobile application using either the Pega Mobile
Client, Mashup SDK, or Connect SDK. Push notifications are not available in mobile apps accessed
through Pega Mobile Express.

What should you consider when designing notifications?

The purpose and target audience of each message
Manual notifications

You use the Push Console to send manual notifications. You also use the Push Console to test
whether your application can send push notifications. You can send notifications to all users or to
specific users.

reate the recipient list, considering the user group.

Where is the Push Console located in Pega 7.3?

The Push Console is on Push Notifications tab of the mobile app. You access the mobile app from
the Channels and interfaces page.

Automatic notifications

Pega applications can notify users of case events and case status by sending automatic push
notifications to mobile devices.

Case-event notifications include SLA escalation actions and new assignments in a user's worklist.
Using the Settings tab, you enable notifications on the case type. Select the Enable push for goal
and deadline notifications option to send push notifications for an SLA that includes an escalation
action to send a notification to the assignee or manager when a goal or deadline interval
expires. Select the Notify user when assignment is routed to worklist option to send a push
notification when an assignment is added to a user's worklist.

Push notification for a goal or deadline interval are only sent if the SLA uses
the NotifyAssignee or NotifyManager escalation action. Other escalation actions do not cause the
application to send a push notification.

You configure general status notifications using the Push Notification smart shape. You can add the
Push Notification smart shape anywhere in a process. The notification can go to a single user or
group of users.

Other than escalation actions in SLAs, what are two options for configuring automatic push
notifications?
Adding a Push Notification smart shape to a case lifecycle and configuring the Notifications tab in
Pega Express.

DEPLOYING A MOBILE APP

Pega Mobile Web
Pega Mobile Web assumes a continuous connection to the server. Mobile devices are transportable,
and they are sometimes offline. This lack of continuous connection is the limitation of Pega Mobile
Web browser deployment. Another limitation is the inability to use native device features.

What is a limitation of the Pega Mobile Web deployment model?

The Pega Mobile Web does not have access to native device capabilities, such as push notifications
and offline functions. Another limitation is the continuous connection requirement.
Pega Mobile Express

You can access applications using Pega Mobile Express. Pega Mobile Express provides offline
processing in addition to the native rendering of Pega Mobile Web. In other words, users can create
cases and complete assignments while offline. When the device is back online, Pega Mobile
Express synchronizes with the Pega Platform application.

Pega Mobile Express lacks the ability to customize branding and support push notification and is
best suited for demonstrations and limited rollouts.

Pega Mobile Client

You use Pega Mobile Client when the business requires a stand-alone custom branded mobile app
with access to device functions. The Pega Mobile Client provides all the capabilities of the Pega
Mobile Express, plus icon and splash screen customization, custom module importing, and push
notifications. The Pega Mobile Client enables fast mobile app building using adaptive design. Pega
applications are deployed to mobile devices in a container designed to interact with device features,
such as the contact manager or camera.

called hybrid mobile apps, or hybrid container apps.

The Pega Mobile Client API includes a hybrid application API consisting of JavaScript functions that
support interactions with device features. When building a custom mobile app, Pega Mobile Client
translates the API functions into OS-specific functions that call in the hybrid container, providing a
seamless native experience for iOS, and Android device users.

How does the Pega Mobile Client API interact with Pega Mobile Client?
Pega Mobile Client translates the API functions into OS-specific functions that call in the hybrid
container, providing a seamless native experience for iOS, and Android device users.

Pega Mobile SDK

Pega supports the ability to add Pega Platform functionality to existing mobile devices through
the Pega Mobile SDK

SDK apps provide the same functionality as custom mobile apps. However, another mobile app is
available to act as the front end, presenting the application to the user

When the business requires embedding a Pega process and the Pega UI into an existing mobile
app, you use Pega Mobile Mashup SDK

When the business requires Pega 7 back-end services delivered through a native app, you
use Pega Mobile Connect SDK. In this approach, the UI is entirely built in the native mobile
application. Pega Mobile Connect SDK contains the integration between the native app and Pega.

When do you configure apps with Pega Mobile Mashup SDK?

You configure apps with Pega Mobile Mashup SDK when the business requires Pega apps
embedded in native applications.

How to build a custom mobile app

To configure access to the build server, update the pega/mobilebuild/baseurl Dynamic System
Setting with the URL of the build server. Then update
the MobileBuildServerAuthentication authentication profile with the name and password for your
account.

Another requirement is the signing certificates for the iOS and Android platforms. Pega requires
uploading the platform signing certificate before building and distributing a custom mobile app.

What are the two actions required before you build a custom mobile app with the Pega Mobile
Client?
Configure your Pega installation to access a build server to generate the mobile app and obtain
signing certificates for the iOS and Android platforms.

The options you can use to distribute a custom mobile app are:

 Adding a banner for mobile app download

 Pushing mobile apps to AMP Manager

 Distributing mobile apps as binary files

 Generating a QR code for mobile app download

Regardless of the option you choose, to distribute your app, use Designer Studio to select your
application, click Channels and interfaces, select the custom or SDK mobile app icon, and click
the General tab.

Log Files

Log files help you to capture information and events on both the Pega Platform application side and
on the mobile device side. Extracting useful information from your log files is critical to successfully
building and deploying your mobile app.

To capture log files, you first enable debugging for your mobile device on the Pega Platform
in Channels and interfaces. Typically testing and debugging is done before distributing the app to
end users. set the logging level to Debug

Debugging may only be enabled for custom mobile apps, not SDK mobile apps.

The mobile device log files are accessible from a link on the Mobile: Offline landing page on Pega
Platform. On the Mobile: Offline landing page, select the Retrieve device log tab. Select the user
whose device log you wish to view under Operator ID.

If device logs are available, you can select Log Files to view the links to the logs.

The system sends a request to the mobile app to retrieve the device logs during the next data
synchronization.

Using the Client Clipboard

ou use the Client Clipboard to examine the Client Cache and Client Store when the mobile device is
offline.

The Client Clipboard is available only in offline-enabled apps built with the debugging mode enabled.
Select whether to view data from the Client Cache or the Client Store. The Client Cache holds short-
term transactional objects, and the Client Store is the long-term collection of items that should be on
the device.

Running an offline-enabled app populates the Client Store database and Client Cache with data
pulled from the device after the app connects to the server. All data elements and screen flow
information remain in the Client Store when the app is offline. Synchronization updates the data.
Closing the app clears the Client Cache.

Using the Client Clipboard requires:

 Enabling debugging for the app,

 Rebuilding the app with debugging enabled,

 Deploying the app to the mobile device, and

 Shaking the device to open the Client Clipboard.

How can you view the data on your offline-enabled mobile device to troubleshoot when it is offline?
You can use the Client Clipboard to view the Client Cache.

Viewing and clearing local storage

To help troubleshoot your offline-enabled custom mobile app you can view all the items that are
currently stored in the mobile app queue (local storage). From the Settings menu, select Local
storage. You may also clear local storage by selecting Clear storage and a full synchronization is
automatically started for the app.

By checking the Simulate offline checkbox, you can troubleshoot your offline-enabled application
without disconnecting it from the network.

From the system info pages of a custom mobile app, you can also clear any actions that are in the
sync queue. Clearing the sync queue allows you to discard any failed actions while working in offline
mode.

From the Settings menu, select Sync queue, then Clear rejected actions to delete all actions from
the sync queue that have been rejected by the server.

If your mobile device had trouble syncing with your Pega Platform application, what could you try?
On your mobile device, select Settings > Sync queue > Clear rejected actions to discard any
failed actions

Monitoring actions using Remote Tracer

Another useful diagnostic tool is the Tracer tool. You can use the Tracer to test and debug a variety
of issues, including your mobile application.

Developers can use a web debug proxy such as Fiddler to examine traffic between the mobile app
and Pega Platform, as well as Android Studio and XCode.

testting

The difference between profiling a regular mobile app and an offline-enabled mobile app is that you
call the offline packaging request.
Performing a load test of an offline-enabled mobile app requires the use of a third-party load-testing
tool, such as HP LoadRunner, and a proxy server.

To load test an offline-enabled custom mobile app, measure the time that was spent during
packaging. You obtain this information by examining the server log. First, enable the debug setting
for
the com.pega.pegarules.session.internal.mgmt.autostreams.packaging.PackageR
untime mask. Click Designer Studio > System > Operations> Logs > Logging Level Settings.

You can use the server and device log files to identify the items that take the most time to package,
the amount of time spent on full and delta syncs, and the number of items packaged.

What tools are required to perform a load test of an offline-enabled mobile app?
A third-party load-testing tool, and a proxy server