The Exalate issue network is a network of companies sharing issues. Instead of using email or telephone calls, issue trackers are connected to each other so that information can be shared in a straightforward way.
To be able to do so, we introduce some concepts and entities below.
A node is an issue tracker with the Exalate app installed. The app can be installed on a separate server or within the issue tracker system. The deployment model depends on the issue tracker.
Exalate provides all the logic to synchronize data in a secure, stable, and robust way. There are a couple of properties related to a node, such as the proxy user.
Nodes are currently available for JIRA Cloud and Server (v6.2 and higher), HP QC/ALM, GitHub, Zendesk and Servicenow.
An instance is an issue tracker that you want to connect. You can integrate with multiple instances using different connections.
You can also synchronize between local projects within the same instance.
Local synchronization is not supported in all issue trackers.
Connection defines how issues are synchronized. A connection is defined by its name, Destination URL and Sync Rules.
It includes information about two Instances and describes how they are related to each other.
For example, you can define a connection between a project which tracks tasks to track a systems deployment on one side and another project which tracks bugs and feature requests on the other side.
Exalate provides the following connection types:
- Local connection
Allows to sync between projects within one instance.
- Another instance, which is accessible
Allows to sync with an instance, which you can access from your side.
- Another instance, which is not accessible
Allows to sync with an instance, which is behind the firewall and you cannot access it from the public network. Check the private/public issue synchronization for more details.
A connection has three different statuses:
The connection is pending for acceptance from the other side.
A connection has been established and synchronization messages can start to flow. You can synchronize issues.
The synchronization is paused, but changes are queued for a later update. Once you activate the connection, all changes will be applied.
Establishing a connection allows you to define Sync Rules and Communication type between two instances.
Synchronization behavior is configured with the groovy scripts. Groovy is a scripting language very similar to java.
The rules specify what data to send to the other side and how to apply received data(from the other side) locally.
Sync Rules consist of 2 processors:
- Outgoing sync
Rules for outgoing synchronization. You can define what information to send to the other instance. This processor executes when the synchronization starts from your side or there's an update on the local issue which is under sync.
- Incoming sync
Rules for incoming synchronization. You can define how to apply received information on your local instance. Exalate uses incoming sync rules to create a new local issue and update the issue which is already under sync. This processor executes when there's new incoming data from the remote side.
Check the Sync Rules article for more details and examples.
Issue and replica variables
When you start an issue synchronization, Exalate creates a replica. It's a copy of an issue that holds information that will be sent to the Destination side.
In the outgoing sync
- replica variable defines the information added to the issue copy
- issue variable refers to the original issue
In the incoming sync
- issue variable refers to the issue where the change needs to be applied.
- replica variable refers to the issue where the change happened.
You can use a shortcut Alt+A to apply changes when you edit a connection.
Triggers are events that start synchronization. This can be:
- an update of an issue
- a user who selects the exalate operation in the drop-down menu
- a search query which identifies issues that should be synchronized