Offline architecture overview

All offline-enabled content goes through the offline-synchronization synchronization service regardless of network connectivity. All synchronizations can happen across multiple client-server HTTP handshakes. If any given synchronization fails to complete, it retries and resumes on the next available connection. Content that is not offline-enabled does not pass through the offline synchronization service.

Full synchronization

When users first sign into a mobile application, and there is offline-enabled content, the mobile client calls the synchronization service, and it sends all the logic and data necessary to perform those actions offline. Whenever there are changes to logic rules, an administrator can push a full synchronization via Admin Studio™. For some mobile users, this action is instantaneous, but because the user must log in to the app, these updates can also happen days later.

Delta synchronization

After the initial, full synchronization, the system considers follow-up synchronizations to be delta synchronizations. Only the changes in the system that have occurred since the previous synchronization go to the client. Large, dynamic data sources can be implemented by Pega Developers such that only updated data is sent.

You can run offline-enabled tasks only with the Pega Mobile Client for iOS and Android or the Pega Client for Windows. These clients include secure, persistent storage, authentication controls as well as the functionality to process offline actions. The offline actions that the users perform go into secure, persistent storage, and the client processes the actions by using the logic and data available on the device. The device keeps the user actions until the server confirms that it receives them.

In the following image, click the + icons to learn more about the Offline Data Synchronization process:

All offline-enabled Cases must use optimistic locking. Optimistic locking indicates that any user with access to a Case can update a Case at any time. In this scenario, the first user to complete the Case will have their changes committed. However, if the Case remains incomplete, the last user will have their changes committed. All changes by all users are displayed in the audit history of the Case. It is up to the design of the Case to determine if and how conflicts are handled. 

Synchronization issues

If a user tries to complete a Case that is no longer available, the system saves the data to a specific issue workbasket. Users can report on this data and retrieve it if necessary.

Reconciliation

If a user is currently working on a Case, and it updates on the server, the system reflects the change mediately when the update reaches the device. If the Case is open on the screen, it refreshes with the updated data.

Check your knowledge with the following interaction: