It's all about the answers!

Ask a question

2 questions on RQM, ClearQuest and Insight ?


David Mehaffy (90123338) | asked Oct 30 '12, 3:14 p.m.
JAZZ DEVELOPER
edited Oct 30 '12, 3:15 p.m.
1.  The first question is I have pretty much worked out the ETL for CQ and have it working.  What I would like to do now is add the component name from CQ to the Request table.  I don't see where that is delivered in CQ ALM or CQ ENT?  It seems to need an id and a name to be delivered to the REQUEST_CATEGORY table but I don't see where that is delivered in the CQ job builds

2.  When trying to view the data in reports I am unable to join the execution results with the results related requests as there is no common key.  I am able though to make it work if I start with request and add the results related requests - it seems like it should work both ways?  Am I doing something wrong.  Also I don't see where or if the table execres_request_lookup get materialized.  If I look at that with db2 client I see the expected request id, result_id pairs and have verified them.

2 answers



permanent link
Hopeshared Lee (1121) | answered Nov 01 '12, 8:04 p.m.
JAZZ DEVELOPER
1. There is no out-of-the-box ETL logic designed for CQ to deliver component information into data warehouse, but there is COMPONENT_ID in RIODS.REQUEST table. You have to customize ETL to deliver data you need into data warehouse, learn how to customize it by tutorial:
http://publib.boulder.ibm.com/infocenter/rentrpt/v1r0m1/index.jsp?topic=%2Fcom.ibm.rational.raer.tutorial.doc%2Ftopics%2Ft_etl_intro.html
2. When authoring reports, you can drag executionresult_id from Execution Result in Execution Result Area and request_id from Execution Result Related Requests in Execution Result Area. They have been joined by execres_request_lookup in Framework Manager so you don not need to join them in report. You can drag them from Request Area as well.

Comments
David Mehaffy commented Nov 02 '12, 2:46 a.m.
JAZZ DEVELOPER

thank you for your response.  On question 1, I assume I would load the CQ category table into request_category using the dbid as the id and name as the component name.  When I fetch the defect data I would get the component name from there as it is in our schema and then lookup the id in the request_category table and then deliver the id I get into the request table?  I want to minimize changing the fm model or dw tables as it can cause problems on upgrades.


On question 2 I thought I had done that and I was not getting the relationship, that is I was seeing the result data starting at row 1 and the request data starting at row 1 so they were not related.  I will try it again and see if it works. 


Hopeshared Lee commented Nov 07 '12, 2:38 a.m.
JAZZ DEVELOPER

For question 1, yes if you don't use CQ category, you can load CQ component data into that table and then lookup component id (althrough it is named as category id) and deliver into request table as CATEGORY_ID because there is an foreign key constrain in data warehouse.


permanent link
Jun Wang (6077) | answered Nov 02 '12, 1:40 a.m.
Re question#2, when you are creating CQ requests as defects with execution results in RQM, it will built OSLC link between CQ request and execution result. RQM OOTB ETL will build their relationship in RIODS.EXECRES_REQUEST_LOOKUP table. But please make sure CQ ETL is run before RQM ETL and the CQ request has been into RIODS.REQUEST table via CQ ETL.
About how to show them in reports design, please refer to Hopeshared Lee's reply.

Comments
David Mehaffy commented Nov 02 '12, 2:50 a.m.
JAZZ DEVELOPER

Hi - yes that is the way I am doing it - I verified that the execres_request_lookup table had the correct data in it by doing db2 selects and then comparing the ids with what was found in rqm user interface and it all verified.  Yes I run the CQ job before the rqm job when I run the ETLs.  It took me a while to get it all working - I guess that having to load the request_history to make it work did not seem obvious to me but finally worked through all the table and columns entries that were necessary so the excecres_request_lookup table got the correct data.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.