In this posting, we’ll continue the series by seeing how we start a traceability report from IBM Engineering Test Management (ETM).

ETM has two reportable APIs:

OSLCV2

• Supports 15 concepts (Test Plan, Test Case, etc.)
• Supports POX (redirects to reportable REST)

Reportable REST

• Supports 48 concepts
• No POX support – links for schemas and data sources must be manually constructed
• Data contains no links by default – additional switches must be used to get these
• Has two types of schema (Feeds and Individual Resources)

The ETM reportable REST API exposes two types of a resource using two different schemas:

• Feeds (that is collections)
  • Contain sets of resources of the same type (Test Cases, Test Plans)
  • By default only contains the name and URL of each resource
• Individual Resources
  • It contains all of the reportable properties for a Test Case, Test Plan, etc.
  • Contains references to other linked resources (but only if an optional switch is added)

Interrogating ETM Data Using a REST Client

Interrogating the OSLC QM V2 API

Just as with the other data sources that support POX, the starting point is to obtain a URL for an artifact we wish to interrogate. In ETM this is easy, if not immediately obvious. At the top, right-hand corner of every page is a ‘clipboard’ button to copy the title or link of the displayed artifact:

As before we want the link without the configuration information – in this case, that’s an option for a ‘Concept URL’:

Now we can put that URL into our REST client, not forgetting to add the POX header which will redirect the request to the reportable REST API for individual resources:

Interrogating the Reportable REST Feed API

Just like the Engineering Workflow Management data source, the ETM Feed data source expects a query that you have to construct. The base reporting URL is:

https://host:port/qm/service/com.ibm.rqm.integration.service.IIntegrationService

That URL is then modified to create a query as we did against EWM. Things are further complicated since the query can be:

• Single project (e.g. ‘give me all test cases from project X)
  • Requires the project alias – this is a unique identifier for the project which is different than the name – later we will see how to obtain such an alias
• Cross-project (e.g. ‘give me all test cases’)
  • Cross-project feeds do not return any data for projects that are configuration aware. For those projects, you must use a single project feed.

You can obtain further details on constructing these queries here: https://jazz.net/wiki/bin/view/Main/RqmApi#integrationUrl

Cross-Project Queries

the cross-project reporting URL is:

base reporting URL/resources/type

For example (returns all test cases that are not in projects under GC):

https://ibmjazz:9443/qm/service/com.ibm.rqm.integration.service.IIntegrationService/resources/testcase

Single-Project Queries

Single-project queries take the form:

base reporting URL/resources/projectalias/type

for example (retrieves all test plans from the project with the alias MTM+Testing):

https://ibmjazz:9443/qm/service/com.ibm.rqm.integration.service.IIntegrationService/resources/MTM+Testing/testplan

Obtaining the Project Alias

To obtain the project alias, take the base reporting URL and add /projects. You can then either run a GET in your REST client or simply paste the URL into a web browser (although that does return XML so you will then have to copy and paste the content into an XML reader to make sense of it). For Example:

https://ibmjazz:9443/qm/service/com.ibm.rqm.integration.service.IIntegrationService/projects

Data in the Feed

By running a GET we can see the data available in each feed entry – which by default is limited to essentially a title and two links:

The links have different type attributes:

• Type: application/xml  – This is the reportable URL
• Type: text/html – This is the user interface navigable URL

Obtaining More Information

By adding an extra parameter (?abbreviate=false) to the query URL we can get more data returned in the feed. For example:

https://ibmjazz:9443/qm/service/com.ibm.rqm.integration.service.IIntegrationService/resources/MTM+Testing/testcase?abbreviate=false

This causes the returned entry to have an additional sub-node – content – which has some more  data about that feed entry:

However, this content is limited to the type of element in the feed. For example, if you have a feed for test plans, you can report the names, ids and so on of those plans by simply adding the abbreviate=false parameter. The feed would also contain references to the test cases that are in that plan – but those would be simple URLs – to obtain any more information (such as the titles of those test cases) you would need to switch to a specific resource data source in your template. Don’t worry – we’ll see an example of this later.

Reporting on ETM Data

In this example, we will start our report on a single test plan and so we will begin with the OSLC QM V2 API. However since we will use POX to redirect the initial request to the reportable REST API for individual resources, that is the schema we need to add, we do not need one for V2.

Adding a Data Source Schema for an Individual Resource

This is, fortunately, one of the predefined schemas in Document Studio (as before you will need to supply the server, port, and credentials). This schema is generic and can be used to report on test plans, test cases and so on – so let’s name it for its intended purpose (Test Plan)

Reporting on Test Artifact Data

Now we can report on the title of a test plan:

Configuring the Document Specification

To configure the document specification we can use the OSLC Resource Selection tool (as before this will add the URL and POX but we then need to supply credentials)

At this point, we should generate a document and make sure we are seeing the test plan title.

Reporting on Test Cases in the Plan

If we examine the test plan using our REST client we can see that the test cases in the plan are references (note the href attribute) – we will need to traverse them and switch to a test case schema to see the details

First, we need another schema for an individual test artifact (schemas are not re-usable and the one we added has already been used to process the test plan). We could add a second one with a different name using Data > Add Data Source menu, or we can duplicate the existing one – which is much quicker. In the Outline panel, we can right-click the data source and select Duplicate Schema

And again we will name it according to its purpose:

 

The URIs obtained from the artifact are reportable (without POX), BUT by default, the data returned from that URL will not contain any links. So if we want to report on requirements, model elements and work items linked to the test cases, then we need to add another parameter to the request using JavaScript: ?calmlinks=true

We can then use that URI in the Data Source Configuration to switch to a schema we can use to report on Test Cases AND any artifacts linked to them:

Reporting on Test Case Information

We can now iterate over the testcase node from the Test Case data source and get the actual test case data

Reporting on Linked Data

Each type of linked data has its section under the test case node. Note that the URLs are non-reportable so you will have to use POX or manipulate the URL as described in the previous articles.

 

That’s all for now. In the next posting, we’ll take a look at how to combine Jazz Reporting Services Report Builder and PUB to produce documents.

Check out Part Seven in this series: Reporting from JRS

Andy Lapping
Technical Enablement Specialist
Watson IoT & Engineering Lifecycle Management