ERP5SyncML is a synchronization engine based on the SyncML protocol which makes
it possible to distribute the data on several sites without need of a permanent
and rapid connection between these sites. That also allows the mobile users
(phone, PDA,...) to use ERP5 without permanent connection.
Table of Contents
The following list of business templates and their dependencies needs to be
installed: erp5_base, erp5_core. For business template installation guide
The 4Suite API is used to parse xml messages, so you must install it (a
rpm is avaible for mandriva 2007.1, and you can find source code at http://sourceforge.net/projects/foursuite/)
If you want to do synchronization, you should have at least two Site instances.
One of them has to be a master and all other have to be clients. Any modification
made on any Site will be sent to the master, and the master send back each
modification to each client. Like this, all Sites (master and clients) are
informed about modifications.
Let's say we have one zope running on our local box. We will create for example
two Sites, the fist one wich will be the master with the id 'erp5_server', and
the second one wich will be the client with the id 'erp5_client1'.
If you want to make sure that your box is installed correctly, you should go
on one object of your site and then add to the url the method 'asXML' like this :
If everything is fine, you should have no errors and you should see the xml
corresponding to your object.
Go to the zope management interface and then add to all your sites (master and clients) an ERP5SyncML Tool.
The last thing to do is to configure your synchronization tool inside the zope
management interface. You have in this tool many tabs. The 'publication' tab is
used on the server and the 'subscription' tab is used on all clients. A publication
is a setting for something we want to share with others. So on the master we have
to specify as many publication as the number of folders we want to share. A
subscription is a setting for something we want to synchronize from a master,
so on each client we have to specify as many subscriptions as the number of
folders we want to synchronize with the master.
I do have on my server side the following publication :
I do have on my client side the following subscription (for me, the subscrption
and publication are on the same computer but you could have, someting else than localhost) :
Note: If you don't want authentication, you can leave the
field Login and Password empty on the subscription (but it is not an obligation)
and you must uncheck the Authentication Required checkbox on the publication
side (and you can leave empty the Format authentication and Type authentication
fields but it is not an obligation).
My script PersonModule_getPersonList:
#Parameter List : gid=None, **kw
if gid is not None:
kw['title'] = gid
object_list = [x.getObject() for x in context.person_module.searchFolder(limit=None, **kw)]
The synchronization starts only from a client, so you should go on one of the
client instance. Then you have to go on the portal_synchronizations and select
one of the subscriptions and hit Sync.
The Reset button erase all signatures on the side where it's hit, that means that
next synchronization will be a SLOW SYNC (= 201 synchronization code). if the
server reiceives a 201 alert code, it erases all of his signatures.
If you want to see the xml messages transferring between the two sites, you have two ways :
tail -f /var/log/zope/event.log
There is some case, where after a synchronization, the data coudn't be merged,
this is a conflict. Typically it's append when a data is modified on a client
and the same data (on the same object) is modified on another client or on the
server, after a synchronization, a conflict appear in the Conflicts tab of
portal_synchronization (on the server only).
To resolve a conflict, it's very easy : In the Conflicts tab, you can see all
the conflicts with the publisher and the subscriber values, you just have to
chose the version you want to keep by clicking on Subscriber or Publisher.
Documentation written by Fabien Morin firstname.lastname@example.org