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.
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 synchronization processors.
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.
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 data filter) This replica is stored:
on the source, tracker to detect if relevant changes have been made since the last synchronization
in the destination, a tracker to provide the content of the previous version.
Yes - the synchronization panel will detail out all information relevant to the synchronization.
Not yet - we are working on it. When staging exalate 1.3 or earlier, make sure that the synchronization engine is not triggered by deactivating all instances.
When you delete an issue Exalate consider it as a synchronization event. It triggers 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.
Not at all - every application administrator can define how 'hubissues' are translated to the local context.
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.
Yes. Right now, Exalate is compatible with JIRA Server, JIRA Cloud, HP QC ALM, GitHub, Zendesk and Service Now. We are working on the integration with other issue trackers.
There are no limits to sending information using the customKeys property of a replica. It allows sending any arbitrary object which will get serialized at one end and deserialized at the other.
Synchronization is unlimited between supported platforms as long as Exalate is installed on each instance. We provide 2 licensing models:
- Instance licensing - the model, where each instance requires a valid license to synchronize.
- Network licensing - the model where only one side pays for the synchronization between instances.
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.
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.
Exalate is already in use since 2014 at different enterprises. The Exalate has been configured as a single-threaded application which processes the synchronization transactions one at a time. This has 2 consequences
- A minimal system load, as the exalate can be compared to a single user who is working hard to update/retrieve information
- 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
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.