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 1, we began the steps to integrate ISM and Jira. In Part 2 we went through the process of creating the ISM fields necessary for tracking an issue from Jira and the fields needed in Jira to track an issue’s corresponding release from ISM. Those field mappings will come into play here in Part 3 and throughout the rest of the series. In addition to creating all the fields we also found the Field IDs for the two custom Jira issue fields.
If you haven’t read the previous parts of this series, they can be found here:
Overview
In Part 3, we are going to be building the ISM business rules, quick actions and web service connections required to automatically create a corresponding ticket in Jira when a user creates a new release in ISM. We will also create some additional business rules for field initialization and calculations. Next, we will cover the Jira automation rule that will automatically create a new ticket in ISM when an issue is created by a user in Jira. One thing that is new this time around is making use of PostMan to retrieve the action ID of an ISM quick action. We will need the action ID for the Jira automation rule. At the end of the blog, I’ll walk you through a simple test to verify everything has been set up properly.
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)
Before we get started, here is a brief overview of what our final goal is with this series.
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 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 3, we will be setting up all the automation that will occur when a Release/Issue in one application and a corresponding Issue/Release is created in the other application.
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 Release
When a user creates a release in ISM that is a “Jira bug” or a “Jira enhancement”, the automation is triggered on save by an ISM business rule and creates the corresponding bug or enhancement in Jira. Business rules only run if specific conditions are met. Here, we will specify that only new releases originating from ISM should be pushed to Jira.
A user creates a new release and hits the save button triggering the business rule.
The business rule triggers a quick action.
The quick action runs a web service script in a web service connection.
The script makes a POST web request to Jira.
The web request creates the issue in Jira with the ‘Initiator’ field set to the service account.
Web Service Connection
Let’s first set up the script that will be called by the quick action.
1. Navigate to the configuration console and in the left navigation list select Extend > Web Service Connections to get to the Web Service Connection Manager.
2. Click on New Integration, name the integration “AAA – Integration: Lab Push Release to JIRA”, provide a description, and click Next.
3. Paste the corresponding script contents from Lab Push Release to JIRA.txt into the Scripts * section.
4. Next, go through the script and make sure you understand what is going on. As you read through it, replace the necessary fields that I have placed comments next to in Figure 3 above.
5. Click Next to the Schedule Setting screen.
6. Click Next through this screen and confirm Yes you want to proceed without scheduling.
7. On the Review and Publish screen click Publish.
You have successfully created the web service connection that will be triggered by the quick action. Let’s move on to setting up the quick action.
Quick Action
1. From the release business object, click on the Quick Actions tab to open the Action designer.
2. Click Create New Actions, and select Web Service Script.
3. Configure the quick action:
Set the action name to Quick Action: Lab Push Release to JIRA.
Select AAA – Integration: Lab Push Release to JIRA in the Connection drop-down list.
In the Publish to drop-down, select Administrator.
4. Click the Save button at the top of the configuration to save your new quick action.
Business Rules
Next, we need to make some business rules. One of which will be the trigger for the quick action we just made. We’ll also make some other business rules for general functionality in ISM.
1. From the Configuration Console, click on Build > Business Objects in the left-hand navigation pane.
2. Select the Release business object.
3. Select the Business Rules tab.
4. Expand the TRIGGERED ACTIONS drop-down and click Add Trigger.
7. Name the trigger “Lab Push Release to JIRA” and select the On Insert check box in the Object Event section.
6. Click on the conditional expression text box and enter the following condition: $(if (TypeOfRelease == "JIRA Bug" || TypeOfRelease == "JIRA Enhancement") && LAB_JIRAIssueNumber == "" then true else false)
7. Click Save in the condition pop-up.
8. Click Next>> in the trigger configuration to get to the Create Trigger Action page.
9. Select the Use copy of existing action radio button and select Lab Quick Action Push Release to JIRA from the drop-down menu.
10. Click Save to save the business rule.
Next, we need to add some initialization rules for all the custom fields we created. I’ll walk you through the first one. You can repeat the steps for the rest based on the table below (Figure 12).
Rule Name | Details |
Initialization Rule for ReleaseProject.LAB_JIRAIssueNumber | Field: LAB_JIRAIssueNumber Expression: $(EmptyString()) |
Initialization Rule for ReleaseProject.LAB_JIRAReleaseCreatedbyISM | Field: LAB_JIRAReleaseCreatedbyISM Expression: No |
Initialization Rule for ReleaseProject.LAB_JIRAAttachmentContentURL | Field: LAB_JIRAAttachmentContentURL Expression: $(EmptyString()) |
Initialization Rule for ReleaseProject.LAB_JIRAAttachmentFilename | Field: LAB_JIRAAttachmentFilename Expression: $(EmptyString()) |
Figure 12
1. Navigate to the Business Rules tab of the release business object and expand the Initialization Rules drop-down.
2. Select Add Initialization Rule.
3. Configure the rule based on the details in Figure 12.
4. Click Save. If a warning appears, click Save again to continue.
5. Repeat for each initialization rule specified in Figure 12.
Next, we need to add a calculation rule. This rule is for setting the field “LAB_JIRAReleaseCreatedbyISM”.
1. Still in the Business Rules tab, expand the EDITING AND CALCULATION RULES list.
2. Click Add Calculation Rule.
3. Configure the calculation rule as shown below (Figure 15).
The last business rules you’ll need for releases are required rules. Use the following table (Figure 16) to fill in the various configuration fields.
Rule Name | Details |
Required Rule for ReleaseProject.LAB_JIRAIssueType | Field Name: LAB_JIRAIssueType Conditionally required Expression: $(TypeOfRelease in ("JIRA Bug", "JIRA Enhancement")) |
Required Rule for ReleaseProject.LAB_JIRAPriority | Field Name: LAB_JIRAPriority Conditionally required Expression: $(TypeOfRelease in ("JIRA Bug", "JIRA Enhancement")) |
Required Rule for ReleaseProject.LAB_JIRAProjectName | Field Name: LAB_JIRAProjectName Conditionally required Expression: $(TypeOfRelease in ("JIRA Bug", "JIRA Enhancement")) |
Figure 16
1. In the Business Rules tab expand the REQUIRED RULES drop-down.
2. Click Add Required Rule.
3. Configure the rule based on Figure 16.
4. Repeat for the rest of the required rules in Figure 16.
Jira Issues
Importing Automation Rules
To import the provided automation rules, you will need to be a global administrator. JSON files for each of the automation rules can be found here: https://github.com/CriticalDesignAssociatesInc/Integrate_Jira_With_ISM_Blog. Once you have the JSON files, you can then import those automation rules into any Jira instance.
1. In Jira settings, select System > Automation rules.
2. In the top right corner, select … > Import rules.
3. Select Upload JSON or drag and drop your JSON file to the area inside the dotted line.
4. Select the rules you want to import and click Next.
5. Select Let's do this to finish the import.
6. Repeat steps 2-5 to import all the automation rules:
Lab Create ISM Release
Lab Push Attachment to ISM
Lab Sprint Started
Automation Rule: Lab Create ISM Release
We are tracking issues that are either bugs or enhancements. Both of which are initially created in the backlog. To get from the Jira column in our diagram (Figure 1) to the ISM column the following occurs:
A user creates an issue in Jira triggering the automation rule.
The automation rule makes a POST web request to ISM.
The web request creates a new release business object in ISM.
The automation rule gets run every time a new issue is created. If the issue originated from Jira it will not yet have an ISM RecId. If the issue does not have an ISM RecId, the automation rule determines whether the issue is a bug or an enhancement and creates the corresponding release in ISM with a POST web request. Looking at the automation rule “Create ISM Release”, there are some changes you will have to make to the web request.
1. Open the Lab Create ISM Release automation rule.
2. In the first Then: Send web request component update the text “YOUR_TENANT_LINK_HERE” to your ISM tenant in the Webhook URL.
3. Then, in the Headers section change “YOUR_ISM_API_KEY_HERE” to the key we generated for the ISM service account.
4. Do this in both Then: Send web request components of the automation rule.
5. Save your configurations and publish the automation rule.
Testing Issue and Release Creation
ISM to Jira
To test our integration let’s begin by creating a new release in ISM. Here’s how mine is configured:
Click Save and head over to the Jira project you sent the Bug to.
In the Backlog in my list of Issues there is a new Bug called “Test Bug: Release # …”.
When I click on the bug for more details, we can see that it was created by the service account. We also see it has the correct Description, Priority, and ISM RecID.
Now if I hop back to the release in ISM and refresh, you can see that the Jira Issue Number has been updated to “CIJB-15” to match the issue in Jira.
Jira to ISM
In Jira, open the BACKLOG of the project you want to test out of and create a new issue. The project should be one that you added to the project pick list in ISM. I used CIJB.
I created a Bug for this test and entered a Summary, Description and set the Priority to Low.
After clicking “Create”, the bug will appear in my Backlog.
My bug will also be updated with an ISM RecID. When I go into the details for the bug, I can see that the ISM RecID field has been populated.
Now, when I go into the list of all the releases in ISM, I can see my bug.
And, when I go into its details all the fields have been automatically filled out (Figures 32 and 33).
Conclusion
If you’ve been following along with this series, you have just completed the first big piece of the integration. As you may have already begun to suspect things are a bit more complicated than the first diagram (Figure 1) with just a user action and an outcome. Let’s look a bit more in depth into what we’ve accomplished so far.
Look at the components that make up the automation that sends a release in ISM to Jira (Figure 34).
The workflow starts with the user action that kicks off the business rule we made.
The stretched-out diamond is the condition we set up in the business rule.
The web service script makes the API call to Jira that creates the corresponding issue.
Next, look at the flow of release creation from Jira to ISM (Figure 35). This one is brief, but it demonstrates how powerful automation rules in JIRA really can be. The user action triggers the automation rule, and the automation rule verifies that the issue originated from Jira then makes the API call to ISM to create the release.
After completing parts 1, 2, and 3 you should be able to effectively track Issue/Release creation in Jira and ISM. Although this blog does not specifically cover updating fields within Jira Issues or ISM Releases, if you complete and understand Parts 4 and 5, you should have the knowledge to challenge yourself and build that portion into the lab on your own!
Resources
The web service scripts and automation rules can be found on GitHub:
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!