This procedure applies only for clients working in read-only mode. Otherwise, the synchronization procedures are failing.
The environment contains 2 Nuxeo servers. One of them (further named "offline server") is the Client machine working in read-only mode. The second (further named "online server") is the base Nuxeo server. The user wants to have on own offline server a replication of the documents on online server so the user can consult them (not to modify) offline.
The target is to upload on offline server the entire set of visible documents for user from online server. Subsequent synchronizations should require minimum amount of data transfer.
The online server synchronization module is the nuxeo-platform-sync-server project, available as addon. It is enough to deploy it to have the feature enabled.
The offline server needs:
nuxeo-platform-sync-client-api, nuxeo-platform-sync-client-core. nuxeo-platform-sync-client-web, available as addons, deployed
flag org.nuxeo.ecm.webapp.readonly.mode set true in the nuxeo.properties.
As user I want to be able to synchronize my offline server.
Step 1: An empty mini Nuxeo server is used.
Step 2: Using the synchro GUI, the mini Nuxeo server is configured to connect to online server. The mini-server is updated.
Step 3: User checks to see that all accessible documents are available offline
Step 4: Using the same synchro UI, further synchronization are effective.
The offline server user logs in and navigates to "Synchronize" page (following the link in top tool list). The user provides the credentials on the server, starts the synchronizations and, on completion, if required, logs in back with the new credentials.
The data workflow on server is simple:
WS Addressing webservice is made available by the server to allow client requests: the current situation and the DocumetnSnapshot of a particular document. The blobs are requested through a restlet.
ExportRestlets are provided to download relations in RDF format and directories XML based custom encoded.
The data workflow on client is a little more complicated, as the client is responsible to decide what documents need to be updated:
The module is able to obtain the webservice SEI based on the provided credentials. With this, the module requests for server the tuples describing the current situation, or the DocumentSnapshot of a particular document.
Also, the query ran on server is provided to client in order to have the same scope of documents synchronized.
Servers runs the query with the user credentials and provides a list of tuples containing: the document id, path, type (including version / proxy selector), modification date, context data for allowing import. Client compares the list with the current situation running the same query.
First it removes the documents no longer available.
After it adds the new documents (in order: usual documents, versions, proxies).
And finally it updates the documents modified.
The documents are added through Core import, allowing preserving the document ID. Also, this method allows to "add" proxies and versions easily. The update of documents is made in several steps:
first, the client requests the FlagedDocumentSnapshot (a DocumentSnapshot + the hasBlobs flag) on synchro webservice;
the DocumentSnapshot map of properties are set on the local document using a mechanism very likely with the core import/export;
if the document has blobs, client makes request to ExportRestlet for the document export;
the Client reads the document.xml and the blob files received and adds them in the document.
The vocabularies and relations are exported entirely and also are imported by replacing existing ones.
Known bug: in the case of security wholes in the tree, the offline server can end up in an undefined state. For instance: user has read rights on Workpspace A, not on Folder B below and has on Folder C below. The Folder C can't be created on offline server as Folder B is not supplied from server.