The synch engine handles the synchronization of external subscriptions with a bedework calendar - for example a Google web calendar or an ical feed from a department.
Currently such a synchronization must be carried out to a single calendar collection which only contains data from the external resource. Also only one way synchronization is supported - inbound to bedework.
These subscriptions are available to personal calendar users and to public events administrators. For personal calendar users the options are limited as it is intended only to mirror the external resource.
Initializing the database
If running with mysql the built in hibernate schema export doesn't work - mysql jdbc does not support it.
The schema is simple however - it can be generated via the JMX mbeans or use the examples below - to install it manually, create a database - ensure UTF-8 is enabled
and then create the single table:
The synch engine uses an extension of CalWS to communicate with bedework. It requires that the wsdl file contain the location of bedework. This is configured into the deploy.properties file - only one change for the synch engine should be necessary. Set the location of (one of) your application servers in the following.
If you are running everything on one server then the quickstart setting above will do. Note that at the moment the synch engine can only work against a single bedework server. It can accept requests from any member of the cluster however.
Generate a set of keys using the cli.
If you are using multiple servers copy the resulting key file from <quickstart>/wildfly-10.1.0.Final/standalone/data/bedework/ on to each server.
Ensure calendar server(s) can locate the synch engine.
The bwengine/synch settings are configured to use a jvm system property to locate the synch engine. In file <quickstart>/wildfly-10.1.0.Final/standalone/confgiuration/bedework/bwengine/synch.xml you should see:
If you are using multiple servers change the host in <managerUri> to refer to your sync server.
Public calendar subscriptions.
For public events there are a few more options available when subscribing.
Process Locations and Contacts: This causes locations and contacts to be moved into x-properties "X-BEDEWORK-LOCATION" and "X-BEDEWORK-CONTACT". The receiving end (bedework) may carry out further actions to validate the location or contact and as a result may set a preexisting location or contact in the event. The x-property is always available for display but this process allows the system to validate the location/contact.
Process categories: This does the same for categories.
When an event arrives at the receiving end with an "X-BEDEWORK-LOCATION" property if the String value of the x-property is ...
If you are using a different version, please click on "Click for all versions" on the left side of the page and select the relevant version.