OSLC Connect for Jira Installation Guide

The following guide is a companion to the installation help guide on installing and validating OSLC Connect for Jira.

For detailed and latest help you can see it online → Online Install Help

For the latest application please see the download portal → Download Portal

For executing the Installation we need support from different roles. We describe these as:

• Jira Admin - Able to access and update Plugins and Plugin Features

• Jira Project Admin - Able to access Project Settings in Jira Projects

• OSLC Admin - Able to access Application Configuration Settings (any of the following Jazz Admin, DOORS Admin, Polarion Admin)

• OSLC Project Admin - Able to access Project Settings in OSLC Projects (ELM, DOORS, Polarion)

• User - A user that has been given Jira and ELM user ids.

We will note these roles for each step.

Step 1: Validate your Environment

Roles: Jira and OSLC Admins

We are connecting a collection of web applications so we need to make sure we have a valid environment to configure our tools.

Check your product versions

Check with the latest system requirements on the versions of the products you are connecting (Supported Product Versions). Document these, as the help desk may want to validate these at a later date.

Check Application Servers

Our web-browsers will work to make sure we have a secure environment. This means we must have https and valid certificates and trusts on all servers. The best method is to have valid certificates and a common certificate authority. If it is not the case, you must do some manual trusts and updates to key stores.

It is also valuable that your applications are using DNS hostnames. Make sure you aren’t accessing the applications via ‘localhost’.

Check connectivity

We need to validate connectivity between your client and each of the servers. This means your client browser can talk to each server and each server can talk to each other. When we are checking connectivity we are performing this through the network topologies (load balancers, reverse proxies, firewalls, etc.) so our tests are end to end. The most effective check is performing a curl command (or similar) from the server command line to validate the connectivity to get a webpage to verify connectivity. If you are not able to establish connectivity this is a sign there is a firewall or other network obstacle to be addressed. Based on the error, our helpdesk can guide you through the root cause.

Step 2: Install the plugin & license key

Roles: Jira Admin

As the Jira administrator, install the oslc connect jar file as an extension. This is available from the zip file in the download portal.

Once installed, it will be available for use and can now be enabled through a license key based on the base URL.

See the download portal for the details → Download Portal Knowledge Base.

Step 3: Configuring your Application Friends

Roles: Jira and OSLC Admins

The first step is identifying the products you want to collaborate with. This will detail which application you friend with and where you will approve the friend (in the target consumer lists).

You will need the Jira Admin to create the Friend relationship to the other Application, and then the OSLC Admin to approve the relationship as a consumer. And the inverse will take place when creating Friends to Jira.

Typical Friends created from Jira with their rootservice location, and approval location.

Note, only connect your applications you intend to collaborate with.

In the inverse direction, you will create the Friends from each Application you intend to use. These should be the inverse of the above selection. From each application you desire to create links, create a friend relationship to {Jira_HOST}/rest/oslc/1.0/rootservices. You can approve the keys in plugin configuration consumer section usually found in {Jira_HOST}/plugins/servlet/oslc/consumers.

Note: JTS should not be friended to directly, or should it friend Jira.

Step 4: (Optional) Configure Global Configuration

Roles: Jira and OSLC Admins

If you are using Global Configuration you must configure two elements.

Friend Jira with the GC Application. This is a friending to {GC_HOST}/gc/rootservices that must be approved in the JTS Application. This allows Jira to create relationships to GCs.

Friend GC to Jira. This a friending from GC to Jira. This enables the usage of the Jira as a Deliverable provider to GC in 7.0.2+ of ELM. Additionally, the friend information will enable the usage of GC selection dialogs inside of Jira.

LDX must add Jira as a data source to allow for link discovery.

a) Add a consumer in Jira Consumers and assign a Functional User to the tracked resource set.

b) Add a new data source in LDX for the CM artifacts. Use the rootservices of Jira and select oslc/1.0/cm/trs resource.

Step 5: Project Configurations

Roles: Jira and OSLC Project Admins

Whenever you want to create links between a Jira project and another OSLC project, these are project-level configurations.

In your Jira project configuration, use project associations to select an OSLC Application, Association Type, and a Project/Container. This will allow you to create links from Jira to the applications. Iterate for all project and association type configurations.

In your OSLC App projects, use their configuration menus to add project relationships to Jira to allow the creation of links to Jira from that application.

Hints on Link Relationships are found in our help → Project Associations to Link Types

---

First Time Suggestion

If it is your first time creating these relationships we suggest keeping it simple to start. For example, create a simple bidirectional relationship

• Jira → DOORS Next. Create a Project Association for “Provides - Implementation Requests”

• DOORS Next → Jira. Create a Project Association for “Uses - Implementation Requests”

With this, you can create a Requirement to Story Relationships quickly and easily.

---

(Optional) Configure for GC

For teams that are using projects that are GC Enabled, we need to relate the Jira concepts to the Configurations that are used in the enterprise. This is done in two steps.

a) Link/Version Field mapping is indicating what field should be used to contextualize a link configuration. It is most typical to just leave the defaults. It can be explored further for your team configuration.

b) Global Configuration mapping is a selection of relating Jira Releases to the Global Configuration that represents the assets of that release (working or static). This should be a Global GC (and not personal GCs), the right practice and granularity is an organizational decision.

Step 6: (Optional) Scheme Configurations

Roles: Jira Admin

Scheme configurations provide overall settings across all projects that are using a specific scheme/process. These are available to encourage common practices for your teams and are configurable in the Plugin Configurations.

a) Issue Type mapping. This configures the default types when a user in a foreign tool attempts to link to an artifact. For example, this allows a user to set the default defect type from your Test Execution tool (ETM) when you identify and problem, or what your default requirements implementation type is (Story/Epic/Other).

b) Approvals. This configures when a Jira ticket should be considered approved. This can be by state, resolution, or custom JQL.

Step 7: Create Your First Link

Roles: User

Create a link from Jira to one of your other repositories. This shows the linkage between the apps and allows you to use reporting services.

Step 8: (Optional, Recommended) Configure for Report Builder

Roles: Jazz Admin

Note: This can be done prior to Step 7, however to better prove reporting and not having to wait to do the data model refresh mentioned below, we do suggest creating a link first.

If you are using Report Builder you will need to configure for using the Jira TRS.

LQE must add datasource for both process and cm. The process resources are the project information, the cm resources are the Jira tickets.

a) Add a consumer in Jira Consumers and assign a Functional User to the tracked resource set. (Note you can use the same consumer you used for LDX)

b) Add a new data source in LQE for the CM artifacts. Use the rootservices of Jira and select oslc/1.0/cm/trs resource.

c) Add a new data source in LQE for the CM artifacts. Use the rootservices of Jira and select oslc/1.0/process/trs resource.

d) In the permissions, make sure to update the access to the process resources so users can report on Jira artifacts. This can be an “Everyone” configuration, Group configuration, or specific users. You can set the access model.

ReportBuilder must update the data sources to have access to the Jira Data Model. This is typically a nightly task that is done, but it can be forced on a data source with a “refresh”.

Create a Report with Jira Resources.