How it works

Pairing

Theory of Operation

Pairing is a method by which two or more servers which are running Integration Tool can work together to process the same workflows. Only those workflows that share the same hotfolder or external trigger (like FTP, JobTicket, Query etc.) will be paired. In the "Pairing Configuraton" you can configure per server which Daemons should be included in the Pairing mechanism. Each enabled Daemon will on startup determine which workflows are suitable for pairing and register itself in the configured pairing-database. When a paired workflow starts running it will first check in the pairing-database if another partner-server is already processing the same workflow. If so, the worklfow won't be executed by this daemon.

The "Pairing Configuration" allows you to configure names for the hashing- and partner tables. All partner-servers which share the same database and the same table-names will be paired together. Using different table-names for different servers you can configure which servers should be in the same pairing-group. This way different pairing-groups can be stored in the same database.

The pairing mechanism ensures that if one partner-server fails, the other server(s) will seamlessly take over the processing of the paired workflows. This makes pairing both a kind of load-balancing and fail-over mechanism.

On a more technical level:

Each time a paired-workflow starts to run, it checks the hashing-table to find out if another partner-server is already processing a workflow with the same trigger-settings. If not, a hash-code is generated from the trigger-type (Hotfolder, FTP, Query), inserted in the hashing-table and the workflow starts to run. This hash-code is the actual "trick" to the pairing mechanism because it is based on the exact trigger-settings (hotfolder-path for Hotfolder-trigger, FTP-settings for FTP-trigger and Query-settings for Database-trigger). This means that if different servers are using the same settings, they will generate the same hash-code. A query can then be executed on the hashing-table to find out if a workflow with this particular hash-code is already being processed.
Once a paired-workflow is finished it will remove the hash-code from the hashing-table.

Requirements

The only requirement for Pairing to function is to configure the PAIRING preset-database to point to the correct database(server). Typically this database should be located on different servers then the partner-servers.

It is recommended to use a "real" database-server for Pairing, like SQL-Server or Oracle (not MS-Access MDB).

Configuration

Paired Daemons

The Daemons for which pairing must be enabled.

Pairing Database Configuration

Hashing Table

Name of the Hashing-table. The hashing-table contains information which is required to determine if a workflow is already running on a partner-server; each time a paired-workflow is executed a hash-code is generated from the workflow trigger-settings and placed in the hashing-table. If another partner-server tries to run a workflow with the same settings this will result in an identical hash-code and cause the workflow not to be executed.

Note-1: The hashing-table is created automatically in case it does not already exist in the database

Note-2: Each time a paired daemon is launched, it will make sure no previous entries exist in the hashing-table (cleanup)

Partner Table

Name of the Partner-table. The partner-table contains a list of all running partner-servers. Each time a partner-server (daemon) is launched it registers itself in the partner-table and each time a partner-server (daemon) is shutdown it unregisters itself. Although this table is not actually used by the pairing proces it can be useful to find out which servers/daemons are currently paired.

Note-1: The partner-table is create automatically in case it does not already exist in the database.

On-Fail Option

This setting determines what action is taken when the pairing mechanism fails. Typically this failing is caused by an inaccesible database.

Disable Pairing	Pairing is disabled for all workflows in the daemon and all workflows will run as they would without the paring-mechanism. NOTE: this could cause problems for workflows/daemons/servers which scan the same hotfolder because they might pickup and proces the same file(s) at the same time.
Stop Daemon	The Daemon is stopped.
Restart Daemon	The Daemon is restarted after the specified number in seconds.

Save (Test/Configure)

When clicked, the pairing settings are saved and the configured database is automatically checked for the necessary tables. If these do not exists, they are created automatically.

Save

When clicked, the pairing settings are saved but the configured database is not automatically checked for the necessary tables.

SetConnect

How it works

Documentation