Blogs about Jazz

Blogs > Jazz Team Blog >

Reporting on Linked Lifecycle Data with IBM Engineering Lifecycle Optimization – Publishing | Part Four – Reporting from Rhapsody Model Manager

In the previous article, we covered how to report on links from requirements to model elements in Rhapsody Model Manager as well as test cases and work items. In this article, we’ll cover how to create a template that reports on the model and gets the links to other artifacts. Once you have the links, the ‘how to report on the other end’ was covered in the last article for everything except requirements – so we’ll fill that gap here too. Note that there is another reporting endpoint specifically for model traceability statistics, and we’ll cover that in a future article.

Reporting on the Rhapsody Model

Adding an RMM Schema

Rhapsody Model Manager is perhaps the simplest of all of the Jazz tools to report on (it is focussed on reporting on traceability rather than reporting in-depth on the model). It has a single schema, and everything is an “Architecture Element”. In the previous article we covered how to get the schema, but we’ll run through it again here for completeness. First, open any model element in the RMM web client. The breadcrumb at the top has ‘chain’ symbols for each artifact. Clicking any one of them will give you that element’s URI. Since there is a single schema – it doesn’t matter which one you click. What does matter is you remove the context information – which can be done easily using a checkbox:

In Document Studio, Add a new REST data source. Enter the URI of the model element you copied above and append it with the text ?metadata=schema (which retrieves the schema for the resource rather than the data itself). In the Extra Headers field, select the POX header:

We should now have a data source we can use to report on model elements (ArchitectureElements)

Reporting on a Single Model Element

Since the focus for this article is on reporting across traceability links, we’ll create our report to report on a single model element, one that we know has links to requirements, tests, and work items (of course in a real template we would create one a little more complete, perhaps iterating over the package structure and reporting on all the diagrams inside those packages). The template is very easy since everything is an ArchitectureElement:

Selecting a Model Element on Which to Report

Now we can switch to the Launch perspective and configure the RMM data source using the OSLC Resource Selection picker. As noted in the previous article if this is the first time you have used this picker you will need to supply the rootservices address of your /am installation. Also as noted previously if your model is in a configuration-aware project you will also need to select the correct configuration on which to report using OSLC Configuration Selection. Lastly, you will need to add your username and password to the properties.

 

Then we can generate a report to make sure we can at least report the model element before we look at reporting on its links (I’ll assume you’ve done that)

Reporting on Links

At the time of writing, retrieving model element data using a REST client does not include the links. There is no easy way to retrieve that data without already knowing the schema structure (which kind of defeats the purpose of using the REST client to perform this kind of exploration). Fortunately, links in RMM are as simple as the rest of the schema. There is one node for Links which has three attributes:

  • linkTypeUri – we don’t need to follow that – we can just parse it as a text string
  • linkValidity – a simple integer
  • targetUri – the URI of the element at the end of the link

We can always print out those values into a document if we want to see what they look like (a good practice in Document Studio anyway – if in doubt – print it out!) – which will help us construct the rest of the template. For example the linkTypeURI’s look like this:

To ensure that we use the correct schema, we need to detect the type of element being linked and filter on that. Whilst we could parse these by switching to a custom schema (and following the LinkTypeURI), in practice, it is far easier to simply filter on the text of the linkTypeURI which contains the necessary information

Reporting on Linked Requirements

For example, to report on linked requirements we first filter the link to make sure it is pointing at a requirement:

(Of course, multiple link types can be used to connect model elements to requirements so we would need to make sure we account for them all)

Then we can use a Data Source Configuration to switch to the DOORS Next requirement schema. Adding a DNG Text schema to the template was covered in the previous article so we won’t duplicate it here. The links are ‘non-reportable’ so we will need POX, but since our AM data source already uses it, we can inherit that, which makes the configuration very simple indeed (Don’t forget to hide the data source from the DocSpec)

Lastly, we can report linked requirement data:

Reporting on Linked Test Cases and Work Items

Now that we have the link URI, reporting on linked test cases or linked work items is no different to how we did it when reporting from requirements to those artifacts, so refer back to the last article for how to traverse these links.

That’s it for this article. So far we’ve covered how to start the report from a requirement and a model element, and how to report on linked requirements, model elements, test cases, and work items. All that remains is how to start the report from a test case or a work item and we’ll cover those next.

Andy Lapping
Technical Enablement Specialist
Watson IoT & Engineering Lifecycle Management