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.
A node is an instance in the overall exalate network. It 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 (v6.2 and higher) and HP QC/ALM.
Instances are other issue trackers you are willing to connect to. You can add any number of instances to your node and start exalating issues.
An instance has three different states:
The initial state is when an instance is created, but no connection has been made with the remote tracker.
When activating an instance, the add-on collects required information regarding what is supported by the remote tracker so that we can ensure backwards compatibility.
The instance has been activating. A successfull connection has been made and synchronization messages can start to flow.
An instance can be deactivated by the admin. For instance, when a remote tracker needs to be upgraded and synchronization with the remote tracker must be paused. Local synchronization events will still be collected so that once that once that the instance is activated again, synchronization can be resumed.
Relations define how issues are synchronized. A relation is defined by its name. So when instance left is synchronizing with right, you can define multiple relations.
For instance, you can define a relation between a left based project which tracks tasks to track a systems deployment and a right based project which tracks bugs and feature requests for a particular project.
At the same time, you can define another relation between left and right to track more generic support requests.
Establishing such a relation allows you to define:
- a data filter
The data filter is a script which defines what information can be sent to the other instance.
- a create processor
When the other instance sends over a request to create an issue, the create processor allows to define what the newly created issue should look like.
- a change processor
Each time a change message is coming in from the remote instance, the change processor allows to specify how this change should be translated into an update of the local issue.
You can also specify if a link between the two issues should be created.
Processors and scripts
All mappings and transformations are done using plain groovy scripts. Groovy is a scripting language very similar to java.
It allows you to specify how a priority of the remote issue should be translated to the priority used on your own tracker (the reality is that most priority definitions are very similar).
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 JQL which identifies an issue which should be exalated.