Test Jira Connectivity on OS Level

Prepare your Infrastructure and Connections for Jira

If communication between different SAP ALM tools, including Jira, is to be implemented based on Conigma Connect, it is necessary to check the requirements on network level in advance.
Often network components like SAP CPI / SAP Integration Suite, firewalls, reverse proxies, MID servers, etc. or challenges like missing certificates require different actions for a communication between JIra and the Conigma Connect middleware server on OS level (called middleware OS in the following text).

This blog post shows how to test the communication between Jira SaaS and a Linux or Windows server on OS level to ensure an integration of e.g. Jira SaaS and Conigma™ CCM or SAP Solution Manager ChaRM / FocusedBuild for SAP Solution Manager. The corresponding procedure also analogously applies to the Jira Data Center Edition.
Communication is tested in both directions for each platform and operating system. These tests help to identify communication issues and provide the chance to resolve such issues during project setup. The proper working communication is tested at the operating system level and is independent of Conigma Connect.

There are two types of network connections to test:

• From Jira to the Conigma Connect Server on OS level (called inbound connection below).

• From the Conigma Connect Server on OS level to Jira (below called Outbound-Connection).

To test the correctly set up network connections for inbound connections, our customers typically use a mock server that can receive and log API calls from Jira (see picture below). In this post, the tests are described using the mock server Mockoon in its portable version. It is available for Linux and Windows. Similar procedures are also valid for any other mock server. On Jira side the built-in automation trigger is mechanism used.

Outbound connections from the middleware server to Jira normally are tested using OS-related functions, e.g. Window Powershell or Linux curl (see also picture below).

General notice: The described approach also applies to Docker-based infrastructures.

Inbound Connection Test for the Middelware OS from Jira

This chapter describes the test of the inbound connection from Jira to the middleware operating system, on which the Conigma Connect Server will be installed.

On the Middleware Server

Perform the start and setup of Mockoon like described in the corresponding section of blog post Test ServiceNow Connectivity on OS Level.

In Jira

Go to the automation rules settings:

On the automation rule page click "Create rule".

NOTE: In the current example we will not finally save this rule, so no persistent change will be made.

Create a manual trigger:

Add a new action:

Select a web request:

Enter the POST data.
The URL will be <your Mockoon URL with port>/content/xyz.

For the endpoint in the image above you have to enter either
<your_mockoon_server_name>:<port>/content/xyz
or
<your_mockoon_server_ip>:<port>/content/xyz.

You also need to specify an empty request body:

Now validate the call's result.
The expected one is "200 OK":

In case of an error, the HTTP Status field contains a value <> 200. Now you can cancel the creation of the automation.

Outbound Connection Test from the Middleware OS to Jira

Build your company's API base URL:
https://<mycompany>.atlassian.net/rest/api/2/

Now test if the Jira API can be reached. Below two different procedures - one for Linux and another one for Windows - are described.

In Linux

curl -vi <URL> (e.g. curl -vi https://<mycompany>.atlassian.net/rest/api/2/)

Expected result curl:

NOTE: The status code "405 Method not allowed" is expected as correct result here, since no real sub-API was addressed.

In Windows

Use the following PowerShell Script to verify the connection to Jira:

$URI = "https://<mycompany>.atlassian.net/rest/api/2/";
Clear-Variable Response;
try {
    Invoke-WebRequest -Verbose -Method GET -Uri $URI
}
    catch {
        $Response = $_.Exception.Response ;
        $ErrHead = $Response ;
    };
$ErrHead;

The required response for a successful test is as follows:

NOTE: The status code "405 Method not allowed" is expected as correct result here, since no real sub-API was addressed.

Summary

The procedure described above can be used for tests regarding daily operations (e.g. expired server certificate for HTTPS connections) as well as for testing the infrastructure before installing Conigma Connect.