Integrating with JIRA

JIRA is a proprietary issue tracking product, developed by Atlassian. It provides bug tracking, issue tracking, and project management functions.

If the eG manager is integrated with JIRA, then eG alerts are automatically routed to JIRA, where they trigger the creation and assignment of trouble tickets to relevant maintenance personnel.

To ensure that eG integrates with JIRA, do the following:

1. Login to the eG administrative interface.

2. Select the Manager option from the Settings tile.

3. Figure 1 will then appear. From the manager settings tree in the left panel of Figure 1, select the ITSM/Collaboration Integration node. The third-party ITSM/Collaboration tools that eG Enterprise can integrate with will be listed in the right panel.

   

   Figure 1 : Viewing the ITSM/Collaboration tool options

4. Now, click on the JIRAoption in the right panel (see Figure 1). A JIRA section will now appear in the right panel (see Figure 2).

   

   Figure 2 : Configuring integration with JIRA

5. To enable integration with JIRA, first slide the JIRA slider in Figure 2 to the right.

6. Then, specify the following in Figure 2:

   • URL: The web services URL using which the eG manager should connect to JIRA.
   • User name and Password: Specify the credentials of a user who has the rights to access JIRA.
   • Project key: A JIRA project is a collection of issues, and is defined according to an organisation's requirements. Each project is associated with a unique Project key. Specify the project key of the project with which the eG alerts are to be associated.
   • Issue type: Indicate how you want to classify the eG alerts – as Incidents, Problems, or Service Requests. The default selection here is Incident.

   • Title format: Specify the format in which the title of the trouble ticket is to be displayed in Slack. The default format is as follows:

     $prior - $ctype / $cname - $pdesc

     The ‘dollared’ ($) text in the format above is a 'key', the value of which varies at run time, depending upon the information contained in the eG alarms. For example, in the default format above, $prior is a key that represents the alarms priority, and changes according to the priority of the actual alarm that is sent by the eG manager to JIRA. You are advised against changing any of the variable names.

     The other keys that are part of the default format are discussed in the table below:

     $cname	Will display the name of the problem component
     $ctype	Will display the component type to which the problem component belongs
     $pdesc	Will display a brief problem description

   • Description format: Specify the format in which the problem description should be displayed in the trouble tickets generated by JIRA. The default problem description will be as follows:

     *Priority:* $prior *Component* *Type:* $ctype *Component:* $cname *Layer:* $layer *Problem* *Time:* $starttime *Problem* *Description:* $pdesc

     As you can see, the problem description format comprises of two types of text strings – one that is enclosed within asterisks and one that follows a $ symbol. The text that is enclosed within asterisks represents a label that qualifies the value that follows. The ‘dollared’ ($) text on the other hand, is a key, the value of which varies at run time, depending upon the information contained in the eG alarms. The asterisk (*) itself represents an empty space. For example, in the default format above, Priority is a label that indicates that the information that follows it is the priority of the alarm. The key $prior that succeeds the label represents the alarm priority, and changes according to the priority of the actual alarm that is sent by the eG manager to JIRA. While you can change the labels, you are advised against changing any of the keys.

     The other keys that are part of the default format are discussed in the table below:

     $cname	Will display the name of the problem component
     $ctype	Will display the component type to which the problem component belongs
     $layer	Will display the layer affected by the problem
     $pdesc	Will display a brief problem description
     $starttime	Will display the start time of the problem

     You can override this default format by removing one/more keys or by changing the positions of a few keys. For instance, you may not want the problem component type to be part of the problem description. In this case therefore, your Description format will be.

     *Priority:* $prior *Component:* $cname *Layer:* $layer *Problem* *Time:* $starttime *Problem* *Description:* $pdesc

   • Custom payload: Use custom payload to customize the alert information you send to JIRA, so that it includes additional static information.

     Typically, the details of an eG alert are sent as a JSON file to the configured URL. Every piece of information contained within an eG alert - eg., priority, component name, component type etc. - is represented in the JSON file as a $key:$value pair, where 'key' denotes the alert field, and 'value' denotes the actual value of that field at run time. The 'key' is configured based on what the JIRA REST API supports. For instance, if the REST API represents alarm priorities using the key 'prior', then the same key will be used in the JSON file for denoting alarm priorities. Accordingly, the entry for alarm priority in the JSON file will be $prior:$value. The $value will be Critical, Major, Minor, or Normal, depending upon the actual priority of the alarm being sent.

     If you want eG incidents routed to JIRA to include additional information, then you can define a Custom Payload for that information as a $key:$value pair. For example, say, you want incidents to indicate the FQDN of the eG manager that generated the incidents. Say that the FQDN of your eG manager is egmanager.innovations.com. To include this information in JIRA incidents, do the following:

     • First, check whether the JIRA REST API supports a 'key' that can be used for capturing the 'source' of alerts/incidents. If no such key exists, then you cannot proceed with the Custom Payload configuration. On the other hand, if such a key is available, then proceed to replace the $key in your Custom Payload specification, with that key value. For the purpose of our example, let us assume that the REST API supports the key named 'source'. In this case therefore, substitute '$key' with 'source'.
     • Then, proceed to explicitly specify the FQDN of your eG manager in the place of $value. This is because, you can use the Custom Payload configuration to add only 'static' information - i.e., information that you explicitly configure, and hence will never change. In the case of our example therefore, the $value will be egmanager.innovations.com.

     • The complete Custom Payload specification will now be: source:egmanager.innovations.com

7. Finally, click the Update button in .