From time to time, we at Exalate receive customer requests for advanced integration cases. One such request we received was to synchronize Customer Cases in ServiceNow as Epics in Jira.
The use case looked like this
Decoding it further:
Exalate can solve this integration use case with the help of Groovy-based scripting giving it the necessary flexibility.
It has a distributed architecture. So as an Exalate administrator, you can configure both the incoming and outgoing processors on each side independently.
These processors on both Jira and ServiceNow filter what information must be sent and received.
The steps for implementing this use case are:
So start by installing Exalate on both Jira and ServiceNow. It can be done via the Atlassian marketplace (Jira) or by requesting for an integration here (all trackers).
Once Exalate has been installed on both systems, you create a connection between Jira and ServiceNow.
This connection already has default sync behavior to sync summary, description,comments, attachments, etc. But this default behavior will not suffice for this use case, hence we must set up an advanced configuration.
Following can be the possible challenges for the same.
We will divide this in 2 sides: The ServiceNow side and the Jira side
Exalate uses Replica to extract the information to be sent and received and then passes it over to the other side.
entityType is used to decide whether the ServiceNow entity is a Case or a Problem. Depending on this, the information will be interpreted differently in Jira.
If the type is “customerCase”, then short-description, description, comments, attachments and status is sent.
If it is “problem” in addition to the above information, “problem.parent” is also sent.
problem.parent is the Case number that is used to track the problem, since it is required to find the epic back on the Jira side.
The default configuration on the incoming processor includes syncing the summary, description, comments and attachments.
The comments have been kept internal on the ServiceNow side with the help of the following code: customerCase.comments += replica.addedComments.each { it.internal = true }
In addition to this, Groovy scripts are needed to fetch the issue key and the issue_url from the Jira side. This is achieved by adding the code shown in the purple rectangle. This can be used for “problem” as well.
We are done with the ServiceNow end. Now let’s head over to the Jira side.
No changes to the default configuration on the Jira side are required.
Information coming from the ServiceNow side needs to be adapted as per the use case requirement.
There are a few things happening in the code here.
Everything else is explained in the comment section of the code.
Once we decide what information is to be sent and received at both ends, we create triggers for automatically starting the synchronization.
We create a trigger that whenever a Problem or a Case is assigned to the CAB Approval Assignment group, they get Exalated to the other side.
This is all that is needed.
All we are left to do is to first create a Customer Case and assign it to the CAB Approval Group.
The “Sync Queue” on the Exalate panel shows the different stages that a sync goes through, you can check the status of all your sync requests here.
Soon after you can see the issue key and the correlation ID reflected in ServiceNow
On the Jira side, you can see that an Epic has been created with the name similar to the Case in ServiceNow and is a copy of the Case.
Then when a Problem is created under the same Case in ServiceNow and the Assignment Group is set to “CAB Approval”, you can see in Jira that it is reflected as a Story with the correct Epic link.
That’s about it. We saw how an advanced deep integration use case like this can be handled flexibly with Exalate.
If you want to learn more about it, you can book a demo with our experts here, or already start your free trial.
francis
Atlassian expert
Exalate
Belgium
42 accepted answers
0 comments