OSLC API and POX Profile simplifies CLM traceability

Further to OSLC + POXProfile post, RPE 2.1 with CLM 6.0.2 simplifies the data source configuration; especially while configuring dynamic data source for traceability reports.

Use OSLC / Permanent link for configuring the data source URL without having to modify the URL manually or through JavaScript. This simplifies the data source configuration to a great extent as the Permanent / OSLC links are available to the user from the product UI.

Watch video, created by Dragos, on requirement (DNG) to use case design (DM) traceability document generation using Permanent / OSLC links from DNG and DM without having to go through building Rest URL.

See jazz wiki for Plain Old XML (POX) profile.

Take a look at RPE documentation on creating traceability document from CLM 6.0.2 and RPE 2.1 using POX Profile.

Data source configuration

Use the permanent link from DM, DNG, QM along with POX Profile header without having to convert the link to Reportable Rest API link.


Dynamic data source configuration

URL manipulation or additional server request are no longer required for some of the scenarios as mentioned in OSLC + POXProfile.


Adding schema

There is no need to go through REST schema discover for scenarios like DM usecase design and other artifacts. Use the permanent link as it is along with POX header.




Author: Kumaraswamy M

Kumar is an architect for Rational Publishing Engine. He has been with the product for more than 4 years and has been involved in many releases of RPE. His expertise are in Web application development and API design. He loves going on a long ride on bike and conquering peaks during weekend treks.

5 thoughts on “OSLC API and POX Profile simplifies CLM traceability”

  1. I’m looking for technical support services that could function as reach back capability for a current delivery order we have with the Government: Subject Matter Expertise reach back support is require in two (2) primary areas. 1. Model Based Systems Engineering methodology support which includes support configuring Rhapsody and Design Manager with the installation and configuration of Rational Engineering Lifecycle Manager (RELM). 2. Rational Publishing Engine (RPE) expertise to satisfy the requirements of the SOW. In particular, with regard to creation RPE templates that traverse interface diagrams to collect information and generate an ICD. We’re looking for approximately 192 hours of support in the near future. Is this something you could provide or recommend another source?

  2. I am in RDNG (Jazz 6.0.2) and using the validated by link to cross into the QM data base for Test Cases and Test Scripts. I used to use the OSLC method with java script coding which no longer works with the server upgrade. I am trying to implement this new method using POX.
    To link to Test Cases, I have inserted a data source configuration for my data source Test Case using the dataSource/artifact/traceability/links/ValidatedBy/relation as the URI. For the accept header field I am using application/rdf+xml (per the https://jazz.net/wiki/bin/view/LinkedData/POXProfile instructions for QM data sources) with the extra link field: Link: ; rel=”profile” as per the video. The RPE console says it is configuring the data source then gives me an error-
    CRRPE1064I Error in engine
    Pox profile header is missing in the response. Please check if the requested resource is valid to have pox profile header.

    1. Hi Erica,

      Apologies for replying late. How does your template look like? DNG to QM_RESTv2 to QM_REST?
      What could be happening is the RESTv2 and REST is also inheriting poxprofile header from dng_artifact data source. So, you should set poxprofile of DSC elements QM_RESTv2 and QM_REST to a dummy value (may be just type dummy) for extra headers. If you don’t find extra header option on the old template DSC element, create a new DSC element and delete the old one. I’m interested to know how this goes.

      1. The template initially starts with a RTC Work Items Rest Data Source for a work item type == Feature. I iterate through the Feature to the workitem/workitem/children/reportableUrl to get to the associated child link to the work item type==story. I connect to a DSC element for an RTC Work Item to represent the Story. I iterate through the story to the associated requirements- workitem/workitem/auditableLinks/targetRef. I use a DSC element to connect to the associated requirements- DNG Text Generic XML. From those requirements, I link to the validated by link to the Test Case. I use the dataSource/artifact/traceability/links/ValidatedBy/relation as the URI for the Test Case Rest 1 data source. For Accept Header, I have used application/xml and application/rdf+xml on different generation runs, and for Extra Headers, I have left it blank, Link: , Link: ; rel=”profile”; text, dummy- all options either generate an error with abort of RPE Engine or if it does state it is configuring the data source Test Case, I just obtain a blank. I have also tried using a REST 2 data source for test case.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s