Confluence has been updated to version 6.15.9

Below you'll find answers to the questions we get asked the most about the Exalate app.

General


 How flexible is Exalate?

Exalate uses a Groovy-based scripting engine that helps to define the synchronization behavior. You can filter what data to send and how to apply incoming data. It is possible to map fields between instances or transform data from one type of field to another.  You can implement the most complex case in scripting mode.

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

 Yes. All standard fields, custom fields, and objects are supported. You can check issue fields available for synchronization.

 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)?

Exalate has an advanced, reliable transactional synchronization engine. Which queues all the changes that need to be applied. And breaks it down into atomic steps that can be retried in case of a failure.

 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. This replica is stored in both instances:

  • the source side: Exalate uses replica to detect if relevant changes have been made since the last synchronization

  • the destination side: Exalate uses replica to provide the content of the previous version

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

 Yes - the synchronization panel in Jira issue shows the current status of the synchronization. As for other issue trackers - you can check the issue status sync from the Exalate admin console by issue ID.

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

No. When staging a production environment into a test, it is important that no synchronization happens. Check how you can test Exalate in staging environment

 What happens when the remote issue is deleted?

When you delete an issue Exalate considers it as a synchronization event.  It triggers a number of events to ensure that future synchronization events are not processed anymore. The synchronization panel indicates 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 'hub issues' are translated into 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. 

 Are you planning to accommodate other issue trackers?

Yes. Check the Exalate integrations to get a full list of the compatible issue trackers.

 What type of information can be exchanged?

Any type of information can be exchanged. With the help of the customKeys property, you can exchange all the information you want.  It allows sending any arbitrary object which will get serialized at one end and deserialized at the other.

 What is the licensing and pricing of Exalate?

 Synchronization is unlimited between supported platforms as long as Exalate is installed on each instance and has a valid license. Check more details on pricing and licensing.

 How can I get a development/community license?

For each valid, paid license you can request a developer’s license for a non-production environment. It is the same as the original license including the expiry date.

As for the community license - you can request it in case you have Jira community license.

 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 use case examples for more details.

 Is the remote issue easily accessible?

Optionally.  The application administrator can configure how links to the remote issue are represented.  In Jira, you can see the remote issue link in the sync panel.

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

Exalate is already in use since 2014 at different enterprises. The Exalate has been configured as a single-threaded application that processes the synchronization transactions one at a time.  This has 2 consequences 

  1. A minimal system load, as the exalate can be compared to a single user who is working hard to update/retrieve information
  2. It takes time to process transactions (because of the single-threaded nature) and the product is not meant to do large migrations

One deployment has on average 12000 synchronizations/month without a significant impact on the overall instance performance.

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

Exalate application is querying the tracker for any new change and processes these changes using a single thread. If the number of changes requires more processing time the next cycle is run immediately.  But some trackers detect changes by polling in a time interval. Usually, this interval is not bigger than 1 minute. It means that once a change is performed, it can take up to a minute to detect the change and schedule its synchronization. 

For the private-public connections, it can take more time as we need to wait for the polling.

 Do you need to have an intermediate Jira to have a GitHub to ServiceNow integration?

No, you don't need to have an intermediate system. You can integrate any of the supported platforms in-between.

 How is my instance licensed when connecting to an existing Exalate network?

When connecting to the Exalate network, you are able to synchronize as long as your remote partner is fully paying for the synchronization using the Exalate network license.

You can install the app unlicensed and keep the License Key field empty in this case. 

This licensing model is not publicly available and we recommended it only in certain cases. 

 Can Exalate for Jira Server work through a proxy?

Yes, it can! You can set up the proxy on your Jira instance. Check Configure an outbound proxy for use in Jira server for more information.



Configuration


 Is it possible to pause a synchronization for maintenance purposes?

Yes, you can pause the synchronization. Synchronization events are queued while a connection is deactivated. You can later resume the synchronization from the moment it was stopped.

 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 incoming sync rules to take into account the new configuration.  

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

When an instance requests another instance to send over the content of an attachment, the other instance will respond with a 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. 

 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 sent and how incoming messages must be handled.  All messages exchanged between the instances are based on a commonly defined 'hub issue' 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.  With the help of groovy-based script rules you 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 difficult is it to configure 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, involves finding the right projectkey in the database table and use it to raise the issue in the right project.  Check the following example showing how this behavior can be configured 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 - 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 is raised. It leads to the problem and we call it stack trace. In case this is not sufficient, you can 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.

 What happens if I change the project key which is under sync?

Whenever a user changes something in an issue, Jira will notify the Exalate about the change by generating an update event. If the issue is under an update gets synchronized.
However, changing the key does not trigger such an event. 
To synchronize a key change, the issue under sync needs to be touched by modifying something or by adding a comment in order to synchronize that information change. 

Additional considerations when changing the project key

  • Review the Incoming sync to make sure that the old project key is not hardcoded.
  • Review the triggers and update the JQL if this is relevant
 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 you would like to send to the other side and how to interpret incoming sync data.

The Outgoing sync rules of the sending side interact with Incoming sync rules 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?

Exalate app for HP QC/ALM supports  HP QC/ALM v. 11.05 - 12.55

 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

 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.

 System requirements to install Exalate app for HP QC/ALM

All you need to know before installing the Exalate app for HP QC/ALM could be found here.

 Is Exalate compatible with Jira 6?

Exalate can be used with JIRA 6.3 and higher.  Due to incompatible API's between JIRA 6 and JIRA 7, it is being published as 2 different distributions.  For administrators installing using the universal plugin manager (UPM) there is no problem, as the UPM will point to the right distribution - which is pretty convenient.  Still - there are a lot of instances which are not permitted to reach out to the marketplace.

 The marketplace is hiding versions which are compatible with older JIRA releases. Find more details.