Upgrade Alert! License package changes affect some upgrade scenarios

Overview

There was a change made in how the various CLM app-specific functional Client Access licenses (CAL) are packaged in CLM v4.0.1 which has caused a problem for staged upgrades to v4.0.1 or greater from versions 3.0.1.x or 4.0 in distributed environments.   A staged upgrade is the kind that we have always recommended and it means if you have multiple CLM applications, you should upgrade them one at a time.  The issue along with the workaround is described in detail in this workitem:  Incorrect documentation for upgrading JTS and apps in a staged fashion when going from pre-4.0.1 to post 4.0.1 CLM release (251460)

Basically, there are functional app-specific CALs such as the CCM Data Collector, QM Data Collector, RQM Connector, Build System, CQ Synch, and CC Synch that used to be packaged with the Required Base License Keys Including Trials package that was installed by Installation Manager along with the JTS and the CLM server packages prior to v4.0.1.  In version 4.0.1, a change was made to rename this license package as well as to move these app-specific functional CALs to be contributed by their respective CLM server applications.  For example, the CCM Data Collector, CQ Synch, Build System and CC Synch CALs are now being contributed only when the CCM (4.0.1 or greater) server package is installed.  Thus, let’s say that you are planning an upgrade from v3.0.1.4 to CLM v4.0.1 and have a distributed CLM deployment with a JTS, CCM and a QM application.  You start by staging an upgrade of just the JTS and CCM applications.  So, you install the JTS and CCM 4.0.1 install in their respective locations so that you can perform a side by side upgrade.  In v4.0.1, the license package is called Trial Keys for Collaborative Lifecycle Management Products.  It only contains the Trial licenses.  The other licenses needed are now contributed by the applications themselves.  Thus, if you upgrade only JTS and CCM to v4.01 and leave QM at v3.0.1.4, you will have some license assignments that refer to licenses that no longer exist such as the QM Data Collector or RQM Connector.  This is because QM is still at v3.0.1.4 and these licenses will not be provisioned until QM is upgraded to v4.0.1.  If you upgrade all the apps at once, this is not an issue.  This is only an issue for staged upgrades.

What is being done about this problem?

A zipfile containing all of the 4.0.x functional CALs is being made available via workitem 251460 above that can be installed via the JTS Admin web UI after the JTS is upgraded.  This will allow these functional CALs to be persisted in the database.  At the time you subsequently upgrade any of the apps such as CCM, QM or RM, all the functional CALs associated with the application would need to be deleted.  This is necessary so that the new CALs contributed by the upgraded app will take effect rather than the ones persisted in the database.

Why do we need to install these 4.0.x functional CALs in the first place?

These functional CALs are assigned to functional users.  Since they are now contributed by the applications, once the JTS is upgraded, the older functional CALs are removed so you end up with functional user CAL assignments to licenses that do not exist.  This causes problems with the operation of the non-upgraded applications.

Why do we need to delete these 4.0.x functional CALs prior to upgrading a particular application?

If they are not deleted, then these functional CALs persisted in the database repository will take precedence over any CALs contributed by the upgraded app.  This is not the state we want to have.

Advertisements

Getting Started with Rational Lifecycle Integration Adapter for GIT

I recently had the opportunity to help some of our client technical professionals overseas get familiar with the Rational Lifecycle Integration Adapters (RLIA) – Standard Edition.  This included some install and configuration sessions and some exercises to help them understand the key features.  But, I was missing some information on how to install and configure the GIT Adapter.  It is documented in the RLIA v1.0 infocenter, but sometimes it’s better to see it broken down into some simple steps with notes and then run through it oneself.  So, that’s what I did when I got back to the office.  I just had to see how to get to the point where RTC and GitWeb were integrated.

I’ll take you through what I did to get RTC 4.0.1 and GitWeb integrated such that I could link Git commits with RTC workitems.

Environment

Windows 7 64-bit

CLM 4.0.1 deployed on Tomcat with a Derby database and the Money that Matters sample.

CLM 4.0.1 public URI is set to https://clm.jkebanking.net:9443/jts

GitWeb 1.7.1 running on a Linux VM image

DB2 Workgroup Server Edition, v9.7

Note:

  • Administrator privileges are required to install the adapter.
  • If your CLM 4.0.1 public URI does not contain a port, please contact IBM support to obtain a hotfix for the Rational Adapter for Git that will work in your environment.

Installation and Configuration

The Git adapter needs to be installed into the same location as Jazz Team Server (JTS).  For example, if you want to integrate with a specific instance of the RTC 4.0.1 application, you need to figure out what JTS that RTC 4.0.1 application is registered with.

I started by running the Interactive Installation guide located here:  http://pic.dhe.ibm.com/infocenter/rliahelp/v1/topic/com.ibm.rational.rlia.git.install.doc/topics/roadmapgit_form.html

  1. Create a DB2 database using the instructions here:  http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0/topic/com.ibm.jazz.install.doc/topics/t_s_server_installation_setup_db2.html
  2. Stop the CLM 4.0.1 server.
  3. Locate the Rational Lifecycle Integration GIT Adapter install directory, GIT\disk1, of the installation media.  Run launchpad.exe to install the adapter into the same application server instance as the JTS.
  4. After adapter install completes, start the CLM 4.0.1 server.

What we have done so far is (1) installed the adapter to the same application server as the Jazz Team Server, and (2) set up the database to use with the adapter.  Now, we want to register the Rational Adapter for Git application with the JTS.  This part is pretty straightforward if you have configured CLM before.  Here’s a link that covers this next step:  http://pic.dhe.ibm.com/infocenter/rliahelp/v1/topic/com.ibm.rational.rlia.git.install.doc/topics/t_register_git.html

When I ran through this part, I got a message during Step 7 regarding having to upgrade the data warehouse. I skipped this step by selecting the checkbox, ‘I do not want to configure a data warehouse at this time’.  Development said it was ok to do this and that this was not the expected behavior. It should have just worked.  In Step 5, I also let it create a default functional user, gitAdapter_user.

After the adapter application is registered, we can proceed to configure linking between the RTC application and the Rational Adapter for Git.

The next part consists of the following areas:

  • Establishing cross-server communication
  • Approving the access request
  • Deploying the Gitweb additions
  • Registering the Gitweb server
  • Registering the Gitweb project

Establishing cross-server communication

This part is pretty straightforward. It involves establishing a friend relationship between the Rational Adapter for Git and RTC.

  1. Follow the process described in this topic:  http://pic.dhe.ibm.com/infocenter/rliahelp/v1/topic/com.ibm.rational.rlia.git.install.doc/topics/t_servertoserverestablish_gittojazz.html  HINT: Use a meaningful name for the friend relationship so that you can identify it easily later on in this process.  I used this name: GIT clm.jkebanking.net
  2. Open the JTS Admin page in a browser.
    1. Create a user called ‘githook’.
    2. Apply a RTC Contributor Client Access License (CAL).
    3. Add this user as a member of the RTC projects that you want to integrate with Git using this adapter.

Approving an access request

This part can be automatic if you are logged in as a CLM Administrator like I was.  You get the option to grant provisional access.  However, there is a part that is not quite documented well and is mentioned in passing in Step 7.  It discusses a functional user ID that needs user privileges to update workitems and permissions in the RTC project area that will be used by this integration. But, it is the first time this is mentioned.  That is the reason I had you create a user, ‘githook’ in the previous section.

http://pic.dhe.ibm.com/infocenter/rliahelp/v1/topic/com.ibm.rational.rlia.git.install.doc/topics/t_approve_consumer_keys_git.html

  1. Open the CCM Admin page in a browser, for example, using a URL such as :  https://clm.jkebanking.net:9443/ccm/admin using an account with administrator privileges.
  2. Navigate to the Consumers (Inbound) page.
  3. Locate the consumer relationship in the Authorized Keys section.
  4. Follow steps 6 and 7 of the infocenter topic listed above to add the githook user to this consumer key.  Note: There is no functional user associated with this inbound consumer. This is where we want to add the ‘githook’ user we created earlier.

Deploying GitWeb additions

This part is done where GitWeb is installed.  The GitWeb additions add a banner to the GitWeb interface that supports: (1) the creation of links between commits and RTC workitems, (2) traversal of existing links and (3) rich hover support of existing links.

http://pic.dhe.ibm.com/infocenter/rliahelp/v1/topic/com.ibm.rational.rlia.git.install.doc/topics/t_deploy_gitweb_additions_git.html

  1. Follow the instructions in the topic above.
  2. In Step 4, follow the suggestion to copy/paste the contents of gitweb.conf.README to the gitweb.conf file for your installation.

Once this section is complete, you should see the following banner when opening GitWeb.

Image

Registering the Gitweb server

Now that we have the Rational Adapter for Git banner installed, we will use it to register the Gitweb server with the adapter.  This step will allow to the Gitweb server to be recognized by Gitweb objects.

Follow the steps in this topic:  http://pic.dhe.ibm.com/infocenter/rliahelp/v1/index.jsp?topic=%2Fcom.ibm.rational.rlia.git.install.doc%2Ftopics%2Ft_deploy_gitweb_additions_git.html

Make sure to follow Step 6 which further updates the ./static/oslcConfig.js file.

Registering the Gitweb project

We can now finish the configuration by registering one or more Git projects with the Rational Adapter for Git.

Follow the steps in this topic:  http://pic.dhe.ibm.com/infocenter/rliahelp/v1/topic/com.ibm.rational.rlia.git.install.doc/topics/t_register_git_project_git.html

Take a note of Step 8.  If you want to configure the ‘commit hook’ piece of the integration, you will need to record the Gitweb project URI.  You can retrieve this Gitweb project URI at a later time however by going to the Git Adapter Appication Administration page (https://<publicURI>/gitAdapter/admin) and selecting the Git Server connection entry ID hyperlink.

Image

Image

Validate the Gitweb integration

Once the above steps are complete, we can validate the Gitweb integration by following the usage in this topic:  http://pic.dhe.ibm.com/infocenter/rliahelp/v1/topic/com.ibm.rational.rlia.git.doc/topics/c_git_use_gitweb_ovw.html

Conclusion

We have now completed one part of the Rational Adapter for Git installation and configuration.  With this integration, we can link existing commits to either existing Rational Team Concert change requests or new change requests.  There is another integration that is supported by the Rational Adapter for Git.  It uses the Git command line to create links between a Git commit and a change request in RTC via the command line.  I will be looking at this next.  If there is anything tricky, I will create another blog post.  In the meanwhile, you can access the deploy instructions in this topic:  http://pic.dhe.ibm.com/infocenter/rliahelp/v1/topic/com.ibm.rational.rlia.git.install.doc/topics/t_deploy_git_receive_hook_git.html

RDz – RTC Compatibility

In this post, I want to outline the RDz considerations to keep in mind when upgrading RTC from 3.x to 4.0.

The information below is applicable to the following releases:

  • RTC 3.0, 3.0.1, 3.0.1.x, 4.0
  • RDz: 8.0.3.x, 8.5

Definitions

RTC

Eclipse client:

This is the Eclipse based client that can be shell shared with the RDz Eclipse client. For the two products to interact they need to shell share.

Server:

This is the server piece of the CLM product (in which RTC is an application along with RQM and RRC). The server can run on various different platforms and the clients connect to it via a web browser or an eclipse IDE.

Build Toolkit:

This is part of the RTC product that is installed on the platforms that code needs to be built on.  In the case of mainframe development, it is installed on the zOS system.

RDz

Eclipse client:

This is the Eclipse based client that can be shell shared with the RTC Eclipse client. Obviously for the two products to interact they need to shell share.

RDz server side code:

This is code that must be installed onto the z/OS system so that the RDz client can talk to it. There are various parts to this such as the RSE (Remote System Explorer) that enables the RDz client to interact with the z/OS file system. There is also the Job Monitor that allows RDz to get notification on jobs running on the z/OS system. This enables a job to be submitted via the RDz Eclipse client and the Eclipse client being able to monitor the job and report back its status.

RTC/RDz Integration – What is it exactly?

The integration is achieved by first installing the two clients using shell sharing. Shell sharing means that they can coexist but there is no specific targeted integration yet between the two products. One can use the RTC functionality and the RDz functionality in the same client but there is no specialized integration going on. What is available from RTC 2.0 and onwards is some meaningful integration between the two clients. This is provided via an installable feature that is shipped with the RDz product. It is the ‘glue’ that allows the RDz Eclipse client and the RTC client to become aware of each other and work together.

With RDz 8.5, there is a change with the API that RTC uses to communicate with RDz (i.e. the API changed). Thus, there are two RTC/RDz Integration features shipped with RDz 8.5. One allows RTC 4.0 to talk with RDz 8.5 and the second one allows RTC 3.x to talk with RDz 8.5. Based on the version of the RTC client, pick the correct integration feature to install in your environment.

Now, what integrates with what exactly?

Clients

The only combination of clients that will NOT work is RTC 4.0 + RDz 8.0.3.x. Another way to say this is that RTC 4.0 pre-req’s RDz 8.5 if you want to use the integration feature. All other combinations work and have been tested either by RTC test team or by the RDz test team.

RDz Server side code (mainframe)

  • The RSE shipped with RDz 8.0.3.x will work with RTC 3.x and 4.x
  • The RSE shipped with RDz 8.5 will work with RTC 4.x

RTC server compatibility

There is N-1 client compatibility.  Thus, an RTC 3.x client will work with an RTC 4.0 server and obviously a RTC 4.0 client will not work with a RTC 3.x server

Build Toolkit

We recommend the following combinations of client and build tool kit combinations when the server has been upgraded to RTC 4.0

  • RDz 8.0.3.x client + RTC 3.x client would use RSE + build tool kit 3.x
  • RDz 8.5 client + RTC 4.x client would use RSE + build tool kit 4.x

I’m upgrading my RTC environment(clients and server) to 4.0, what do I have to upgrade?

On the client side, you will need to upgrade the RDz clients from 8.0.3 to 8.5 and use the RTC/RDz integration feature provided shipped with RDz 8.5.

On the server side, specifically the RSE, the 4.0 RTC / RDz 8.5 client integration will work with the RDz 8.0.3.x RSE. Naturally, any server-side dependent features for 8.5 will not work, so the user is restricted to 8.0.3 functionality for anything that is related to server side function.

Additionally, on the server side, there may be build toolkits installed. Any 3.x RTC client should continue to use a 3.x build toolkit.  Any 4.0 RTC client should use a 4.0 build tool kit.

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 Jazz.net, 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:

GET https://clm.jkebanking.net:9443/rm/rootservices

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="https://clm.jkebanking.net:9443/rm/discovery/RMCatalog" />

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:

GET https://clm.jkebanking.net:9443/rm/discovery/RMCatalog

Response Body (Partial):
...<oslc:ServiceProvider rdf:about="https://clm.jkebanking.net:9443/rm/discovery/_a0x-oLVyEeG3pOZm5lwEBA/services.xml">...

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.
GET https://clm.jkebanking.net:9443/rm/discovery/_a0x-oLVyEeG3pOZm5lwEBA/services.xml

Response Body (Partial):

<oslc:QueryCapability>
<dcterms:title rdf:parseType="Literal">Folder Query Capability</dcterms:title>
<oslc:queryBase rdf:resource="https://clm.jkebanking.net:9443/rm/folders?oslc.where=public_rm:parent=https://clm.jkebanking.net:9443/rm/folders/_a0x-oLVyEeG3pOZm5lwEBA"/>
</oslc:QueryCapability>

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:

GET https://clm.jkebanking.net:9443/rm/folders/_a0x-oLVyEeG3pOZm5lwEBA

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

...<nav:subfolders rdf:resource="https://clm.jkebanking.net:9443/rm/folders?oslc.where=public_rm:parent=https://clm.jkebanking.net:9443/rm/folders/_a0x-oLVyEeG3pOZm5lwEBA"/>...

In our example, the folder query capability URI of the ‘root’ folder is
https://clm.jkebanking.net:9443/rm/folders?oslc.where=public_rm:parent=https://clm.jkebanking.net:9443/rm/folders/_a0x-oLVyEeG3pOZm5lwEBA

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.

GET https://clm.jkebanking.net:9443/rm/folders?oslc.where=public_rm:parent=https://clm.jkebanking.net:9443/rm/folders/_a0x-oLVyEeG3pOZm5lwEBA

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=”https://clm.jkebanking.net:9443/rm/folders/_u0xiMbVyEeG3pOZm5lwEBA">…

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

https://clm.jkebanking.net:9443/rm/folders/?projectURL=https://clm.jkebanking.net:9443/jts/process/project-areas/_a0x-oLVyEeG3pOZm5lwEBA

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

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:oslc="http://open-services.net/ns/core"
xmlns:nav="http://jazz.net/ns/rm/navigation"
xmlns:calm="http://jazz.net/xmlns/prod/jazz/calm/1.0/">
<nav:folder rdf:about="">
<dcterms:title> My First OSLC folder </dcterms:title>
<dcterms:description>The description is optional.</dcterms:description>
<nav:parent rdf:resource="https://clm.jkebanking.net:9443/rm/folders/_u0xiMbVyEeG3pOZm5lwEBA"/>
</nav:folder>
</rdf:RDF>

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.

GET https://clm.jkebanking.net:9443/rm/discovery/_a0x-oLVyEeG3pOZm5lwEBA/services.xml

Response Body (Partial):

<oslc:CreationFactory>
<dcterms:title rdf:parseType="Literal">Requirement Creation Factory</dcterms:title>
<oslc:creation rdf:resource="https://clm.jkebanking.net:9443/rm/requirementFactory?projectURL=https%3A%2F%2Fclm.jkebanking.net%3A9443%2Fjts%2Fprocess%2Fproject-areas%2F_a0x-oLVyEeG3pOZm5lwEBA"/>
<oslc:resourceType rdf:resource="http://open-services.net/ns/rm#Requirement"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_n-4BYbVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_n_S4IrVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oAo79LVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oA5aobVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oDjGBbVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oD5rUbVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oEPCg7VyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oFQ9QrVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oFql4rVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oF85wbVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oIepVLVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oKvTIbVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oMQ9IbVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oMj4ELVyEeG3pOZm5lwEBA"/>
<oslc:resourceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_oNGqobVyEeG3pOZm5lwEBA"/>
<oslc:usage rdf:resource="http://open-services.net/ns/core#default"/>
</oslc:CreationFactory>

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"?>
<rdf:RDF
xmlns:oslc_rm="http://open-services.net/ns/rm#"
xmlns:dc="http://purl.org/dc/terms/"
xmlns:oslc="http://open-services.net/ns/core#"
xmlns:rm_property="https://clm.jkebanking.net:9443/rm/types/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:nav=http://jazz.net/ns/rm/navigation#">
<oslc_rm:Requirement
rdf:about="">
<dc:title>MyDocument</dc:title>
<dc:description>This is a test document</dc:description>
<nav:parent rdf:resource="https://clm.jkebanking.net:9443/rm/folders/_EH_3wr8BEeGugPMVwOckzA"/>
<oslc:instanceShape rdf:resource="https://clm.jkebanking.net:9443/rm/types/_n-4BYbVyEeG3pOZm5lwEBA"/>
<rm_property:_bw8r8rVyEeG3pOZm5lwEBA rdf:parseType="Literal">
<div xmlns="http://www.w3.org/1999/xhtml" id="_Nf2cQJKNEd25PMUBGiN3Dw"><h1 id="_DwpWsMueEd28xKN9fhQheA">Test Document</h1></div></rm_property:_bw8r8rVyEeG3pOZm5lwEBA>
</oslc_rm:Requirement>
</rdf:RDF>

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:  https://jazz.net/library/article/662

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

https://jazz.net/wiki/bin/view/Main/CLMWorkbenchSystemRequirements

Review the upgrade process

The Jazz.net 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.

https://jazz.net/wiki/bin/view/Main/CLM301x40UpgradeDistributed

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 Jazz.net 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!

Hello.

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 Jazz.net. 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.