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
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
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.
Absolutely. The synchronization panel shows all relevant details - even if the remote issue has been removed.
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.
Yes. Right now, Exalate is compatible with JIRA Server, JIRA Cloud and HP ALM. We are working on the integration with other issue trackers.
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.
Yes. Thanks to the groovy goodness, one can parse the newly added comments and trigger a resolve transition
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.
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.
Yes - check the relation and/or instance configuration - these can be activated / deactivated if necessary.
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.
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.
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.
As an example - when the proxy user is not allowed to modify the local issue due to issue security
Typical example - when there is an error in the processor scripts, or when there is a permission problem to apply changes to an issue
A connection problem
Bugs in the synchronization layer.
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 email@example.com for further processing.
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)
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.
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.
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.
Yes. Each integration point can evolve as long as the hub issue model and exalate api is respected.
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 .
Yes - the synchronization panel will detail out all information relevant of the synchronization
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.
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
Not at all - every application administrator can define how 'hubissues' are translated to the local context
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
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 to enable debug logging permanently — In the cases where you need to have a closer look at what the add-on is executing in the background, you can enable logging as described in this article.
How to enable temporarily debug logging — In the cases where you need to have a closer look at what the addon is executing in the background, you can enable logging temporarily