Tag: clm

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. Continue reading “OSLC API and POX Profile simplifies CLM traceability”

Jazz Reporting Architecture

This is how JRS, Insight and RPE fit together to provide reporting capabilities for CLM and more. The JRS and RPE combination offers excellent design usability and runtime performance for any report that involves traceability/data aggregation.

jazz Reporting - JRS + RPE
(click to enlarge)

Rational solution for Collaborative Lifecycle Management 4.0.1 Reporting Workshop

This is a workshop from 2013 but it’s still correct and provides valuable information for how CLM REST APIs and especially the data linking works. The exercises are well structured and show you the actions sequence used to build most CLM templates.

https://jazz.net/library/article/1269

Configuring RPE template to generate documents from RTC

This is a guest post by my colleague Subramanya Pilar from the RPE FVT team.

Similar articles are available for RQM  at https://jazz.net/library/article/1137,  DM https://rpeactual.com/2015/10/08/easy-selection-of-the-report-starting-point-a-rhapsody-example/ and QM again https://rpeactual.com/2014/08/18/rpe-configuration-layer-or-docgen-configuration-made-simple/

The example template associated with this article, rtcWorkitemHistoryWithMetadata.dta,  is available in the RPE Community Template Library.

Rational Publishing Engine provides functionality to configure data source metadata so that when RPE report is consumed by point product, it can understand how to configure the data sources.  This capability enables report designers to provide users with a list of options to choose from, instead of manually entering the URI. Below are the steps to configure a template’s metadata so that RPE template can be executed from within Rational Team Concert.

Template Configuration Metadata

Open the template in RPE Studio. In Outline view, right click on the data source that needs to be configured and select “Edit Configuration Metadata”. Usually, this data source is the parent data source which is not dynamically configured and the name does not start with “_”.

There are 4 fields in “Edit Configuration Metadata…” window.

  • “Request URL” – the URL that RPE will request the data to show to the user. There are pre-defined variables that can be used in this field that RTC will recognize. You cannot use these values if configuring the report from standalone RPE.
    • $public: Public URL of the server
    • $projectAreaUUID: RTC project area.
  • “Type” restricts the format of user input.
  • “Identifier”- XPath expression that selects the data RPE/RTC will use to configure the report. The values of this attribute must be Reportable REST URLs .
  • “Display” – XPath expression that selects the data RPE/RTC will show the user.
    NOTE: you can drag and drop attribute from Data Source View into the identifier and display fields.

How does RPE uses these values

If ‘Request URL’ isn’t set, then user has to manually input the data source value when executing the report. If ‘Request URL’ is set, and ‘Identifier’ field is not set, the resolved value of ‘Request URL’ will be used for report generation.

If both ‘Request URL’ and ‘Identifier’ fields are set, a GET request to the resolved Request URL is made, then ‘Identifier’ and ‘Display’ XPath expressions are evaluated on the server response and a list is shown to user to choose from. The values matching ‘Display’ expression are shown in the list and the corresponding value of ‘Identifier’ is set as data source URI.

rtc_report_metadata

In this example the user is provided with a list showing the id and summary for all the workItems . Once user selects a workItem the reportable URL of the chosen WorkItem is used to configure the  document generation.

NOTE: for RTC the @href attribute cannot be used in  Identifier field because the URL it holds is not a Reportable REST URL.

Embed attachments as OLEs in the RPE Word output

This is a guest post by my colleague Subramanya Pilar from the RPE FVT team.

Hyperlinks are a simple and convenient way to attach additional data to a document. There are however scenarios where embedding the content as OLE objects is more useful:

  • the document is self contained, you can transfer the documents with embedded objects to other computers or mail them without breaking any link.
  • you can edit the embedded objects without changing the content of the source.
  • embedded objects can be edited without having to work in a separate window.

Rational Publishing Engine supports creating such documents. The attachment can be of any format supported by Microsoft Word for embedding .xls, .pdf, .doc, .docx are examples of such documents.

Continue reading “Embed attachments as OLEs in the RPE Word output”

Adding Quality Management data to the traceability mix

Continuing the Assemble traceability documents from reusable building blocks I want now to add QM data in the mix. I will be using the same DM model as a starting point and I will follow links to QM Test Cases.

dm_qm_step1
As you read this I  recommend also going through Geoff Rosenthal’s the excellent Rational solution for Collaborative Lifecycle Management Traceability Templates with Rational Publishing Engine tutorial.

The artefacts for this tutorial are available on the Unclassified & Cross Domain Templates section of the RPE Wiki Community at #15  DM to CLM Traceability.

Getting the DM link information is already covered in  Assemble traceability documents from reusable building blocks so I will skip it here. This article starts from the point where you have your DM and DM link data in place in your template.

How QM linking works

But before I go there I want to explain how QM linking works and what are the various schemas you will encounter in the process.

QM, just like all the other CLM products has an OSLC API that is used for linking. A QM Test Case will be referenced from another product using a URL that looks like this:

https://giediprime:9443/qm/oslc_qm/contexts/_cmIwsHceEeW6EPQMMno5Bw/resources/com.ibm.rqm.planning.VersionedTestCase/_sF1Y4XceEeW6EPQMMno5Bw

For the example I am presenting you can get these URLs from the link page of the DM artifact.  And if you access these URLs from a tool like Poster and specify “application/xml” for the “accept” header you can see the data available. One thing you will notice is that even though the data is not in the form you are used to when reporting on QM with RPE which is the QM’s Reportable REST API.

dm_qm_step6

Unlike DNG there is no way to convert from the RQM OSLC v2 URL to the Reportable REST URL but for QM the OSLC representation of the QM artifact contains the link to the RQM Reportable REST URL.

So to get from the OSLC URL to the Reportable REST URL you firsy need to access the OSLC resource, read the Reportable REST URL and then accesses the data there.

How QM linking works – TL;DR version

When you want to access linked QM data you need to:

  1. access the OSLC representation of the artifact
    • you need to use RPE’s Reportate REST v2 schema discovery to find the schema form QM’s OSLC representation. The starting point for the schema discovery process is https://server:port/qm/oslc_qm/catalog
  2. read the URL to the Reportable REST representation of the QM artefact
  3. access the Reportable representation of the artefact
  4. Use the data as needed

Suggested reading:

  1. RQM OSLC v2 REST API – for linking data
  2. RQM Reportable REST API – for document generation

Get linked QM Data from DM

  1. Insert the QM_TC_Snippet.dta in the indicated position
  2. Edit the condition on the QM Container such that you are only processing QM Data. I have used the “link type” property  to only accept “Validated By” links
    dm_qm_step2
  3. Connect the QM snippet to your template by specifying
    1. A data source to have the QM_OSLC_TC inherit from
      dm_qm_step3
    2. The data property that holds the OSLC QM URL
      dm_qm_step4
  4. Make a test run to verify all the pieces fit together. Just like with the RTC example you only need to specify the entry point and credentials for accessing the DM UML project.
    dm_qm_step5

NOTE: You will need to replace the QM schema from my snippet with your particular QM schema so that you can use the custom attributes defined in your particular QM instance.

Conclusion

You now have 2 RPE snippets for accessing RTC and QM linked data that you can reuse in your traceability documents. I recommend evaluating your existing templates to identify other sections in your templates that you use on a regular basis and transform them in reusable snippets.

Assemble traceability documents from reusable building blocks

When building a template you can take advantage of the reuse capabilities that RPE Template and Document Studio provide.  You can use this for any documents and traceability documents are a great candidates since they usually involve the same steps over and over again:

  1. Read the data from Product A and print the details you need
  2. In the data of Product A find the links to data in Product B
  3. Read the data from Product B and render it
  4. …

The above is the outline of any 2 source traceability report and steps 2 and 3 are almost identical for all reports so they can be packaged as blocks to be reused as needed.

To show this I have created a document with DM and RTC data. The artifacts I use in my example are available on the Unclassified & Cross Domain Templates section of the RPE Wiki Community at #15  DM to CLM Traceability.

Continue reading “Assemble traceability documents from reusable building blocks”