OSLCLink for ClearQuest Bridge to RQM: advantages, disadvantages, net results of mapping state predicates
Hello,
Concerning the integration of ClearQuest and RQM through the ClearQuest Bridge, technote 1433074 describes prerequisite steps taken to prepare the ClearQuest schema repository for the Bridge:
Step 4 under Section E mentions using state predicate support to map ClearQuest states to OSLC states. Not a lot of readily available documentation further describes how this affects the eventual integration between ClearQuest Bridge and RQM. I am interested in finding out what are the advantages, disadvantages, and/or net results of performing this state-to-state mapping as opposed to not performing it. As ClearQuest-RQM integration is the end goal, how does this step, if at all, impact the eventual integrated tool set?
Thanks,
Jake Huang
Accepted answer
@Jacob Huang, thanks for your question. RQM implements OSLC 1.0 and 2.0 to integrate with CQ. OSLC spec has its own definition of defect status. For example, OSLC 2.0 defines six defect statuses
(http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;table=up#CM_Resource_Definitions).
In order to integrate with other software CQ must comply with OSLC spec. As a result CQ needs to map its own status(which is defined by customers) to OSLC defined status so that the integration on the other end can really understand CQ defect status. For RQM/CQ integration, customers must implement state mapping to make it work correctly. Hopefully it answers your questions. Thanks
| oslc_cm:closed | zero-or-one | True | Boolean | n/a | n/a | Whether or not the Change Request is completely done, no further fixes or fix verification is needed. | |
| oslc_cm:inprogress | zero-or-one | True | Boolean | n/a | n/a |
Whether or not the Change Request in a state indicating that active work is occurring. If
oslc_cm:inprogress
is
true
, then
oslc_cm:fixed
and
oslc_cm:closed
must also be
false
|
|
| oslc_cm:fixed | zero-or-one | True | Boolean | n/a | n/a | Whether or not the Change Request has been fixed. | |
| oslc_cm:approved | zero-or-one | True | Boolean | n/a | n/a | Whether or not the Change Request has been approved. | |
| oslc_cm:reviewed | zero-or-one | True | Boolean | n/a | n/a | Whether or not the Change Request has been reviewed. | |
| oslc_cm:verified | |||||||
In order to integrate with other software CQ must comply with OSLC spec. As a result CQ needs to map its own status(which is defined by customers) to OSLC defined status so that the integration on the other end can really understand CQ defect status. For RQM/CQ integration, customers must implement state mapping to make it work correctly. Hopefully it answers your questions. Thanks
One other answer
CQ state mapping is necessary when integrated with RQM if you have defect related "Quality Objectives" set up for test plans. When you evaluate "Quality Objectives', it sends request to CQ to check what defects are in closed versus inprogess state.
Mapping is also critical if you have set up automatic unblocking of TCERS in RQM.
If you store "Quality Tasks" in CQ, state predicates are needed for "Formal review" to work correctly.