11.1 Mobile Channel Configuration & Offline Processing

Mobile Channel Configuration & Offline Processing

Modern enterprise applications must empower a distributed, on-the-go workforce. From insurance adjusters assessing storm damage in remote rural areas to field service engineers repairing utility equipment in subterranean vaults, enterprise users frequently operate beyond the reach of reliable cellular or Wi-Fi connectivity. The Pega Platform addresses this demand through its robust Mobility Architecture and comprehensive Offline Processing capabilities.

For a Certified System Architect (CSA), mastering Pega Mobility requires understanding how native mobile containers interface with core PRPC case lifecycles, how the cloud-based Pega Mobile Build Service compiles production-ready binaries, and how the Offline Synchronization Engine guarantees transactional consistency across intermittent network states.

---

1. Pega Mobility Architecture: Delivery Models

Pega provides two distinct architectural approaches for delivering enterprise applications to mobile devices:

+-------------------------------------------------------------------------+
|                    PEGA MOBILITY ARCHITECTURAL MODELS                   |
+-------------------------------------------------------------------------+
| 1. RESPONSIVE WEB BROWSER ACCESS:                                       |
|    - User accesses application via Safari, Chrome, or Edge on mobile.   |
|    - Zero installation required; instant deployment of server updates.  |
|    - Bound to active network connectivity; zero offline capability.     |
|    - Limited hardware access (restricted background geolocation/push).  |
+-------------------------------------------------------------------------+
| 2. PEGA MOBILE CLIENT (HYBRID CONTAINER ARCHITECTURE):                  |
|    - Native container shell (iOS / Android) wrapping Pega web runtime.  |
|    - Access to native device hardware APIs (Camera, GPS, Biometrics).   |
|    - Embedded local SQLite database for full offline case processing.   |
|    - Background push notifications via APNs and FCM services.           |
|    - Distributed via Enterprise MDM or public App Stores.               |
+-------------------------------------------------------------------------+

The Pega Mobile Client (Hybrid Architecture)

The Pega Mobile Client is an enterprise hybrid mobile container that bridges native operating system capabilities with the Pega web presentation layer.

• Native Wrapper: The outer container runs as native Objective-C/Swift (iOS) or Java/Kotlin (Android) code, providing direct access to device hardware through internal bridge APIs.
• Embedded WebView: The user interface renders inside an optimized, high-performance webview executing modern HTML5, CSS3, and JavaScript.
• Hardware Integration: The native bridge exposes device-native sensors directly to Pega controls, allowing caseworkers to capture geospatial coordinates via GPS, snap high-resolution damage photos with the camera, scan barcodes, and capture customer signatures directly on glass.
• Local Data Persistence: The container embeds an encrypted SQLite database (utilizing SQLCipher) to store rule metadata, data pages, and case state for disconnected operation.

The Pega Mobile Build Service

Historically, compiling native mobile binaries required dedicated local development environments equipped with macOS hardware, Xcode command-line tools, and Android SDK toolchains. Pega eliminates this operational friction through the cloud-based Pega Mobile Build Service (PMBS):

1. Declarative Configuration: Architects configure application branding, security settings, and certificate profiles directly in App Studio.
2. Cloud Compilation: When the architect clicks Build, App Studio securely packages the application assets, themes, and configuration manifests and transmits them to the cloud build service.
3. Signing & Artifact Generation: The build service compiles the native container, applies enterprise code signing certificates (Apple .p12 certificates and provisioning profiles for iOS; .keystore or .jks cryptographic keys for Android), and returns installable binary packages:
   • iOS: Enterprise or Ad-Hoc .ipa (iOS App Store Package).
   • Android: Signed .apk (Android Application Package) or modern .aab (Android App Bundle).
4. Distribution: Administrators download the binaries for testing or distribute them directly to enterprise workforces via Mobile Device Management (MDM) / Enterprise Mobility Management (EMM) solutions (e.g., Microsoft Intune, VMware Workspace ONE) or public app stores.

---

2. Configuring the Mobile Channel in App Studio

Pega adheres to a strict low-code governance model: mobile application configuration is performed entirely within App Studio under Channels and interfaces -> Mobile.

App Studio -> Channels -> Mobile Channel Configuration
├── Branding & Assets (App Icons, Splash Screens, Color Themes)
├── Navigation Structure (Bottom Tab Bar, Navigation Drawer)
├── Gesture Configuration (Swipe-to-Approve, Swipe-to-Reject)
├── Security & Authentication (Biometric Unlock, Session Timeouts)
└── Notification Services (Apple APNs, Google FCM Integration)

App Branding & Visual Identity

Architects customize the native look and feel without writing platform-specific styling rules:

• Application Icons: Developers upload a single high-resolution master image (PNG format, at least 1024x1024 pixels). The Pega Mobile Build Service automatically generates and scales all required asset densities for iOS (@1x, @2x, @3x) and Android (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi).
• Splash Screens (Launch Images): Configures the static branding graphic displayed while the mobile container initializes and loads the local JavaScript bundles.
• Theme & Colors: Centralized Cosmos design tokens govern primary brand colors, top navigation header bars, interactive button highlights, and status bar treatments (light vs. dark contrast).

Mobile Navigation Layouts

Pega provides two primary navigational structures optimized for handheld touchscreens:

1. Bottom Bar Navigation:
   • Renders 3 to 5 persistent tabs at the base of the viewport (e.g., My Work, Search, Notifications, New Case).
   • Ideal for primary microjourneys and high-frequency operational switching. Supports dynamic badge counters (e.g., displaying unread assignment counts).
2. Navigation Drawer (Hamburger Menu):
   • A collapsible side panel accessed via an upper-left hamburger icon.
   • Houses secondary navigation destinations, operator profile settings, application version details, and manual synchronization controls.
3. Quick Create (Floating Action Button):
   • An optional prominent floating button (+) anchored to the bottom-right corner that lets caseworkers instantly instantiate new cases regardless of the active tab.

Gesture Controls: Swipe Actions

To accelerate repetitive operational tasks, Pega enables Swipe Actions on mobile tabular lists and assignment queues:

• Swipe Right: Configured for affirmative, progressive actions (e.g., Approve, Acknowledge, Mark Complete).
• Swipe Left: Configured for negative or administrative actions (e.g., Reject, Transfer, Delete).
• When an operator swipes a list row, visual color-coded action buttons slide into view. Executing a swipe action triggers the underlying flow action or stage transition without requiring the operator to open the full case view.

Biometric Authentication & Mobile Security

Enterprise mobile clients demand rigorous security without compromising worker efficiency:

• Biometric Authentication: Architects can enable native biometric authentication (Apple Face ID / Touch ID on iOS; BiometricPrompt fingerprint/facial recognition on Android).
• Credential Binding: Upon initial enterprise login (via SAML 2.0, OAuth 2.0, or OpenID Connect), the user's encrypted session token or refresh credential is securely stored within the hardware-isolated mobile Secure Enclave (iOS) or KeyStore (Android).
• Fast Unlock: When returning to an open app or resuming after a brief idle timeout, caseworkers unlock the container instantly using biometrics instead of manually re-entering complex enterprise passwords.
• Push Notifications: The mobile channel integrates with Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM). When a case assignment routes to an operator or an SLA deadline approaches, the Pega server dispatches native push notifications that wake the mobile device and deep-link directly into the assignment.

---

3. Offline Processing Architecture & Synchronization Lifecycle

Offline capability enables mobile caseworkers to create new cases, advance existing assignments, execute business validations, and capture rich media while completely disconnected from any data network.

+-------------------------------------------------------------------------+
|                    PEGA OFFLINE PROCESSING ARCHITECTURE                 |
+-------------------------------------------------------------------------+
| [ MOBILE CLIENT CONTAINER (DEVICE) ]                                    |
|   ├── Local Web Engine (Evaluates Client-Side Rules & Views)            |
|   ├── Encrypted Local SQLite Database (SQLCipher)                       |
|   │     ├── Rule Cache (Sections, Data Transforms, Validate Rules)      |
|   │     ├── Offline Data Pages (Reference & Lookup Data)                |
|   │     └── Client Transaction Queue (Recorded Offline Actions)         |
|   └── Synchronization Engine (Manages Upstream/Downstream Delta Sync)   |
+-------------------------------------------------------------------------+
                                    ▲
                                    │  HTTPS (Online Sync Reconnection)
                                    ▼
+-------------------------------------------------------------------------+
| [ PEGA PLATFORM SERVER (PRPC) ]                                         |
|   ├── Synchronization Servlet & Delta Packaging Service                 |
|   ├── Case Lifecycle Engine (Server-Side Rule Execution)                |
|   ├── Conflict Resolution Handler (Optimistic Locking Engine)           |
|   └── System Database (PegaDATA & PegaRULES Schemas)                    |
+-------------------------------------------------------------------------+

Core Components of Offline Processing

1. Local SQLite Database: Embedded directly within the mobile container, this encrypted database stores all assets required to run the application offline: rule definitions, data page records, active user assignments, and the transactional request queue.
2. Client-Side Rule Engine: A lightweight JavaScript execution engine interprets Pega rules locally on the device, executing Client-side Validate rules, Declare Expressions, and Data Transforms without contacting the server.
3. Offline-Enabled Case Types: In App Studio or Dev Studio, architects explicitly enable offline processing on designated Case Types (Case Designer -> Settings -> Mobile -> Enable offline). Only marked case types and designated stages/steps are packaged for offline execution.

The Four-Phase Synchronization Lifecycle

The transition between online and offline states is governed by a strict four-phase lifecycle:

+-------------------+      +-------------------+      +-------------------+
| 1. CLIENT         |      | 2. OFFLINE        |      | 3. ACTION         |
|    PACKAGING      | ---> |    EXECUTION      | ---> |    QUEUEING       |
| (Download Rules & |      | (Local Data Entry |      | (Store in Device  |
|  Data Pages)      |      |  & Validations)   |      |  SQLite Queue)    |
+-------------------+      +-------------------+      +-------------------+
                                                                │
                                                                v
                                                      +-------------------+
                                                      | 4. RECONCILIATION |
                                                      |    & CONFLICT     |
                                                      |    RESOLUTION     |
                                                      +-------------------+

1. Phase 1: Client Packaging (Initial Sync & Refresh):
   • When the user logs in while connected to the network, the server's synchronization service packages application metadata into a compressed manifest.
   • This package includes: whitelisted UI Views/Sections, flow metadata, client-executable rules (Data Transforms, Validate rules), offline-enabled Data Pages, and all pending assignments assigned to the operator (pyWorklist).
   • Assets are cached locally in the device's SQLite store.
2. Phase 2: Offline Execution (Disconnected Operation):
   • When the device loses network connectivity, the Pega Mobile Client automatically switches to offline mode.
   • The caseworker can instantiate new offline-enabled cases and complete assignments.
   • The local engine generates temporary case identifiers (e.g., OFFLINE-1695289123456) and persists form entries directly into the SQLite database.
   • Media attachments (camera photos, voice notes, signatures) are staged locally in device storage.
3. Phase 3: Action Queueing:
   • Every completed flow action, stage advancement, or case creation event is serialized as an atomic transactional request in the local SQLite Action Queue.
   • Requests are sequenced in strict chronological order and maintained persistently across app restarts.
4. Phase 4: Server Reconciliation & Conflict Resolution:
   • As soon as the device regains network connectivity, the synchronization engine initiates an upstream sync session.
   • The queued actions are transmitted sequentially to the Pega server via RESTful synchronization endpoints.
   • The server PRPC engine re-executes each transaction in the context of the live case, evaluating server-side business rules, executing post-processing data transforms, running SLAs, and committing data to the PegaDATA schema.
   • Temporary offline case IDs are replaced with permanent enterprise case identifiers (e.g., C-10492).

Conflict Resolution & Optimistic Locking

Because multiple caseworkers or automated background processes might modify a case simultaneously, offline transactions face potential concurrency conflicts:

• Optimistic Locking: Pega tracks the case commit revision counter (pzSaveCounter / pxCommitDateTime). If another user modified the case on the server while the mobile user was offline, the server flags a locking collision during reconciliation.
• Resolution Mechanics:
  • If fields updated offline do not overlap with server changes, the Pega engine automatically merges the delta changes.
  • If mutually exclusive conflicting changes occur (e.g., a supervisor rejected a claim on the server while the field adjuster approved it offline), the synchronization request halts.
  • The failed transaction is logged, and the case is routed to an administrative workbasket (such as pyOfflineConflicts) for manual supervisor adjudication, preventing silent data corruption.

---

4. Restrictions, Data Pages & Offline Development Guardrails

Designing for offline mobile requires strict adherence to architectural guardrails. Features that rely on continuous server-side stream processing or live network queries cannot function in a disconnected container.

Offline-Enabled Data Pages

Data Pages provide the foundational reference data for mobile forms (e.g., product lists, medical diagnostic codes, geographic territories):

• Scope & Mode: Data pages intended for offline use must have an Application or Thread scope and must be configured in Read-Only mode.
• Offline Declaration: In the Data Page rule form (or App Studio data model settings), the architect must check Enable offline. This flags the data page for inclusion in the mobile client packaging manifest.
• Payload Size Control: Large datasets consume excessive device memory and prolong initial sync times. Architects must use parameterized data pages or targeted filter criteria to restrict offline data packages to the minimal subset required for field work.
• Prohibited Sources: Data pages with direct live connector sources (such as a live SOAP connector querying an external mainframe on every access) cannot run offline. Offline data pages must source from local lookups, cached records, or savable configurations pre-populated during online packaging.

Supported vs. Unsupported UI Controls

Logic & Processing Guardrails for Offline Case Types

• No Procedural Server Activities: Flow actions executed offline must never reference procedural Activity rules (Rule-Obj-Activity) for pre- or post-processing. Offline logic must rely exclusively on Data Transforms (Rule-Obj-Model) and Validate rules (Rule-Obj-Validate).
• No Direct Outbound Integrations in Steps: Steps that trigger outbound REST/SOAP connectors to third-party enterprise services must not reside in offline-enabled stages. Route cases through offline-enabled stages for data capture, and position automated integration steps in subsequent online-only stages executed by the server.