Polarion OSLC Services for your Configuration
Polarion provides the ability to leverage OSLC services for your specific configurations. However, before you can leverage those features you must complete the mapping of artifacts to the OSLC Services for your project and server.
Seeing artifacts from other OSLC Tools
To be able to see artifacts from other tools, your Polarion project must identify the types of artifacts that it is making available and map to the OSLC types. Effectively what needs to be done is to map your Polarion types to the OSLC Types that are desired.
You can find the configuration in your Project in the Linked Data Mapping.
In the XML document the focus is on relating the Polarion types to the OSLC types.
The default mappings look something similiar to the following:
While a user has flexibility to refine their definition, at a minimum polarionType that you want to access from Jira should be mapped to the respective oslcType. For example if you have a Polarion type as follows defined.
In the <oslc-mappings> and <type-mappings> structure you would add the following link
<type-mapping oslcType="oslc_rm:Requirement" polarionType="myRequirementType"/>It is also possible that you can leverage the oslcUsage to better refine the type description. However, the basic need is to relate your polarionTypes to the interfaces that you want to make an artifact visible to Jira. These can be oslc_rm:Requirement, oslc_rm:RequirementCollection, or oslc_cm:ChangeRequest.
These can be defined logically as
Requirement - An atomic identified asset that represents any requirement artifact.
Requirement Collection - An atomic identified asset that contains (by ownership or reference) other artifacts. This is often a document of some sort.
Change Request - An atomic identified workflow artifact that has a history, but is not versioned.
We recommend that users refrain from using Requirement Collections, as the Requirement object has the most flexibility and value.
OSLC linking from Polarion
OSLC linking from Polarion is dictated by both the OSLC Mapping as well as your type mapping.
To use OSLC Links, the Linked Data Mapping must be updated to relate a specific Polarion link role to an OSLC link type. Once this is done, the option will be avialable to create external links to OSLC resources. The default mappings look something like the following:
The intention here is to identify the Polarion link type (linkRole) to and OSLC Link type (oslcLinkProperty). The Polarion link role should use the ids defined for the link types in the following definition:
Note: this will also dictate the Polarion objects from which a link type would be available to create links.
To bind a link role to an OSLC relation, you must add a link-role-mapping such as:
<link-role-mapping linkRole="myPolarionLink" oslcLinkProperty="oslc_rm:trackedBy"/>This link mapping would identify that the myPolarionLink when coming from a Polarion Artifact that is mapped as an oslc_rm:Requirement can be related to an oslc_cm:ChangeRequest via an OSLC Link dialog.
The oslcLinkProperty are standard oslc link types and will be specified in the Link Data Semantics file. It is a repository wide configuration and is typically not touched.
The typical link types and artifact relationships are as follows. Additional types can be found in the semantics file, but these address 99% of the relationships performed.
Common Name | From Artifact Type | To Artifact Type | OSLC Link | OSLC Link Inverse |
|---|---|---|---|---|
Related Change Request | oslc_cm:ChangeRequest | oslc_cm:ChangeRequest | oslc_cm:relatedChangeRequest | oslc_cm:relatedChangeRequest |
Affects Plan Item | oslc_cm:ChangeRequest | oslc_cm:ChangeRequest | oslc_cm:affectsPlanItem | oslc_cm:affectedByDefect |
Implements Requirement | oslc_cm:ChangeRequest | oslc_rm:Requirement | oslc_cm:implementsRequirement | oslc_rm:implementedBy |
Affects Requirement | oslc_cm:ChangeRequest | oslc_rm:Requirement | oslc_cm:affectsRequirement | oslc_rm:affectedBy |
Tracks Requirement | oslc_cm:ChangeRequest | oslc_rm:Requirement | oslc_cm:tracksRequirement | oslc_rm:trackedBy |
It is noted that there must be consistency in the workitem link roles and the oslc link property types so mappings are consistent (e.g. Change Object to Requirements Object). There may be some adjustments that evolve as you make sure the configuration is consistent.
It is also recommended that each oslc link type (oslcLinkProperty) is used once to a link role to ease the mapping from an external tool into Polarion. When there is overlap, we can see that Polarion may use only one of the link role mappings.
You can confirm the update of the configuration of the link mappings when the OSLC link option is available on a link type as you would observe as follows.
The third icon shows the availability to create an OSLC link for a link role. It is important to also review the directionality of the role to make sure the role rules are followed and that the association naming is as desired. It will leverage the OSLC semantics for directionality for the role.
It should also be noted that even if custom link types are used in Polarion, the external tools will be using the OSLC link names and labels, so you will see the oslc names as the links back to Polarion. For example:
In Polarion (uses custom link labels):
In Jira (uses standard OSLC link labels):
