Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,463,739
Community Members
 
Community Events
176
Community Groups

Synchronizing a Customer Case in ServiceNow to an Epic in Jira

image11.png

 

 

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

The use case looked like this

 image3.png

Decoding it further:

  • When a Case is assigned to the “CAB Approval” assignment group in ServiceNow, then an Epic on the Jira side must be created automatically through triggers. 
  • The Epic name, which is a mandatory Jira field, must be set to the Case identifier.
  • On the ServiceNow side, the Correlation.Id field for the Case must include the Jira issue key and a custom field called “Issue Key” must provide a direct link to the Jira issue. 
  • When a Problem is created under that specific Case, it must be automatically synced (or Exalated, we like to call it that) under the corresponding Epic in Jira as Story. 
  • Correlation.Id and the “Issue Key” field must also be set for Problems. 
  • Comments and attachments need to be synced over, but Jira comments on the ServiceNow side must reflect as “Work Notes”, not visible to the customers. 

The Integration Solution: Exalate

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:

  1. Installation of Exalate
  2. Creating a Connection
  3. Configuration of Information
    1. Configuring what information to send from ServiceNow to Jira: Outgoing processor of ServiceNow
    2. Configuring what information to receive from Jira to ServiceNow: Incoming processor of ServiceNow
    3. Configuring what information to send from Jira to ServiceNow: Outgoing processor of Jira
    4. Configuring what information to receive from ServiceNow to Jira: Incoming processor of Jira
  4. Configuration of Triggers 
  5. Synchronization 

Implementation with Exalate

Installation

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). 

 

Creating a Connection

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. 

  • Creating the trigger for automatic syncing of Cases and Problems over to Jira.
  • Displaying issue related information (esp the issue key and URL) for Cases and Problems on the ServiceNow side.
  • Maintaining parent child relation between Cases-> Problems in ServiceNow as Epic-> Story in Jira. 
  • And finally, keeping the comment visibility private in ServiceNow. 

 

Configuration: Deciding Incoming and Outgoing Information

 

We will divide this in 2 sides: The ServiceNow side and the Jira side

ServiceNow: Outgoing Processor 

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. 

 image4.png

 

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.

 image5.png

ServiceNow: Incoming Processor

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 }

 

image8.png

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. 

Jira: Outgoing Processor

No changes to the default configuration on the Jira side are required. 

Jira: Incoming processor

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. 

  • The firstSync variable denotes what must happen when the entity from ServiceNow is synced for the first time. 
  • Based on the entityType from ServiceNow: Case -> Problem either an Epic-> Story will be created or a Task in all the other cases. 
  • A switch case is used to switch between the different entity types and depending on the entity type, appropriate information is applied on the Jira side. 

Everything else is explained in the comment section of the code. 

 image12.png

Setting the Triggers

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. 

image2.png

Syncing Information 

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. 

 

image6.png

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. 

image9.png

 

Soon after you can see the issue key and the correlation ID reflected in ServiceNow

 image10.png

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.  

 

image7.png

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. 

 image1.png

Conclusion

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



0 comments

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events