No PhD required

CLM 6.0.2 comes with the server side implementation for the Plain Old XML profile or POXProfile. You can test this feature using one of the recent milestone builds.

Based on the name you might think “great, one more reporting “feature” that requires a PhD just to get a PDF of my data” but the Plain Old XML Profile is designed to remove much of the complexity associated with creating traceability documents in RPE.

In essence the POX profile allows a client (RPE, browser addon, curl etc) to request and receive Reportable REST XML from OSLC URLs. The feature is designed for document generation but you can use it whenever you need to access the XML representation of your data.

poxprofile

The image above shows using the POX Profile to get Reportable REST XML from DNG using the FireFox Poster addon. The is URL obtained from DNG’s “Share link” dialog.

For document generation this essentially means that URL manipulation or additional server requests are no longer required for following links. See below for examples. This in turn translates into simpler templates that produce documents faster.

The POX profile complements well using JRS as it simplifies fetching additional data attributes which are not available to JRS such as images and rich text. For such properties you need to request the data from the point product itself starting from the OSLC URLs returned by JRS.

Below are some examples of the document generation flows with and without the POXProfile.  Please note that the client side implementation is not available in the RPE GA but we are working on it.

Continue reading “No PhD required”

Advertisements

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.