A connection between two instances specifies the synchronization behavior. Each connection includes information about two instances and describes how they are related to each other.
Pending:The connection is pending, waiting for acceptance from the other side.
ActiveA connection has been established and synchronization messages start to go out. You can now synchronize issues.
DeactivatedSynchronization is paused, but changes are queued for a later update. Once you activate the connection, all changes will be applied.
To know more about how Connections in Exalate work, please refer to our Building a Connection guide.
An Instance is a task management system that contains information you want to synchronize. Examples of instances are Jira Cloud, Salesforce, Zendesk, etc.
You can integrate with multiple instances using different connections. You can also synchronize between local projects within the same instance.
Note: Local synchronization is not supported in all task management systems.
Whenever you set up a connection between two different task management systems, one of them will be a local instance, and the other one is a remote instance.
For example, if you set up integration between Jira Cloud and Zendesk, you can initiate a connection from either side.
If you choose to set up a connection on the Jira Cloud side, Jira Cloud becomes your local or source instance, and Zendesk the remote or destination instance.
To sync information between two task management systems, you need to set up a connection. When doing this, Exalate generates an invitation code. This works as a shared secret that helps authenticate both source and destination instances. Invitation codes store encrypted connection information, such as:
- Shared secret
- Connection type
- Connection name
- Connection initiator information
- Exalate app version
- Task management system and version
- Task management system URL
- Exalate Node URL
- Task management system UID - Unique instance identifier
An invitation code is used to set up a connection with the destination instance if an initiator does not have access to both sides of the connection. The code will only apply to the instance you are inviting to synchronize.
Note: An invitation code is required only in Script mode configurations.
Exalate uses synchronization rules (Sync Rules) to handle outgoing and incoming messages. You can find Sync Rules in a separate tab when you select the connection to edit.
To learn more about how to create Sync Rules, please refer to configuring a Connection in Script Mode.
Incoming Sync Event
The Incoming Sync Event is a record of the changes in the remote entity. Every Outgoing Sync event on the sending side results in an Incoming sync event on the Destination side.
Outgoing Sync Event
The outgoing sync event is a record of the changes in the local entity. When the outgoing sync processor sends out information, it gets recorded as an Outgoing sync event.
A replica is a copy of the information that is getting transferred to the destination side. Exalate uses replicas to extract specific data and then send it over. You can use the replica in the Outgoing rules to specify which data should be sent. On the destination side, the replica object is used to represent the remote issue. It contains only the fields provided through the data filter on the source side.
You can view the replica details in the Entity Sync status panel. If the entity is synced, you can view the local replica by clicking the Show local replica button and the remote replica by clicking the Show remote replica button.
The replica looks something like this:
In this manner, you can see what information is being passed over from the local instance. The remote replica has a similar structure.
The hubIssue represents the information that is passed and how you can access it. Whereas, the replica is more than the hubIssue section. The replica is the entire payload to be transferred between platforms.