Exalate basics

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.

Node

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.

Instance

Instance is an issue tracker which you want to connect. You can integrate with multiple instances using different connections.

You can also synchronize between local projects within the same instance.

Connection

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 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:

• Pending
  The connection is pending for acceptance from the other side.
• Active
  A connection has been established and synchronization messages can start to flow. You can how synchronize issues.
• Deactivated
  The synchronization is paused, but changes are queued for 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.

Sync Rules

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 which 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.
  
  

Triggers

Triggers are events which start a synchronization. This can be:

• an update of an issue
• a user who select the exalate operation in the drop down menu
• a search query which identifies issues that should be synchronized