Upgrades & Config Changes
There's multiple components in the Connector architecture and they are upgraded individually.
Cinchy Platform hosts the configurations for the listener and worker. Any new features that require a change in the data model (e.g. New configurable setting in the listener, change in structure of the error messages) will require you to upgrade your Cinchy Platform instance. New versions of Cinchy Platform are backwards compatible with your old data sync configurations, so it is recommended that you upgrade your Cinchy Platform first if you want to use a new feature.
The CLI worker reads a configuration from Cinchy Platform and performs the data synchronization. You can use multiple versions of the CLI Worker at the same time with a single instance of Cinchy Platform, so you can test or run your configurations through a new CLI worker locally before promoting that version of the CLI to production.
If you are running batch syncs, you can simply switch out the CLI you are using between jobs. For the CLI worker service, disable the listener subscriptions first and check that there are no more outstanding messages in the queue before shutting down the worker service. You can then start up the newer CLI worker service pointing to the same queue in SQL, and then enable your listener configurations.
The Listener picks up the subscriptions from Cinchy Platform. Similar to the worker, if you are upgrading for a new feature in the listener you should upgrade Cinchy Platform first. To upgrade the Listener, disable all subscriptions first before shutting down the Listener. When you start up the new Listener, make sure it is using the same state configuration file so it can pick up where the last one left off and you do not lose any messages.
If you are adding more fields to sync, ensure the columns are in the target system first. You can then swap in the new data sync configuration whenever and it will get picked up for future execution.
If you are removing fields to sync, swap out your data sync configuration. You can optionally delete the field in the source and/or target system afterwards.
If there are no fields being added or deleted, simply swap out your sync configuration. If you need to add or remove fields, follow the guidelines above of when to swap in the config versus making the data model changes (add columns first, swap out config, validate config, delete unneeded columns).
Simply swap out your data sync configuration if you are changing the sync key. It is a good idea to check if your new sync key is unique in both your source and target. The CLI worker will sync using the first record it found in the source to the first record it finds in the target. Checking for duplicate sync keys will allow you to understand whether any unexpected behavior will occur.
Last modified 2yr ago