Push Service (Client)

The UBIK^® push service is a mechanism to ensure the clients always receive certain information pushed by the push web service.

The client part of the push service runs in the background, independently of the content service. When active, it periodically polls the push web service for new updates. Once such updates are received, the clients react accordingly based on the information contained in them. Some examples are updating content and switching clients into different sync modes.

The following settings are used in order for the push service to function properly.

Changing the value of "ActivatePushService" could potentially start/stop the push service.

As mentioned, a background polling service is responsible for communicating with the push web service and getting push updates. This service is started once users successfully log in and will keep running until they are logged out.

There are two types of push communication involved here, namely

• Updating push parameters;
• Updating push data

Updating push parameters

There are different push criteria that define which data should be pushed to which clients. As a result, the push web service requires a set of push parameters which can be used to check against these criteria.

The client polling service, in order to always get the intended push data, has to keep this set of parameters up-to-date and use them in the push data updating.

During maintaining the push parameters, the following information might be collected by UBIK^® and used as the parameter values:

• User name;
• Device ID;
• UBIK^® application name and context name;
• Current location;
• etc.

Updating push data

The main job of the service is to get push data once it's ready to be pushed from the server. And the service is not interested in getting push data it has received before.

To achieve this, the service repeats (e.g. every 10 seconds) the following tasks:

1. Frequently sending the client's actively maintained push parameters (types and values) and the last push status ID to the push web service;
2. Recording the status ID in the received push update as the last push status ID;
3. Passing on the data in the received push update so that UBIK^® can process it.

Notification for Received Push Data

After receiving push data, UBIK^® processes it and potentially performs different follow-up tasks.

The currently known types of push data and their intended client actions are described in the following subsections.

Updating content hierarchy

Upon receiving such push data, UBIK^® tries to update the content hierarchy as the parameters in the push data indicate. This can lead to various scenarios such as:

• Update of a single object;
• Removal of a single object;
• Update of a single object and all its children;
• Update of root objects;
• Update of infrastructures;
• etc.

In case there are uncommitted changes involved in the update, UBIK^® performs the update while preserving the changes. This applies for all the sync modes.

Updating Meta Definitions

Error Notification for Conflict during Updating Meta Definitions

Upon receiving such push data, UBIK^® tries to update all the Meta Definitions. If the update is successful, root objects and infrastructures are then updated as well, and UBIK^® is automatically switched to the automatic sync mode.

In case there are uncommitted changes, the followings apply depending on the sync mode at that point of time.

• Automatic mode: Changes are committed automatically and the updates are done afterwards;
• Other modes: Updates can not proceed (changes will be lost otherwise) and an error notification is shown.

Updating device status

Error Dialog for Conflict during Preparing for Maintenance

Upon receiving such push data, UBIK^® tries to update the status of the device. Currently, the only known status is maintenance. This means the server will be under maintenance and unreachable soon. Therefore, UBIK^® should be switched to offline mode.

In case there are uncommitted changes, the followings apply depending on the sync mode at that point of time.

• Automatic mode: Changes are committed automatically and UBIK^® is switched to offline mode;
• Other modes: A dialog is shown to let the users decide whether to commit their changes or not. Changes are, of course, only committed with users' consent. But UBIK^® is switched to offline mode either way.

Reacting to processing errors

In the push scenarios described above, once a conflict is detected and can not be resolved (e.g. updating Meta Definitions when there are uncommitted changes in manual sync mode), that particular push is considered as failed to be processed.

During the next push update, all the failed pushes will be reported to the push web service. The result of this is UBIK^® will get these failed pushes again along with the new pushes (if there are any). However, all successful pushes in the previous push update will not be delivered again.

Just like for the content service, various errors can happen when the push service is running. For example,

• The push web service is unreachable due to misconfigurations in the settings;
• Users are denied of accessing the push web service due to invalid credentials;
• The client push service is incompatible with the push web service due to version differences;
• etc.

In case such an error occurs, a notification is shown to inform the users so that they can either fix the issue or contact the administrators.

• UBIK Push Web Service
• Sync ModeVersion