Expand all   Collapse all
Skip to end of metadata
Go to start of metadata

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.

Node

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

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:

  • Initial
    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.
  • Active
    The instance has been activating.  A successfull connection has been made and synchronization messages can start to flow.
  • Deactivated
    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.

Connections

Connection define how issues are synchronized. A connection is defined by its name, Destination URL and Sync Rules. So when instance left is synchronizing with right, you can define how issues will be synchronized.
For instance, you can define a connection 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 connection between left and right to track more generic support requests.

Establishing a connection allows you to define Sync Rules and Communication type between two instances.

Sync Rules include:

  • 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

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.

See Also