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 1, we began the steps to integrate ISM and Jira. In Part 2 we take the next step. By the end of this series, you will have the foundation that can be used for developing your integration between your Ivanti Service Manager (ISM) and Jira Software platforms.
In the previous blog, we set up the service accounts required to communicate between Jira and ISM. Along with the service accounts, we generated the API tokens needed for authentication for each service account in the other system. The service accounts provide us with two advantages: we can easily track what issues/releases are created in the other system, and they allow us to avoid an infinite loop of creating tickets and releases between the systems. Once the service accounts and API tokens were created, we used PostMan to validate successful connections to both ISM and Jira.
If you have not already read Part 1 it can be found here: https://www.criticaldesign.net/post/how-to-integrate-jira-with-ivanti-service-manager-part-1-service-accounts-and-api-keys
In this blog, we will be reviewing all the modifications needed in Jira and ISM to accurately reflect the tickets in the opposite systems. This will include ISM custom fields such as the Jira Project Name, the issue type, status, and issue number. We will also need to create custom fields in Jira to map to ISM, such as RecID and SprintRecId.
Before we get into the creation of custom fields, here is a brief overview of the entire lab we are building over the five parts of this series.
Overview
The integration between ISM and Jira allows for seamless communication. It automatically creates a corresponding ticket for the reported issue in the opposite platform. Integrating the two systems 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 2, we will be creating the fields required to track corresponding Issues and Releases in Jira and ISM.
The process diagram below outlines the workflow for the two systems and the final prototype deployment:
Figure 1
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.
Joining/Tracking between ISM and Jira
Mapping fields between ISM Releases and Jira Issues will take some additional custom fields. For example, an issue’s status or type in Jira is something that should be reflected in the corresponding ISM Release. By adding these fields, a release in ISM will more thoroughly reflect an issue in Jira and vice versa.
ISM Custom Fields
We are using the Release object to represent sprints and two issue types: bugs and enhancements. It is likely that you will have other release types and fields unrelated to Jira, so we will use the following naming convention: LAB_JIRA<NameofField>.
To track issues, we will need the release business object to store the following new fields:
Field Name | Details |
LAB_JIRAStatus | Display Name: JIRA Status Field Type: Text Text Length: Variable, max 32 |
LAB_JIRAIssueType | Display Name: JIRA Issue Type Field Type: Text Text Length: Variable, max 32 |
LAB_JIRAPriority | Display Name: JIRA Priority Field Type: Text Text Length: Variable, max 32 |
LAB_JIRAIssueNumber | Display Name: JIRA Issue Number Field Type: Text Text Length: Variable, max 32 |
LAB_JIRAProjectName | Display Name: JIRA Project Name Field Type: Text Text Length: Variable, max 50 |
LAB_JIRASprintName | Display Name: JIRA Sprint Name Field Type: Text Text Length: Variable, max 32 |
LAB_JIRAReleaseCreatedbyISM | Display Name: JIRA Release Created by ISM Field Type: Text Text Length: Variable, max 32 Validated: Checked Pick List Name: YesNo |
LAB_JIRAAttachmentContentURL | Display Name: JIRA Attachment Content URL Field Type: Text Text Length: Variable, max 200 |
LAB_JIRAAttachmentFilename | Display Name: JIRA Attachment Filename Field Type: Text Text Length: Variable, max 200 |
Figure 2
We also will be working with attachments. These are the fields that will need to be added to the attachment business object.
Field Name | Details |
LAB_JIRAAttachmentType | Display Name: JIRA Attachment Type Field Type: Text Text Length: Variable, max 32 |
LAB_JIRAParentObjectID | Display Name: JIRA Parent Object ID Field Type: Text Text Length: Variable, max 32 |
Figure 3
Creating a Field
You will need to add all the fields from Figure 2 to the release business object and the fields from Figure 3 to the attachment business object. I’ll walk you through the first one, and you can repeat the steps to add the rest.
1. From the Configuration Console, click on Build > Business Objects in the left-hand navigation.
2. We are working with the Release business object so click on Release to view the object.
3. Select the Fields tab. You will see a list of the default fields.
4. Click Add New…
5. Select the Text field type. The system will display the Setting Field Details workspace.
6. Enter information for the new field in the fields based on the details in Figure 2 or 3.
7. Click Add This Field at the bottom of the configuration.
8. Back at the list of fields be sure to click Save next to the Details tab.
9. Repeat these steps for all the fields in Figure 2 and 3.
Creating Pick Lists for Fields
Some fields will need pick lists to be validated from. For example, the priority of an issue can only be one of the following: lowest, low, medium, high, highest. I’ll walk you through the steps to create the pick list for LAB_JIRAIssueStatus. You will repeat these steps for all the fields that require a pick list. I have specified the field names and the values that will go in the pick list in the table below (Figure 9).
Field Name | Pick List Values |
LAB_JIRAIssueStatus | To Do In Progress Done Note: If you use other statuses in JIRA feel free to add them too. |
LAB_JIRAIssueType | Bug Enhancement |
LAB_JIRAPriority | Lowest Low Medium High Highest |
LAB_JIRAProjectName | Note: Add your JIRA projects. I added CIJB and a couple others. |
Figure 9
In addition to creating the pick lists in Figure 9, you’ll need to update the pick list of the field TypeOfRelease, see Figure 10.
Field Name | Pick List Values |
TypeOfRelease | JIRA Bug JIRA Enhancement JIRA Sprint *Note: Leave all preexisting values and just add to the list* |
Figure 10
Let’s get started.
1. Click on Business Objects in the navigation pane.
2. Click on New Object.
3. Select Stand-alone Business Object.
4. Give the new Business Object the same name as the field you are making the pick list for.
5. Click on the Fields tab and click Add new.
6. Select Text.
7. Set the Field Name and Display Name (these will be the same as the name of the new business object).
8. Click on Add This Field at the bottom of the page.
9. Make sure to hit Save back at the list of fields just like we did with adding the fields earlier.
10. Click on the Details tab and click AUTO GENERATE UI.
11. Click OK in the pop up.
12. The details should look like this now:
13. Save the business object.
14. Click on Pick Lists in the left navigation pane.
15. Click ADD NEW.
16. Configure the pick list.
The List name and Display name will be the same as the field name we are making the pick list for.
Select the business object we just finished configuring from the Get list data from drop down menu.
Select the field with the same name as the business object in the Display field, Value field and Sort by field dropdowns.
17. Save the pick list.
18. Open up the Release business object and select the Fields tab.
19. Select the field you’re making the pick list for.
20. Check the box next to Validated under Pick List and set the Pick List Name to the matching list we just finished making.
21. Click values in the Pick List section to open the pop-up below.
22. Click Add and add the pick list values specified for the field in Figure 9 or 10.
23. Click Close and save your release business object.
24. Repeat for all fields in Figure 9 provided at the beginning of this section.
25. Repeat from step 18 to update the field as specified in Figure 10.
Adding the Fields to a Form
Next, we need to add our fields to a form so that a user filling out a new release can use them. I added mine to the ReleaseProject.CustomerOwnershipForm form. If you would like to put your fields on a different form, feel free to do so just make sure that the form is visible when a user goes to create a new release.
1. Navigate to the Release business object and select the Forms tab.
2. Select the form you want your fields to go on (I used ReleaseProject.CustomerOwnershipForm) or create a new one. To start, my form looked like this:
3. Use the drop down on the left to locate our custom fields.
4. From here drag and drop the fields into the form as desired. Here’s mine after adding the fields. I also added in Status and RecId for testing purposes later.
5. Add any styling to your form that you’d like and click Save when you’re finished.
6. For more information on customizing forms check out: https://help.ivanti.com/ht/help/en_US/ISM/2017.3/Content/Configure/Forms/Forms.htm
My form looked like this after adding my fields:
Jira Custom Fields
Let’s look at Jira. To track the corresponding release in ISM, Jira needs to track the release’s record identifier. You will be adding the fields I have specified in the table below (Figure 30).
Name | Description |
ISM RecId | Record identifier of corresponding release in ISM (single line text) |
ISM Sprint RecId | Record identifier of the related sprint release in ISM (single line text) |
Figure 30
1. In Jira, navigate to Settings > Issues.
2. Click on Fields > Custom fields in the left-hand navigation list.
3. Click the Create custom field button in the top right of the page.
4. We will be making a single line text field.
5. Give the field a name based on the table in Figure 30.
6. Select the screens that you want to associate the new field with and click update at the bottom of the list. I am working out of a project called “CDA ISM Jira Blog” so my field is associated with CIJB:Scrum Bug Screen and CIJB: Scrum Default Issue Screen.
7. Follow steps 2-6 to add the other field from Figure 30.
Once you have created both custom fields, you’ll need to determine their field IDs. The field ID is a unique identifier that Jira uses to label the field, and we will need these IDs for the body of REST API calls later in the lab.
1. Again, navigate to Settings > Issues.
2. Click on Fields > Custom fields in the left-hand navigation list.
3. Using the search bar look up ISM RecId.
4. Select the ellipses on the far right for the field and click on Edit details.
5. The field ID will be in the URL as secure/admin/EditCustomField!default.jspa?id=#####. Based on the URL for my details page my field ID for ISM RecID is 10061.
6. Make note of the ID for the ISM RecID and repeat from Step 9 to find the ID for ISM Sprint RecID. We will need both of these IDs later.
7. We also need the ID for the Sprint field. When you click on the ellipses select View field information and find the ID in the URL like we did for the other two. Make note of it for later.
Summary
In this blog we covered creating fields, pick lists, business objects and forms in ISM and creating custom fields in Jira. Field mapping between ISM and Jira is now complete. I only covered a bare minimum of potential fields for tracking, so feel free to add any other fields that may be relevant to your specific use case. In Part 3, we will set up the automation required for communicating Jira Issues and ISM Releases back and forth between the two applications.
If you’ve been following along make sure to save the following information with your details from Part 1 before moving on to Part 3:
JIRA Field ID for ISM RecID
JIRA Field ID for ISM Sprint RecID
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!