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 Cloud and Server (v6.2 and higher), HP QC/ALM and GitHub.

Instances

Instances are other issue trackers you are willing to connect to. You can integrate with multiple instances using different connections. 

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 incoming data from the other side.

Sync Rules include 3 processors:

  • Outgoing sync (data filter)
    Script rules which define what information to send to the other instance.
  • Incoming sync for new issues (create processor)
    Rules for incoming synchronization used to create a local issue. This processor executes every time you receive a new issue from a remote side.
  • Incoming sync for existing issues (change processor)
    Rules for incoming sync used to update the issue which is under sync. Every time there's an update on a remote issue, the local issue is updated with the help of the change processor. 
    It defines how an update of the remote issue integrates into the local issue.

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(data filter) 

  • replica variable defines the information added to the issue copy
  • issue variable refers to the original issue 

In the incoming sync(create and change processor) 

  • 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

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