Using OSLC Tables in Polarion Forms

Starting with Polarion version 21r1, a new feature enables users to provide a data table for remote OSLC resources. This provides the benefits of having immediate visibility to remote data without the penalty of copied data.

By using this feature, your Jira attributes can be visible in Polarion forms. For example, here are the related ECRs (Engineering Change Requests) from Jira on a Polarion Requirement.

This new widget provides significant flexibility in how data is presented from your Jira instance. To prepare to use this feature, look to identify the following behaviors you want to see.

• On what Polarion Forms do you want to show tables of OSLC resources

• On those Polarion Forms, what OSLC Resources do you want to show

• On each of these forms, what remote attributes should be present

Our guide will demonstrate how to build and leverage your tables in Polarion from Jira.

Adding the widget to your form(s)

The first step is to add the widget to the desirable forms.

In the Administration view, navigate to the Form Configuration.

Edit the Form Layout

As we are editing a configuration, we recommend you create a backup of the configuration before editing.

For whichever type(s) you want to add the OSLC Widget, you need to add a single line of XML.

For example:

<extension id="OSLCExtension" label="ECRs" oslcType="oslc_cm:ChangeRequest"/>

And in context, it will look like this:

The configuration is instead simply using three fields

• id → always “OSLCExtension”

• label → any label you desire to use. In this case, I used ECRs for Engineering Change Requests

• oslcType → For Jira artifacts, this will be “oslc_cm:ChangeRequest”. In practice, this can be other OSLC resource types.

Repeat this configuration for each of the Polarion types that you want to show OSLC Resources in a table.

Configure the Contents of your Tables

Polarion allows you to pick and choose which attributes to include in your tables. This is done in the Link Data Appearance.

Again, since these are simple XML configuration files we would recommend that you backup any existing configurations.

In the Siemens Polarion help (https://almdemo.polarion.com/polarion/help/topic/com.polarion.xray.doc.user/guide/xid1927032.html?cp=0_3_15_2_5 ), we see an example of what should be expected in this configuration:

<remote-attributes-configuration polarionTypes="changerequest,defect" remoteOslcType="oslc_cm:ChangeRequest">
   <attribute label="Status" oslc="oslc_cm:status"/>
   <attribute label="Change Owner" oslc="dcterms:creator"/>
</remote-attributes-configuration>

We can note that we can create a configuration for several Polarion types at once. For each configuration, we can declare three fields.

• oslc → This is the attribute identifier used in the OSLC rdf (more details below)

• label → This is the visual label that you will see on your table

• visible (optional) → This is a true/false designation on whether you want to see an attribute appear in the table. The default is true, and in most instances, this is unnecessary except during some testing.

Configuring your Jira Content

When configuring your Jira Content, we do recommend some additional steps and a basic configuration to begin.

<?xml version="1.0" encoding="UTF-8"?>
<remote-attributes-configurations>
 <remote-attributes-configuration remoteOslcType="oslc_cm:ChangeRequest">
   <attribute label="Jira Status" oslc="oslc_cm:status" visible="true"/>
   <attribute label="Jira Id" oslc="dcterms:identifier"/>
  </remote-attributes-configuration>
</remote-attributes-configurations>

This initial configuration will address all Change Requests and Polarion types and serve as a simple check on the behavior.

It should look similar to the following:

You will note that the Linked Data Friend, Role, and Title are always in the table by default. (The Friend name is from the Server Configuration, so you should discuss with the Admin the best name for the Server Friend)

You should execute this before further configuration. Once this is working you can continue to customize as defined below.

Custom Jira Configurations

Using OSLC Connect for Jira means some extended configurations will be available. This requires the ability to know what attributes are available on your Jira artifacts.

For example, the following configuration adds the priority field to your table.

<?xml version="1.0" encoding="UTF-8"?>
<remote-attributes-configurations xmlns:jira="http://atlassian.com/ns/cm#">
 <remote-attributes-configuration remoteOslcType="oslc_cm:ChangeRequest">
   <attribute label="Jira Id" oslc="dcterms:identifier"/>
   <attribute label="Jira Status" oslc="oslc_cm:status" visible="true"/>
   <attribute label="Priority" oslc="jira:priority" visible="true"/>
 </remote-attributes-configuration>
</remote-attributes-configurations>

The results look like the following:

Following are the standard attribute fields that are available to configure from Jira.

For the Jira specific attributes (jira:xxx) ensure that the Jira xmlns is present in your XML as shown above.

Polarion does not format these values, so some (such as user ids) may still be encoded in their URL or other storage formats. However, most of these standard fields are usable in the table. We recommend you review the results before deployment to your teams.

Extended Jira Attributes

If you are using extended Jira attributes and want them to be present in your tables, you must locate the identifier for these attributes and confirm their reporting.

Please review [update] Accessing Custom Jira Fields via OSLC for further details.