In 3.2.1 release subscriptions page was hidden. But the page is still there. You can access it using this kind of link :
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.
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.
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.
Yes. Thanks to the groovy goodness, one can parse the newly added comments and trigger a resolve transition
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.
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.
Yes. Each integration point can evolve as long as the hub issue model and Exalate API is respected.
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)
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 firstname.lastname@example.org for further processing.
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.
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 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 Create Processor to make sure that the old project key is not hardcoded.
- Review the triggers and update the JQL if this is relevant
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.