This article describes the main difference between the Exalate application for supported issue trackers.
Major features are available for all supported platforms. But some functionality might be restricted due to the underlying issue tracker API or the tracker functionality itself.
Below you can find a detailed explanation in a comparison table.
Features | Jira Server | Jira Cloud | HP QC/ALM | GitHub | Zendesk | ServiceNow | Azure DevOps | Confluence Cloud |
---|---|---|---|---|---|---|---|---|
General | ||||||||
Licensing | License is perpetual and the purchase price includes 12 months of maintenance (support and version updates).
| JIRA Сloud is monthly subscription-based license. Therefore you are automatically billed for apps together with host products.
|
|
| ||||
Hosting and data storage | You host the app on your server. JIRA server URL is also the Exalate URL once you install the app. | We are hosting the Exalate app for JIRA Cloud on our own servers. It means that you have 2 separate servers:
The Exalate app has its own Exalate URL, that is different from JIRA Cloud instance URL. There is a possibility for connectivity delays between the JIRA Cloud and the Exalate app. The physical location of the servers that host the app and the instance might affect the connectivity performance. | You host the app on your server. The Exalate app has its own URL, which is different from the your HP QC/ALM URL. | You have 2 separate items:
The app has its own Exalate URL and it' is different from the GitHub repository URL. We host the app on our servers. It communicates with the GitHub repository. | You have 2 separate items:
The app has its own Exalate URL. It communicates with the issue tracker instance. You can reach the app from the Zendesk admin. | You have 2 separate items:
The app has its own Exalate URL. It communicates with the issue tracker instance. You can deploy the app on your own server or we can host the app on our servers. | ||
Backups and updates | Since the app is hosted on your server, you decide how often to update and backup data. | The Exalate app is upgraded automatically. Atlassian automatically detects updates to Atlassian Connect apps with a polling service and updates your app. More details about automatic updates. We perform a back up every hour on the Exalate servers to avoid data loss. If a customer unsubscribes from our Cloud app we mark stored Customer Data, for deletion. The data is deleted after 180 days at the latest if the customer does not re-subscribe. However, the customer can contact us to ask for an earlier deletion. | Since the app is hosted on your server, you decide how often to update and backup data. | The Exalate app is upgraded automatically. We perform a back up every hour on the Exalate servers to avoid data loss. If a customer unsubscribes from our app we mark stored Customer Data, for deletion. The data is deleted after 180 days at the latest if the customer does not re-subscribe. However, the customer can contact us to ask for an earlier deletion. | ||||
Monitoring | Monitoring could be done only by the JIRA server admin, since the app is hosted on the same server, where you host Jira instance. | Since the Exalate cloud app is hosted on our own servers, we do system health monitoring for the app. | Monitoring could be done only by server admin, since the app is hosted on your server. | Since the Exalate app is hosted on our own servers, we do system health monitoring for the app. | For apps hosted on our own servers we do system health monitoring for the app. | |||
Exalate specificThis block includes specific app configuration elements, that may differ depending on the underlying issue tracker | ||||||||
Scope of the sync | Any issue within the instance, not limited to a specific project. | Any issue within the instance, not limited to a specific project. | Limited to a project scope | The scope of the Exalate connection is limited to a single repository with the GitHub user/company account used to installed the app | Any issue within the instance, not limited to a specific project. | Any issue within the instance, not limited to a specific project. | Limited to a project scope | Limited to a space scope |
Exalate/Unexalate buttons | ||||||||
Sync panel | ||||||||
Error flags | ||||||||
Exalate administrators |
| |||||||
Attachments sync | ||||||||
Remote Issue link | ||||||||
WorkLogs | ||||||||
Ways to starts issue sync |
|
|
|
|
| |||
How Exalate gets issue change data | Exalate subscribes on the issue events to get issue changes | Exalate subscribes on the issue events to get issue changes | Exalate polls the issue tracker to get the data | Exalate subscribes on the webhooks to get issue changes | Exalate subscribes on the webhooks to get issue changes | Exalate polls the issue tracker to get the data | Exalate subscribes on the issue events and webhooks to get issue changes | Exalate subscribes on the issue events to get issue changes |
ScriptingMost of the functionality provided in the app is available for all supported platforms, but there are limitations caused by the API for different issue trackers. The app architecture is different for every platform. It affects advanced scripting, which would be different depending on the platform. Below you can see a list of the most common differences in Groovy scripting | ||||||||
API | REST API | REST API (depends on the HP QC/ALM version) | REST API | REST API | REST API | |||
JAVA version | depends on your Jira version | is determined by iDalko, since we host the app on our own servers | depends on the JAVA version, installed on the server, where you have Exalate app running | is determined by iDalko, since we host the app on our own servers | ||||
helper methods |