When building templates it is often useful to be able to send a GET request to a data source, in the same way, that PUB does. This is often the only way you can find out how linked data actually appears in its reportable form, and guides the building of your template. To do that you need a REST client. There are many such clients, including browser-based add-ons such as RESTClient for Firefox and Postman for Chrome. In this article I’ll be using Postman – the desktop version as the browser add-on is now deprecated (but still works and is somewhat easier to set up and use).

Making a Request

Authentication

The main issue you will run into when using your own REST client to interrogate Jazz based resources is authentication. Browser add-ons like Postman for Chrome usually have the ability to store and re-use cookies – which means you can log in to your Jazz Team Server using the Chrome web browser, and the REST client will then re-use that same authentication. External applications (like the new Postman desktop app) need to do something similar. Postman uses a web-browser add-on called Postman Interceptor to store the cookies and make them accessible, and another application called the Bridge, to connect the desktop app to Interceptor. This isn’t difficult to set up and all the instructions are available on the Postman website: https://www.getpostman.com/

The only caveat was that in order to get it to work I had to specifically add my server to its list of domains – YMMV and I may write up a post on it at some point.

Obtaining the URI

The first thing you will need is the URI of the data source that you want to interrogate. Most artifacts in the Jazz platform have some way to get their URI (in most cases you cannot simply use the URI in the web browser address bar – that has all sorts of other stuff in it). For example:

Obtaining the URI of a Requirement in DOORS Next

Obtaining the URI of a Model Element in RMM

The URI obtained in this way usually has the base address for the artifact and then the current configuration context (so that if you paste it into a browser you are looking at the correct variant of that artifact). Document Studio (and the REST client) has its own way of adding the configuration context so in general, you should only ever copy the base address – that is the part before ?oslc_config.context=xxx

Headers

Before sending the GET request you need to add two headers:

• Accept = application/xml
• Link = <http://jazz.net/ns/profile#POX>; rel=”profile”

That second one is the POX header (assuming the URI you are querying is non-reportable and supports POX).

Adding Configuration Context

If your data source is GC aware then you will need to include configuration context information in your request. First obtain the URI of the global stream/baseline you want to query, by opening that in the GC tool and clicking the Copy URI button:

Next, add an extra header to your request:

• Configuration-Context = The Copied URI

If all goes well you should receive a 200 OK response and the reportable XML data of the resource:

That’s all for now – in the next article, we’ll build a template in Document Studio that reports on requirements in a module, along with all of their linked model elements, work items, and test cases.

Check out Part Three in this series: Reporting from DOORS Next

Andy Lapping
Technical Enablement Specialist
Watson IoT & Engineering Lifecycle Management