Now to resolve on Jira’s end whether if this issue already has a link to the issue provided on the “jiraIssueKey” custom field(so it connects to it) or if it needs to be exalated into a new issue we would use the following snippet on Jira’s incoming sync:
Jira Incoming:
if(firstSync) {
if (replica.jiraIssueKey) {
Map<String, Object> responseJson = new JiraClient(httpClient).http(
method = "GET",
path = "/rest/api/2/issue/${replica.jiraIssueKey}",
queryParams = [:],
body = null,
headers = [:]
) { response ->
if (response.code >= 300 && response.code != 404) {
throw new com.exalate.api.exception.IssueTrackerException("Failed to perform the request (status ${response.code}), and body was: \n\"$response.body\"\nPlease contact Exalate Support: ".toString() + response.body)
}
if (response.code == 404) {
return null
}
def responseStr = response.body as String
def _responseJson = responseStr ?
new groovy.json.JsonSlurper().parseText(responseStr) as Map<String, Object>
: null;
_responseJson
}
if (responseJson.id != null) {
issue.id = responseJson.id
}
}
if (issue.id == null) {
// if we didn't instruct Exalate to connect to an existing issue, sync back the created issue key, so ZD knows, where it was synced to
syncHelper.syncBackAfterProcessing()
}
...
}
Note: mind the name of the custom field being send from Zendesk, in this example we used “jiraIssueKey”, therefore we receive it as “replica.jiraIssueKey” (This is short syntax for “replica.customFields.jiraIssueKey.value” but any of the 2 methods would work).
The result is that whenever you have a Zendesk ticket that you know should be connected to a given Jira issue key, you can set this Key in the “jiraIssueKey” and Exalate will do the job.