Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

executionworkitem ID in REST API

We recently upgraded to RQM 3.0.1 so that we could make better use of the REST API to integrate with Microsoft's TFS. The setup we are using is this:
Through the API a Build Record and Build Definition are updated when the build is done on TFS

This kicks off an execution schedule which runs a set of Test Cases

These steps have all been worked out fine. The problem we are having is in trying to recover the Test Case Execution Records when the tests are done running.

When I examine the data from an executionworkitem item, I can see a number of executionresult elements. However, rather than providing me with an ID I can query, I get a slug:

<currentexecutionresult>
<executionresult>

Compare this to other data returned where I get an ID (in this example a remote script):

<remotescript>

Is there an artifact that would contain an ID for the currentexecutionresult artifact?

0 votes



5 answers

Permanent link
The URL of the referenced test resources is contained in the href attribute of the referring test resource property (see https://jazz.net/wiki/bin/view/Main/RqmApi#Detailed_Schema_Documentation).

0 votes


Permanent link
The URL of the referenced test resources is contained in the href attribute of the referring test resource property (see https://jazz.net/wiki/bin/view/Main/RqmApi#Detailed_Schema_Documentation).


Hello Paul,

Thanks for replying to this. I'm working on this problem right now.

The docs you point to sadly are like providing a hay stack and saying "there's a needle in there". :o

If I request via the REST API the Execution Work Item, I get back some nice XML. In fact I can see the "previous ID" just fine:

executionresult ref="https://server.domain.com:9443/

qm/service/com.ibm.rqm.integration.service.IIntegrationService/
resources/Quality+Manager/
executionresult/urn:com.ibm.rqm:executionresult:561"

However the current item looks like this:

currentexecutionresult 

href="https://server.domain.com:9443/
qm/service/com.ibm.rqm.integration.service.IIntegrationService/resources/
Quality+Manager/executionresult/
slug__Ah-TpQVyEeGMGd5U5A4BCQ"


Can you explain WHY this make sense?

When I use that URL and watch in Fiddler, I see a ton of round trips between the client and the server.

Why couldnt you include the ID for the current item?

Cheers,

Brian

0 votes


Permanent link
Hi Brian,
The URL for the test resource should be considered opaque. That said, the ID can be the internal ID, external ID, or generated ID (see https://jazz.net/wiki/bin/view/Main/RqmApi#id). Both URLs should resolve test executionresult resources when performing a GET request.

0 votes


Permanent link
Hi Brian,
The URL for the test resource should be considered opaque. That said, the <id> can be <internal> (see https://jazz.net/wiki/bin/view/Main/RqmApi#id). Both URLs should resolve test executionresult resources when performing a GET request.


Paul thank you for your reply.

Two questions:

One:

Why does one use an ID

561


and one use a "random" string?

slug__Ah-TpQVyEeGMGd5U5A4BCQ


Two:

Am I reading your resonse correctly in that I can pass the "slug" string in a get request and have the XML data returned like it does when I pass the ID? In other words are both ID types (int vs "slug") morally equivalent?

Cheers,

Brian

0 votes


Permanent link
slug_X IDs are generated external IDs created with POSTing new test resources. You could use either the internal or external IDs to GET a test resource.

0 votes

Your answer

Register or log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: Sep 22 '11, 5:44 p.m.

Question was seen: 8,833 times

Last updated: Sep 22 '11, 5:44 p.m.

Confirmation Cancel Confirm