Folder support added to RRC 4.0 OSLC-RM API implementation

There is now folder support in RRC 4.0 with the OSLC-RM API.  This was a highly requested feature for those trying to integrate with RRC via the OSLC-RM API.  In version 3.0.1, it was only possible to create a requirement in the root folder with the Requirement Creation Factory OSLC API.  With version 4.0, you can now create a requirement in any folder along with these other use cases:

  • Create Folder
  • Discover and navigate the folder structure
  • Move a requirement from one folder to another

Here is a preview on how to get started.  The examples below will cover how to discover the root folder and navigate the folder structure of a RM project, create a folder and how to create a requirement in that new folder.  At the end, I will mention briefly how to move a requirement from one folder to another.  This information will be incorporated into an updated version of the OSLC workshop on, so stay tuned for that for some sample code.  Note that in all the examples below, I do not discuss the request header.  The request header must contain OSLC-Core-Version=2.0 and Accept=application/xml (where applicable).

Discover the ‘root’ folder of the RM project

If you have played around with OSLC-CM or OSLC-RM and the IBM Rational implementation provided by RTC or RRC, you know you need to start with a GET of the rootservices document:


Next, look for the catalog of Requirements Management Service providers which looks like this in the rootservices document:

<!-- Catalog of Requirements Management Service Providers on this server -->
<oslc_rm:rmServiceProviders rdf:resource="" />

Next, proceed with a GET on the catalog URL which results in a list of service provider URLs, one per RM project in the RM server:


Response Body (Partial):
...<oslc:ServiceProvider rdf:about="">...

A GET on the service provider URL for a project yields a number of services, one of which is the query capability.  With RRC v4.0, there are now 2 entries returned for query capability.  One of them is the Folder Query Capability URL.

Response Body (Partial):

<dcterms:title rdf:parseType="Literal">Folder Query Capability</dcterms:title>
<oslc:queryBase rdf:resource=""/>

The folder query capability URL is the way to discover the ‘root’ folder of the RM project.

An alternate way of retrieving the Folder Query Capability URL is by constructing a URL using the project ID and sending a GET request using this URL:  https://<server:port>/rm/folders/<project-id&gt;.  In our example, the project id is _a0x-oLVyEeG3pOZm5lwEBA.  NOTE:  We will need this later when creating a folder.  The project ID can be found in the service provider URI of the RM project.  Here is the alternate way of retrieving the folder query capability URL:


In the response body, look for the nav:subfolders element and the rdf:resource attribute:

...<nav:subfolders rdf:resource=""/>...

In our example, the folder query capability URI of the ‘root’ folder is

The above folder query capability URI allows you to retrieve information about the root folder and discover attributes that will allow top down navigation of the folder structure.


Response Body

This response body contains the top level folders of this RM Project:  JKE Private Banking and Securities Project , JKE Enterprise Project, and JKE Business Recovery Matters.  Each folder contains a nav:subfolders element which is that folder’s query URL.  Use that URL to discover any subfolders.  Each folder has its own unique identifier which is found in the rdf:about attribute of the nav:folder element.  It is this attribute that will be used in our next section to identify the parent folder of a new folder.

Create Folder

Now, let’s create a subfolder in the folder ‘JKE Business Recovery Matters Project’.  We just need to provide a nav:parent element to our POST request body to indicate where we want the folder created.  In our case, we need the nav:parent element to point to the folder URL of the ‘JKE Business Recovery Matters Project’ folder.   That was obtained at the end of the previous section using the rdf:about attribute of the nav:folder element for the ‘JKE Business Recovery Matters Project’ folder.

For example, here is a partial POST request body:

….<dcterms:title>My First OSLC folder</dcterms:title><nav:parent rdf:resource=”">…

The POST request must be made to the folder Creation Factory URI.  The folder creation factory URI can be constructed as follows:  https://<server:port>/rm/folders?projectURL=https://<server:port>/jts/process/project-areas/<project-id&gt;.  For our example, the folder creation factory for the RM project is

The full request body for the POST would like as follows:

<nav:folder rdf:about="">
<dcterms:title> My First OSLC folder </dcterms:title>
<dcterms:description>The description is optional.</dcterms:description>
<nav:parent rdf:resource=""/>

After the POST, you can get the folder URL of the new folder from the location field of the response header.

You can also confirm via the RRC Web UI Artifacts page that there is a new folder, ‘My First OSLC folder’, created under the ‘JKE Business Recovery Matters Project’ folder.

Create Requirement in folder

Next, I want to create a requirement in this new folder.  Requirements can be created using the Requirement Creation Factory URL.  I can find that URL by doing a GET on the services provider URL for my RM project.  We did that earlier to locate the Query Capability URL.


Response Body (Partial):

<dcterms:title rdf:parseType="Literal">Requirement Creation Factory</dcterms:title>
<oslc:creation rdf:resource=""/>
<oslc:resourceType rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:resourceShape rdf:resource=""/>
<oslc:usage rdf:resource=""/>

Next, construct the requirement creation request.   Grab one of the resourceShape URLs and use it as the instanceShape rdf:resource.  To specify a folder  for this requirement, add the nav:parent element and provide the folder URL in the rdf: resource attribute.  How do you find the folder URL?  At the end of the previous section, it was part of the response header.  If it was not saved, then simply do a GET on its parent folder query URL, and parse for the name of the new folder in the query results.

Once the nav:parent element value has been located, use it to complete the content for the new requirement.  Here is the complete content to send in the POST request body.

<?xml version="1.0" encoding="UTF-8"?>
<dc:description>This is a test document</dc:description>
<nav:parent rdf:resource=""/>
<oslc:instanceShape rdf:resource=""/>
<rm_property:_bw8r8rVyEeG3pOZm5lwEBA rdf:parseType="Literal">
<div xmlns="" id="_Nf2cQJKNEd25PMUBGiN3Dw"><h1 id="_DwpWsMueEd28xKN9fhQheA">Test Document</h1></div></rm_property:_bw8r8rVyEeG3pOZm5lwEBA>

To create this requirement, do a POST to the requirement creation URL with the above POST body.  The location field of the response header will contain the URL of the newly created resource.

Move requirement from one folder to another

To move a requirement from one folder to another, you simply have to update the nav:parent element of the requirement using a PUT.  We cover updating a requirement in Example 4 of the OSLC workshop.

  1. Locate the folder URL of the new folder you want to move the requirement to.
  2. Update the  rdf:resource attribute of the nav:parent element.  The rdf: resource attribute of the nav:parent element is what contains the folder URL for a requirement resource .

Here is a the XML for a requirement resource.  Notice the highlighted nav:parent element.

Useful Tools

There are a few tools that are useful when working with the OSLC API.  Here are some links.

HTTPRequester Add-on for Firefox

RESTClient Add-on for Firefox


CLM 2012 is coming. Are you ready?

Well, I know it’s been a while since my last post.  Sorry, but it sure has been a busy year for me as a Jazz Jumpstart team member.  Last year at this time, I was busy testing the upgrade to CLM 2011 and helping our User Assistance team put out the best documentation possible.  The Jazz Jumpstart team also released a great workshop to help folks learn how to upgrade to CLM 2011:

So, what am I up to now?  I’m busy testing and helping to document the upgrade to CLM 2012, of course.  I started thinking that there are things CLM customers could be doing now to get ready to upgrade to CLM 2012.  Why not blog about it?  So here goes…..

Review the CLM 2012 System Requirements

Review the upgrade process

The development wiki contains some drafts of the upgrade process.  Review it to start getting familiar with the process.  Remember that this is all pre-release and subject to change.  The official upgrade process will be in the 4.0 infocenter.

Start preparing a test environment for upgrade testing

This is still a good idea even though the upgrade process this year is much easier.  Here is a way to get started:  Staging a test environment for the upgrade process

Once you have a test environment set up, try it out the process with one of the 4.0 release candidates:  Download 4.0 RC3

Configure a data warehouse if you haven’t already

When you first upgraded to CLM 2011, you may have skipped configuring a DW.  Plan to configure a DW so that you can begin taking advantage of the CLM reporting features.  And, when you upgrade to CLM 2012, you will be able to avoid running JTS setup altogether.  Read this topic for assistance:  Configuring the DW after running JTS setup

Upgrade to the latest fixpack

Do some research on the IBM support portal pr the website and figure out if you should upgrade to the latest fixpack of the CLM applications you are running in your deployment.  The latest fixpack is v3.0.1.3 for RTC, RQM and RRC.  It’s easy to upgrade to the latest fixpack of CLM 2011.   Read this topic for assistance:  Upgrading to version 3.0.1 fixpack releases

Welcome to my Blog!


Since I have joined the IBM Jazz Jumpstart team, I’ve been encouraged to start this blog.  This will give me the opportunity to share tips and tricks with you that will help you make the best use of IBM Rational’s Jazz suite of products.  In particular, I am excited about the upcoming release of our Collaborative Lifecycle Management (CLM) solution, version 3.0.1.  You can get more information and get just as excited by visiting the central location for ‘all things Jazz’:  a.k.a This new release will simplify the way Rational Team Concert, Rational Quality Manager and Rational Requirements Composer (the 3 original Jazz-based products) work together to help teams improve their productivity across the application lifecycle.

My initial focus will be on the following topics: Upgrade, RRC v3.0.1 new features and the Reporting capabilities built-in to the CLM solution.