IT Operations and DevOps teams often use separate platforms for tracking their work. Integrating these separate platforms together provides values. Teams are more efficient in keeping statuses in sync. This blog series provides an example of how to integrate these two platforms. For our ITSM platform we use Ivanti Service Manager (ISM). For our DevOps platform we use Jira Software.
Review
In Part 3 of this series, we completed building the automation for creating releases. The ability to push the details of a release or issue was made possible by API requests in automation rules and business rules. In Jira, an automation rule was used to send the web request with a custom payload, and in ISM, we made use of a business rule chained with a quick action that called a web service script to build and send the API call.
If you missed previous blogs in this series, they can be found as follows:
Overview
In Part 4, we will be adding the ability to track attachments in both Jira and ISM. You will be following a very similar process for setting up business rules, quick actions, and web service connections. For Jira, we will set up a webhook and an automation rule to push attachments to ISM.
To continue forward with this lab, make sure that you have the following:
API keys for both the Jira and ISM service accounts
The email associated with the Jira service account
The user ID of the Jira service account
The field IDs for both custom fields in Jira
The .json files for the Jira automation rules (found here: https://github.com/CriticalDesignAssociatesInc/Integrate_Jira_With_ISM_Blog)
The scripts used in the web service connections (found here https://github.com/CriticalDesignAssociatesInc/Integrate_Jira_With_ISM_Blog)
The PostMan collection containing some helpful requests (https://github.com/CriticalDesignAssociatesInc/Integrate_Jira_With_ISM_Blog)
At the end of this series, you’ll have an effective prototype to build your integration between ISM and Jira Software.
Before we get started, let’s quickly review what our final goal is for the series and the lab buildout.
The integration between ISM and Jira allows for seamless communication. It automatically creates a corresponding ticket for the reported issue in the opposite platform. Removing the extra steps of recreating and filling out the details of the issue a second time eliminates potential human error and saves time. The synchronized reflection of data between the two systems makes it easy for stakeholders such as developers, administrators, and auditors to track software issues in ISM throughout the software development lifecycle as they change statuses in Jira.
Jira issues are represented as releases in ISM. Attachments providing insight into the issues can be added from either end. Issues can be organized into sprints from Jira to support agile or scrum software development. In Part 4, we will automate the process of adding attachments to corresponding Jira issues and ISM releases.
The process diagram below outlines the workflow for the two systems and the final prototype deployment:
Lab Overview
To support this blog, I have provisioned the following lab components:
Ivanti Service Manager-Cloud
ISM is an IT service management software: a help-desk application for submitting IT service requests, reporting issues with applications or equipment, and getting status updates.
JIRA Software-Cloud
JIRA is an issue and project tracker used by development teams for use as an organized to-do list that follows each task through development, testing, and resolution.
PostMan
PostMan is a tool used for API development. It offers the ability to collaborate, and easily build or dissect APIs.
ISM Attachments
Attachments added to releases on ISM trigger a business rule on save. This integration was built to handle .docx, .xlsx, txt, .pdf, .png, .jpeg, and .mp4 files. They are a little different from releases because we need a special quick action that can be triggered by Jira later in an automation rule. We will be making two web service connections, two quick actions, and one triggered business rule to allow for communication. For pushing an attachment from ISM to Jira the following occurs:
The business rule triggers the quick action.
The quick action triggers the web service script.
The web service script makes a POST web request to Jira.
The POST pushes the new attachment to the related Jira issue.
Web Service Connections
We’ll build the web service connections called by the quick actions first. Refer to the table in Figure 2 for names and which scripts to use.
Integration Name | Script |
AAA – Integration: Lab Push Attachment to JIRA | Lab Push Attachment to JIRA.txt |
AAA – Integration: Lab Get Attachment from JIRA | Lab Get Attachment from JIRA.txt |
Figure 2
You can follow the steps in Part 3 of this series to create the two web service connections specified in Figure 2. You should have three connections at the top of the Integration list.
Quick Actions
We need to set up two quick actions, one for each of the web service connections we made. The first quick action will be created under the release business object, and the second will be created under the attachment business object.
Business Object | Quick Action Name | Connection Name |
Release | Quick Action: Lab Get Attachment from JIRA | AAA – Integration: Lab Get Attachment from JIRA |
Attachment | Quick Action: Lab Push Attachment to JIRA | AAA – Integration: Lab Push Attachment to JIRA |
Figure 4
Follow the steps we completed for setting up the quick actions in Part 3 of the series.
IMPORTANT: Make sure that you create each quick action under the proper business object.
The Quick Action: “Lab Get Attachment from JIRA” is special because it is only getting called from Jira. To call the quick action in Jira, we need to find its action ID. We will be using PostMan to get the action ID. I have included the structure of the request in the Get Release Metadata request.
1. Open the Get Release Metadata Request.
2. Similar to when we were authenticating to ISM, add your tenant URL and API key where necessary.
3. This request will grab all the metadata for the release business object so a successful response will be pretty large and look something like this:
4. Search the response (ctrl/cmd + f) for the name of the quick action for getting a new attachment from Jira.
5. Locate the PropertyValue tag under the Action tag with the name of our quick action. Make a note of the string. We need it for our Jira automation rule.
Business Rules
Moving onto the business rules. If you are unfamiliar with the process for creating Business rules in ISM, check out Part 3 of this series where I go through the process step by step. Use the table in Figure 8 to configure the attachment business object’s business rules.
Name | Details |
Triggered Action Lab - Push Attachment to JIRA | Object Event: On Insert Conditional Expression: $(if nvl([ReleaseProject#.]LAB_JIRAAttachmentContentURL, "") == "" then true else false) Action: calls Web Service Script Lab Push Attachment to JIRA |
Calculation Rule for Attachment.LAB_AttachmentType | Condition: BeforeSave Expression: $(if Find(".txt", ATTACHNAME) != "-1" then "txt" else EmptyString()) |
Initialization rule for Attachment.ParentObjectID | Expression: ParentObjectID = 12345 |
Calculation Rule for Attachment.ParentObjectID | Condition: AfterSave Expression: $([ReleaseProject#.]RecId) |
Figure 8
The rule names specify which kind of business rule to make. As always, don’t forget to save!
Jira Automation Rules and Webhooks
We will be making use of automation rules and webhooks in Jira to do the grunt work of the integration. Jira is great because you can import and export automation rules. I have provided the structure of all the automation rules you’ll need to complete this lab. I will walk you through the changes you’ll need to make to use the custom fields and API key you created in Parts 1 and 2 of the series. Make sure that you understand each component of the automation rules, so you will be able to add on to the integration if desired.
Attachments added to Jira issues can be several file types. This integration supports .txt, .docx, .pdf, .xlsx, .png, and .mp4 file types. This ability to add attachments to issues was included in the integration to make reporting easier. A user reporting a bug can include images or a video of how they recreate it rather than just explaining it in text. Beginning with the Jira side, the flow of processes is as follows:
When a user adds an attachment to an issue, a webhook is triggered.
The webhook then kicks off an automation rule.
The automation rule makes a PUT and a POST web request to ISM.
- The PUT web request sends details of the attachment to ISM.
- The POST request calls a function in ISM to retrieve and add the attachment to the related release.
Let’s begin by configuring a webhook that will trigger the automation rule.
1. Navigate to your webhooks and click Create a webhook.
2. Name the webhook and provide a description.
3. Check the box next to “created” under Attachment.
4. Next, we need to go into our automation rule “Lab Push Attachment to ISM” and click on the When: Incoming webhook component.
5. Click Regenerate. Then click Copy URL to copy the webhook URL to your clipboard.
6. Back in your webhook configuration, paste the URL we copied in Step 5 into the URL field and add ?issue=${issue.key} to the end of it.
7. Save your webhook.
The automation rule will require some configuration on your part. Let’s go and make those changes now.
1. In the If: component set the Second Value to the id of the service account you found in the beginning of the lab.
2. In the PUT web request, update the URL with your tenant URL and change replace ISM_RECID_ID with the field ID for ISM RecID.
· For example: {{issue.customfield_ISM_RECID_ID}} will become {{issue.customfield_10061}} if the field ID for ISM RecID is 10061.
3. Still in the PUT web request, update the header with your ISM API key.
4. In the POST web request, update the Webhook URL with your ISM tenant URL, and the field ID for ISM RecID.
5. In the body of the POST web request, you will need to replace all instances of ID_FOR_GET_ATTACHMENT_QUICK_ACTION with the ID of ISM quick action Lab Quick Action Get New Attachment from JIRA we found using PostMan.
6. Also, in the body of the POST web request replace all instances of ISM_RECID_ID with the field ID of ISM RecId.
7. Save your configurations and publish the automation rule.
Test Adding an Attachment
ISM to Jira
To test sending an attachment from ISM to Jira I’m going to open a Release that has a corresponding Issue in Jira. The release depicted in Figure 15 is the one I created to test creating a Release in ISM and pushing a corresponding one to Jira.
In the Details tab of the release we just created, click on ATTACH. Use your file explorer to select a file to attach to the release and save the release. I used a text file.
When I go and look at the corresponding issue in Jira, I see my attachment.
Jira to ISM
The next part of the automation to test is sending an attachment from Jira to ISM. Find a Bug or Enhancement in Jira that has a corresponding release in ISM.
I opened the bug I made in part 3 to test Issues/Release and clicked the Attach button.
In the dialog, I used my file explorer to find a .txt file and added it to the bug.
Back in ISM in my corresponding release, I clicked Refresh (next to the Save button) and saw the attachment that I added to the bug in Jira.
Conclusion
You can now track attachments added to Jira issues and ISM releases. Now let’s look at what we just built. The integration has a few more intermediary steps than our first diagram (Figure 1) with just a user action and an outcome.
In ISM a user adding an attachment will kick off the “Push Attachment to JIRA” business rule. The business rule triggers a quick action, and the quick action triggers a web service script that sends the attachment to the corresponding Issue in Jira. The attachment being added to the Jira issue triggers the Jira webhook. To prevent thrashing between the two platforms, we use a condition in the automation rule to determine if the issue was added by the service account. If it was added by the service account, then we know that it came from ISM and not a Jira user.
Attachments being sent from ISM to Jira follow this flow of communication:
When sending an attachment from Jira to ISM, like in Figure 21, the webhook gets triggered and kicks off the automation rule. Since a Jira user added the attachment to the issue, the automation rule will pass the content URL and the filename to ISM and trigger a quick action that uses that information to pull the attachment to ISM.
Adding the ability to track attachment in Jira and ISM is helpful both in reporting and in the stages of an issue’s lifecycle as it is worked, tested, and completed. In the final part of the series, we will be working with sprints. The ability to track sprints will be helpful for auditing and looking back at work that was completed within a given period of time.
Resources
My PostMan collection, Jira automation rules, and scripts used for ISM web service connections can all be found here:
Still have questions or want to discuss Jira Software, Ivanti Service Manager, and/or their integration further? Reach out to us at CDA. We’d love to discuss how we can help you with your DevOps and automation needs!