Deploying the sync engine

These notes assume a multi-server configuration where it matters. There is a 2 way interaction between the calendar server and the sync engine. 

The calendar server will call the sync engine to create new subscriptions and will call it to get information while adding or displaying collections.

The steps to deploy are:

1. Create a database for the sync engine
2. Update the standalone.xml to provide a datasource (and drivers)
3. Update the configuration.
4. Start it.
5. Create the table(s)

Update the configuration

There may be a number of changes to make - both in the calendar server which will interact with the sync engine and for the sync engine itself.

First update the calendar engine end:

1. connectorId - identifies the connector "localBedework" should be OK
2. managerUri - "http://localhost:8080/synch/manager" for embedded or the equivalent for a multi server setup

3. wsdlUri - "http://localhost:8080/wsdls/synch/wssvc.wsdl" is probably fine.

Then update the sync engine. This requires configuring both the engine itself in synch/conf/synch-config.xml but also at least the bedework connector in synch/conf/connectors/localBedework.xml

In synch-config.xml ensure the hibernate dialect is set correctly. Other than that the config is probably fine.

In localBedework.xml the name should match the name in the Connector Id above. The bwWSDLURI element refers to either the soap wsdl loaded from the remote server or it can be loaded locally. In either case that file must provide the location of the calendar server in the soap:address element right near the end of wssvc.wsdl. That file is deployed as part of the bwxml module. The files is in wildfly-10.1.0.Final/standalone/deployments/bw-xml-3.11.0.ear/bwwsdls-3.11.0.war/synch/wssvc.wsdl. The server location can be set as part of the build process or edited in later (but that will need to be done on each rebuild/redeploy). The build uses the value in the build time property org.bedework.bwsynch.service which is set in .default/cal.properties.

This process needs to be changed to use the deploy.properties invoked after the build.

Create the tables

The previously created database will have no tables. To make it usable you need to install the schema. Either use the hawtio jmx console or the cli.

Using hawtio to install schema

1. Navigate to the sync configuration.
2. Switch to operations
3. Invoke the "schema" operation

Using the cli to install the schema

1. Build the cli if not already built - cd quickstart;./bw -bwcli
2. cd into the built tool - cd quickstart/bwcli/dist/temp/shellscr/bwcli
3. invoke it - ./bwcli.sh
4. enter the admin id and password
5. Enter "sync schema"

In either case tables should appear in the database.

Sync Engine operations

The sync engine needs to operate in a firewalled environment. It uses connectors handle subscriptions and has the connector types:

1. localBedework - interacts with bedework via the SOAP service
2. file - handles iCalendar only
3. manager - for internal operations.

The localBedework connector will poll (currently iCalendar only) subscriptions for changes and interactswith bedework as follows:

1. At startup sends a startServiceRequest to bedework
2. Bedework sends back a response holding a token
3. The connector periodically pings bedework to keep the connection alive. Each time it gets a new (random) token.
4. The connector will check each of the subscriptions for changes.
5. When changes occur interactions with bedework (updating collections) use the supplied token

When a subscription is created an opaque token is handed over to the connector. This is returned when changes take place. This token actually contains some properties. At the moment these are

1. public-admin - true/false

2. adminCreateEprops - true/false - indicates whether the admin update can create event properties - e.g. location/category/contact. If false they get preserved as x-properties. Only set true for a very trusted source.