Sync Manager
The Sync Manager collects all synchronization operations of the UBIK® client that could not be completed successfully and offers a central place to review, retry, report or dismiss them. In addition, it lists all local changes that have not been committed to the server yet.
It replaces the former behavior where failed synchronizations were either not visible at all or interrupted the user. Failed operations are now recorded silently in the background, and the user can decide when and how to deal with them.
 | Only failed operations are listed. As soon as an operation succeeds (e.g. through a retry or a later automatic synchronization), the corresponding entry disappears from the list automatically. |
Contents
Opening the Sync Manager
The Sync Manager is opened via buttons which are only shown if there is something to handle:
| Button | Shown when | Opens tab |
|---|---|---|
| Sync issues (alert icon + number of issues) | at least one synchronization issue exists | Needs attention |
| Uncommitted changes (unsaved-changes icon + number of objects) | at least one object has local changes that are not committed yet | Uncommitted changes |
- WinX: The buttons are located on the right side of the global status bar (visible after login).
- Mobile: The buttons are located in the bottom row of the menu area.
 | The Sync Manager does not open automatically when a synchronization fails. Keep an eye on the sync issues indicator. |
Tabs
Issues are grouped by how urgently they require the user's attention. The number in front of each tab title shows the number of entries in that tab.
| Tab | Content | Typical impact |
|---|---|---|
| Needs attention |
|
Local work has not reached the server, or offline data is incomplete. Should be handled as soon as possible. |
| Review |
|
Displayed data might be outdated or incomplete. |
| Background |
|
Background operations which usually recover by themselves. |
| All issues | All entries of the three tabs above. | |
| Uncommitted changes | Objects with local changes that are not committed to the server yet. | See Uncommitted Changes. |
Each entry has a colored marker on its left side: red for Needs attention types, orange for Review types and grey for Background types.
Sync Issue Entries
Every entry shows:
- a summary consisting of the operation and the affected object (name and description),
- the location of the affected object in the hierarchy,
- the time when the operation failed (most recent failure),
- the report state: Not reported, ✓ Reported or ⊗ Report failed.
When expanding an entry, the following details are displayed:
- Sync type – the kind of operation (e.g. BranchHierarchyDownload, CommitChanges)
- Web service call – technical information about the failed server call (URL, status code, duration, error details). Session tokens are not included.
- Location – the full path(s) of the affected object(s)
- Error – the error message
Failed documents of a branch download
If documents fail to download during a branch download, the branch is listed in Needs attention and the failed documents are shown nested inside the branch entry (visible when expanded). Documents which are downloaded individually (e.g. by opening a document) are listed as separate entries in the Review tab instead. If a failed Document download under a branch download is retried and fails again, then it is also displayed in the Review section as a single file Document download.
Repeated failures
If the same operation (same type, same object(s)) fails again, no additional entry is created. The existing entry is updated with the new time, error and web service call instead, and its report state is reset to Not reported.
Actions
Actions can be executed for a single entry (buttons on the entry) or for several selected entries at once (bulk buttons).
| This only works in Online and Manual Sync mode. |
| Action | Description | Requires online mode |
|---|---|---|
| Retry | Executes the failed operation again. If it succeeds, the entry is removed. If it fails again, the entry is updated. Retrying a branch download downloads the branch again, including its documents. When several failed commits are retried together, all affected objects are committed in one single commit. | yes |
| Report | Sends the selected entries, including their technical details, to the UBIK® server so that administrators can analyze the problem. The report state of the entries changes to ✓ Reported or ⊗ Report failed. Reporting does not remove the entry. | yes |
| Remove | Removes the entry from the list without retrying the operation. Removing a branch download also removes its nested failed documents. | no |
| Remove only dismisses the entry – it does not undo or repeat anything. For example, removing a failed commit entry does not discard the local changes; the object stays in the Uncommitted changes tab. |
Selecting multiple entries
- WinX: Hover over the list and click the selection icon at the top to switch to multi-selection. A toolbar with Select all, Deselect all, Retry Selected, Report Selected and Remove Selected appears. The buttons on single entries are shown when hovering over an entry.
- Mobile: Entries can be selected by tapping them or via their checkbox. The toolbar with Select all, Deselect all, Retry Selected, Report Selected and Remove Selected is always visible.
The All issues tab shows the same entries as the other tabs, so a selection made in one tab is also visible in All issues.
Offline mode
While the client is in offline mode, Retry, Report and Commit are disabled and a corresponding hint is shown. Entries can still be viewed and removed. No new sync issues are recorded in offline mode because no synchronization is attempted.
Automatic Merging
The Sync Manager automatically combines related entries so that the list stays short and every problem is only listed once.
One entry per operation and object
An entry is identified by its operation type and the affected object(s). If an operation fails that is already listed, the existing entry is updated instead of creating a new one (see Repeated failures). This also applies to the automatic retries the client performs internally, which means that a single failed action results in exactly one entry.
The following rules apply when comparing entries:
- The order of the affected objects does not matter; e.g. a failed commit of the objects A, B and a failed commit of B, A result in one entry.
- A failed check-out and a failed release of the same object are separate entries.
- A failed file upload is only merged with another entry if both refer to the same object and the same file.
In addition, the Sync Manager regularly checks the lists for duplicates and keeps only the most recent one. Two entries count as duplicates if their operation type, affected object(s), called web service and error message are identical.
Partially resolved entries
Some entries refer to several objects at once: commits, check-outs / releases and live value updates. If some of these objects are synchronized successfully later on (e.g. by committing one of the objects again), they are removed from the existing entry and its location is updated. The entry only disappears once all of its objects have been synchronized successfully.
Example: A commit of the objects A and B fails. Later, only A is committed successfully. The entry remains and only refers to B.
Failed documents of a branch download
Failed document downloads that belong to a branch download are grouped under the corresponding branch entry instead of being listed individually (see Failed documents of a branch download). Once all of these documents have been downloaded successfully, the branch entry is removed as well.
Combined retry
When several entries are retried together (Retry Selected), operations of the same kind are combined:
| Selected entries | Executed as |
|---|---|
| Several failed commits | One single commit containing all affected objects |
| Several failed check-outs / releases | One check-out request and one release request, each containing all affected objects |
| Several failed live value updates | One live value request containing all affected values |
| Several branch downloads, document downloads/uploads or object updates | One request per affected object; objects selected multiple times are only processed once |
The entries are then updated individually depending on the result, i.e. entries that were synchronized successfully are removed, while entries that still fail remain in the list.
| Reporting is not merged: All selected entries are sent to the server in one single request, but each entry keeps its own details (location, error message, web service call). |
Uncommitted Changes
The Uncommitted changes tab lists all objects which were changed, created or deleted locally but not yet committed to the server. Select one or more objects and use Commit to upload the changes. Committing requires online or manual mode. If the commit fails, a corresponding entry is added to the Needs attention tab.
Persistence
Sync issues are stored in the local client database. They are therefore
- kept after restarting the client,
- stored separately per user and per profile,
- loaded after login.
They are deleted when the issue is resolved (successful retry or synchronization), when the user removes them, or when the affected object is deleted.
Reporting (Server)
Issues can be reported to make Admins aware they exist and can react accordingly. Reported issues are sent to the content service (service version 530 -> add flag!) and stored there as well. The server does not send these reported issues back; you only receive OK or failed as a response.
See also
