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.
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:
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:
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 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 is a tool used for API development. It offers the ability to collaborate, and easily build or dissect APIs.
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.
AAA – Integration: Lab Push Attachment to JIRA
Lab Push Attachment to JIRA.txt