General

 How flexible is Exalate?

Exalate uses a groovy-based scripting engine to implement filtering, transformation and mapping.  Even though scripting like that is more complex than a drag and drop interface, it is the only way that makes even the most complex mapping possible to implement. See how the most complex use cases can be implemented using the relation level processors.  Do you want to map statuses to comments check following blog 

 Are you planning to accommodate other issue trackers?

 Yes. Right now, Exalate is compatible with JIRA Server, JIRA Cloud and HP QC ALM.  We are working on the integration with other issue trackers.

 What is the licensing and pricing of Exalate?

 Exalate is available for JIRA Server, JIRA Cloud and HP/QC ALM. Synchronizing is unlimited between any of these platforms as long as each instance has a valid Exalate License. Check here for details on pricing and licensing.


 Is it robust and performant enough to scale and support enterprise level synchronizations?

 Exalate is already in use since 2014 at different enterprises.  One of our customers processes on average 12000 issues / month without significant impact on the overall instance

 What type of information can be exchanged?

There are no limits to sending information using the customKeys property of a replica.   It allows to send any arbitrary object which will get serialized at one end and deserialized at the other.

 Could one issue be synchronized to multiple parties?

Yes, it is possible to synchronize an issue from A to B and then from B to C, thus creating a chain of synchronized issues.


 Are updates and deletions of comments, attachments, worklogs supported?

 Yes. A hubissue is representing standard fields but also a whole set of objects of comments, attachments ...

For instance. it is possible to list all the added and removed comments using the correct properties.  Check the details of what is contained in a replica here.

 Is it possible to pause a synchronization for maintenance purposes?

Yes - check the relation and/or instance configuration - these can be activated / deactivated if necessary. 

 How does the engine ensure that attachments are sent over correctly?

When a node requests another node to send over the content of an attachment, the other node will respond with an hash key calculated from the content of the attachment. The same hash key is calculated on the receiving end to ensure that the received content matches the original attachment.  The download will be retried once to avoid transmission errors.  Failing this second attempt an error is raised and the administrator is notified. 

 How will the solution behave in the case of a disaster recovery (where one side needs to restore a backup which is 1-day-old)?

There are 2 different situations to be considered

  • Any new issue brought under sync will be synchronized normally

  • All issues under sync will require a 'calibration phase' which allows to bring the synchronization back into shape. 

 What is the storage overhead per issue?

Every replica of an issue is stored on 2 systems. A replica is the result of the transformation of an issue into a hub issue (through the datafilter)  This replica is stored:

  • on the originating tracker to detect if relevant changes have been made since the last synchronization

  • in the target tracker to provide the content of the previous version.

 What architecture is used to ensure independent upgrades of each tracker?

The distributed architecture of the synchronization engine allows to upgrade either end as appropriate.  The common hub issue model ensures that the synchronization information can be translated to the local context.

 Is the synchronization status made visible in a simple and straightforward way?

 Yes - the synchronization panel will detail out all information relevant of the synchronization

 Is the remote issue easily accessible?

Optionally.  The application administrator can configure how links to the remote issue are represented.  Either as JIRA issue link, as a weblink in the synchronization panel or not at all.

 Does the solution support staging the configuration in another environment without affecting production synchronization?

Not yet - we are working on it.  When staging exalate 1.3 or earlier, make sure that synchronization engine is not triggered by deactivating all instances .

 What happens when the remote issue is deleted?

The deletion of an issue is considered as a synchronization event.  This will trigger a number of events which ensure that future synchronization events are not processed anymore.  The synchronization panel will indicate that the remote issue has been removed

 Does the third party require administrative access to be able to synchronize?

Not at all - every application administrator can define how 'hubissues' are translated to the local context

 What is the impact when syncing with a less capable tracker - should you compromise on synchronization options?

No - the intermediate layer is taking care to transport whatever information the originating tracker wants to share.  It is up to the other side to take it into account. 

 How do I access the subscriptions page?

In 3.2.1 release subscriptions page was hidden. But the page is still there. You can access it using this kind of link :

JIRA_URL/secure/admin/exalate/subscription!Default.jspa
 
 Is it possible to do sync manually ?

Yes, it is possible. Both on Jira Server and on Jira Cloud, you can use either an issue operation (menu item in the More drop-down)or even configure workflow for the issue to put it under synchronization when certain transition is performed( Exalate Post-function).

 Considering JIRA has workflow and customizations for a ticket, how does Exalate handle them during the sync process?

Exalate has a built in scripting engine to implement almost any use case in a flexible way. Check our documentation for some examples.

 What is the frequency of sync of data / issue details between JIRA & JIRA / JIRA & ALM?

From JIRA to HP: Changes are processed almost immediately, depending on the number of outstanding synchronization requests.
From HP to JIRA: The exalate application is querying the HP application every 5 seconds for any new change, and processes these (using a single thread). If the number of changes requires more processing time than 5 seconds, the next cycle is run immediately.
From JIRA to JIRA: Changes are processed almost immediately, depending on the number of outstanding synchronization requests.

 What is a Link Type?

When the issues get synced, you can select whether users see a link to those remote issues or not. The admin has the option to decide if the users can have direct access to the issue they are connecting. 

 What do you mean by Sync rules?

This is a set of scripts, where we define the data we want to synchronize and the reaction when we receive the synchronization data. Every script has its purpose.
Data filter defines what your instance sends during synchronization(how a message is created). Create Processor tells how would an issue get created due to the first message from the remote Instance.
Change processor tells how would an issue change due to a subsequent message from the remote Instance.

 How is the data secured on the Exalate server for Jira Cloud?

Atlassian requires that any 'add-on' technology runs on a separate server. This is called Atlassian Connect.

Relevant data for the functioning of the add-on will be exchanged with the vendors' servers. The same applies to Exalate.

Whenever an issue is updated, a webhook will be called. It triggers the Exalate logic to collect all relevant data such as specified in the outgoing processor (Data Filter).

This communication is secured via https and JWT.

In case the Destination side is on the private network the issue data resides on the Exalate Cloud servers until the destination Jira instance requests for any changes. These changes will then be sent to the Jira Server - and that communication is normally also secured via https. The information on the Exalate cloud server is removed.

In case the Destination side is publicly accessible the issue data resides on the Exalate Cloud server until the app filters and processes changes. These changes will then be sent to the Destination Jira Instance - and that communication is normally also secured via https. The information on the Exalate cloud server is removed.

Contrary to the common implementation model as prescribed by Atlassian, Exalate cloud apps are single tiered.

Meaning - that the operation and handling of the data is fenced from any other interference.

Configuration

 Can the configuration evolve independently?

 Thanks to the distributed model, it is possible to adapt the common hub issue to the local context.  For instance, if your local workflow evolves, you will be able to change the create and change processors to take into account the new configuration.  

 Can you upgrade your own environment without affecting any remote configurations?

Exalate is based on a distributed model where each application administrator configures what information can be send and how incoming messages must be handled.  All messages exchanged between the nodes are based on a common defined 'hubissue' which carries all information one application administrator wants to communicate to the other side. The processors will use this information to apply the changes to the local issues.

 Is the synchronization status visible for the user - even when the synchronization failed?

Absolutely.  The synchronization panel shows all relevant details - even if the remote issue has been removed.

 Is it possible to transition an issue whenever a certain comment is given?

Yes.  Thanks to the groovy goodness, one can parse the newly added comments and trigger a resolve transition

 

#
# Resolve the issue when a comment contains the word 'Resolve'
#
def resolveComments = replica.addedComments.findAll { comment -> comment.body.contains("Resolve")}
if(resolveComments.size() > 0) {
   workflowHelper.transition(issue,"Resolve")
}
 How complex is it to construct a complex scenario?

A scenario we encounter regularly is the service desk use case where tickets raised by a customer need to be raised internally in different projects - depending on the set of properties. One use case was particularly interesting.  The target project depended on 3 different properties resulting in 200+ potential permutations.  This mapping is stored in a single database table.

The way we solved it involved finding the right projectkey in the database table and use it to raise the issue in the right project.  Check following example showing how such configuration can be set up using Exalate.

 Is it possible to synchronize contextual data of an issue (such as project, version, user information)?

Yes.  A hub issue contains all contextual data allowing to implement complex business logic.  Check out the detailed information a hub issue message transports such as:

 How long does it take to process all synchronization events when 10000 issues in 100 different projects have been updated?

The synchronization engine is processing sync events sequentially (for the moment - November 26. 2016).  Processing 10000 issues in 100 different projects might take a couple of hours.  We have been synchronizing 10k+ issues as part of our performance tests and we are looking at increasing the processing speed to meet the challenge that one of our prospects is facing.

 

 Can the configuration of the local tracker change without impacting the configuration of the other trackers?

Yes.  Each integration point can evolve as long as the hub issue model and exalate api is respected.

 How long does it take to synchronize an issue, when 10 other issues under sync have been updated at the same time?

This happens immediately. Exalate is based on a fully event-driven engine  Whenever a user changes some information (and that information needs to be sent), a sync event is generated containing a snapshot of the modified issue - ready to be sent to the remote instance.  When 10 issues are changed, or 1 issue 10 times at the same moment (it does happen) - 10 events are generated.

The replication layer in the exalate architecture will transmit each sync event to the remote instance, triggering a sync request, which is processed at its own pace.

Handling a full synchronization event takes a couple of seconds (give / take the size of the information to be transmitted)

 How is the troubleshooting process supported?

Whenever an error occurs, a detailed overview (= stack trace) leading to the problem is raised.  In case this is not sufficient, one might create a support.zip and send it to support@exalate.com for further processing.

 Is Exalate compatible with any reverse-proxy solutions?

Since Exalate is an app for different deployments of Jira (Server, Cloud, Data Center) and other platforms, we do not attempt to ensure that our application is compatible with all third-party reverse-proxy solutions that might be set up on the Jira host.
However, we've tested it with nginx, and we can state that Exalate is compatible with nginx as a reverse-proxy server.

 How are the system administrators notified in case an error is raised?

The group of exalate administrators will be notified in 2 different ways

  • by email with the details of the error notification

  • In JIRA - by using 'In-JIRA' notifications - popping up a warning about the blocking error

Also, errors are generated at 4 different levels.

  • issue

  • As an example -  when the proxy user is not allowed to modify the local issue due to issue security

  • Relation

  • Typical example - when there is an error in the processor scripts, or when there is a permission problem to apply changes to an issue

  • Instance

  • A connection problem

  • Node

  • Bugs in the synchronization layer.

 Is it possible to sync multiple projects to one using one Connection?

Yes, it's possible to sync multiple projects with one connection.

 Basically, it's all about the configuration of the Sync Rules. Once that you establish a connection between instances you can specify which data would you like to send to the other side and how to interpret incoming sync data.

The Data Filter of the sending side interacts with Create and Change Processor of the receiving side.

For more details, please check the synchronization processors.

Versions and pre-requisites

 Does Exalate support any other issue trackers or versions (both now and in the future)?

Currently, Exalate supports JIRA Core, JIRA Service Desk, JIRA Data Center, JIRA Software, JIRA Cloud, HP ALM. We are working on some other issue trackers to be compiled with Exalate 

 What versions of JIRA are supported?

All editions of JIRA (Core, Software, Service Desk) and platforms (Server, Datacenter and Cloud). Server and datacenter supported from JIRA 6.3 and up. 

 What versions of HP ALM are supported?

We are validating against HP ALM 12.02, and 12.50. 

 Is it possible to synchronize a JIRA issue with an HP ALM requirement?

For now only HP ALM defects could be synchronized. 

 What are the installation and software prerequisites for Exalate plugin?

For JIRA Server: Exalate is an Atlassian add-on, which can be installed as any other add-on. Synchronization information is stored in the JIRA database. The memory footprint is limited and should not require any modification from the existing setting. In case of doubt, adding 128MB to your jvm settings should be sufficient.
You will be required to configure a single JIRA user, which will be used to access the issues to be synchronised
Exalate also requires a SMTP server to raise notifications in the case of errors. For this SMTP a hostname, userid and password are to be provided in case outgoing mail requires authentication

For JIRA Cloud: Exalate is an Atlassian add-on, which can be installed as any other add-on. Synchronization information is stored in the JIRA database.

For HP ALM: Exalate is delivered as an external application which interfaces with HP through the REST API. You will need following:

  • A host which can run the application

  • The application is delivered either as a RPM (centos) or as a docker image (many platforms)

  • In the case of an RPM, a postgresql 9.4 database needs to be deployed on the host

  • The exalate application needs to have access on the HP ALM application (for reading and writing)


 Exalate app for Jira Server upgrade to 4.x

In 4.0 version we've introduced Connection and Invitation concept that includes changes to the User Interface.

The configuration is simplified now. What we used to call Instances and Relations is now merged into Connections.

The Connection includes information from the Instance and a Relation, based on that Instance.

 More details

 How is the security improved in the Exalate 4.x version?

 

EXALATE 4.X

In Exalate 4.x, there is no need to share access credentials anymore, even if your instance requires authentication.
Starting from 4.0.0 version in the Exalate app for JIRA Server, 4.1.0 in the Exalate app for JIRA Cloud and 2.0.0 in the Exalate app for HP QC/ALM, Exalate is using a new security approach.

Below you can find answers to the most common security questions.

 

 What if the invitation was sent to the wrong person - could it be applied?

No, the invitation could be applied only to the invited side. It includes an Invitation code that helps to secure Connection data.  

 What infomation is exchanged with the other side?

Once the Connection set-up is finished, Exalate generates the shared secret. The secret is used to define a secure connection between both Instances.

It is shared only once to generate a JWT token. The token is temporary and is generated for every communication request between Exalate on both Instances.

The following information is exchanged between Instances:

  • shared secret;
  • information about the type of the connection with the Destination instance;
  • Connection name;
  • information about the Connection initiator
    • Exalate app version, including supported features
    • Instance type and version ( JIRA Server, JIRA Cloud or HP QC/ALM)
    • Instance URL and Exalate URL
    • Instance UID, which is a unique instance identifier
 How is the data transfer secured?

The JWT token generates on every communication request between Instances. It authenticated the request so the destination side can be sure they are getting data from the expected Instance.

 What information is stored locally?

Instance URL, Instance version, Exalate URL, a unique instance identifier.

 How the connection is secured and authenticated between the Exalate app for Jira Cloud and Jira Cloud Instance?

For more details check Atlassian security overview.

 How the connection is secured and authenticated between the Exalate app for HP QC/ALM and HP QC/ALM Instance?

On the configuration stage of the Exalate app for HP QC/ALM you need to specify HP QC /ALM Instance(issue tracker) user and password. The credentials are used to communicate with the HP QC/ALM Instance.

 

See Also

How is the data secured on the Exalate server for Jira Cloud?

DATA SECURITY AND PRIVACY STATEMENT

How is the traffic different between a public and a private side?