Best way to check for bad links via the REST API?

Mike Shkolnik (965●7●160●143) | asked Mar 21 '14, 2:04 p.m.

I am writing an app to check the entire repository for bad links via the REST API. Unfortunately, the current method is:

https://SERVER:9443/jazz/oslc/workitems/WORKITEMID/rtc_cm:com.ibm.team.workitem.linktype.parentworkitem.children.xml

and look for error "CRJAZ0215E" in the result.

For EVERY work item. In addition, I have to do this for each of the following link types:
.parentworkitem.children
.parentworkitem.parent
.relatedworkitem.related
.textualReference.textuallyReferenced
.relatedartifact.relatedArtifact
.attachment.attachment
.copiedworkitem.copies
.copiedworkitem.copiedFrom
.duplicateworkitem.duplicates
.duplicateworkitem.duplicateOf
.blocksworkitem.blocks
.blocksworkitem.dependsOn

That's 12 queries each for 50,000 work items. Is there a faster way to do this via the REST API?

3 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

sam detweiler (12.5k●6●189●201) | answered Mar 21 '14, 4:12 p.m.

I'm not sure there is a faster way AT ALL..

I certainly wouldn't do this via REST anyhow.

write a query, all workitems that have links (of types if you care),

fetch the query results, get all their links, and check the ends..but you will have to check each one, one at a time.

why would a link be bad? only the ones added by users in the comments/description should be subject to error)

but queries are by project, not repository wide.

Comments

Mike Shkolnik commented Mar 21 '14, 4:19 p.m.

That would reduce the number of links I need to check, but it would not by itself result in a list of work items containing bad links. I would need to export the query results and then have my program check that reduced list of work items. That could cut the time in half, but I'd still be using the same method to check the links. I might do that though if this takes excessively long, as it likely will.

Mike Shkolnik commented Mar 21 '14, 4:21 p.m.

Bad links are sometimes created when deleting work items. Sometimes a link to a deleted work item remains. I have not been able to track down the exact cause and it is rare, but it does happen. Bad links can cause a variety of issues.

sam detweiler commented Mar 21 '14, 4:56 p.m.

understood.. thus the suggestion never to delete workitems..

I would do this all in Java.. I don't use the REST apis.

we wrote a utility to copy projects from one server to another, and did some extensive work on reworking all the links with the right new targets. fixup all the comments, description, attachments, approvals, users, workitem references, u name it.

I think we have hashtables of hashtables of hashtables at one point.

we drive everything off the query results.

Mike Shkolnik commented Mar 21 '14, 7:38 p.m.

I don't know Java, thus no Java API for me. I am using Delphi. :)

I have the app working. It's very slow. The good news is I don't have to run it often, just after after I do a bulk delete. We end up with way too many bogus work items not to delete them.

permanent link

Mike Shkolnik (965●7●160●143) | answered Mar 26 '14, 5:40 p.m.
edited Mar 26 '14, 7:51 p.m.

I have completed my app for link checking in RTC. If anyone else is suffering from bad link issues (or thinks they might be or wants to make sure they aren't), let me know and I will send you my app. The app does not do any writing to RTC, only reading. You will still need to edit the work items in 4.0.6 or later to remove the bad links.

permanent link

Mike Shkolnik (965●7●160●143) | answered Mar 31 '14, 6:11 p.m.

I found a MUCH faster way of checking for bad links.

First, run this REST API command for each work item:

https://SERVER:PORT/jazz/service/com.ibm.team.workitem.common.internal.rest.IWorkItemRestService/workItemDTO2?id=WORKITEMID&includeAttributes=false&includeLinks=true&includeApprovals=false&includeHistory=false

Then parse the results.
<linkTypes></linkTypes> contains each link type
<displayName></displayName> within each link type is the name of the link type, such as "Parent".
multiple <linkDTOs></linkDTOs> within each link type are your individual links.
<comment></comment> within each linkDTOs is your link name. The link name will be different if the link is bad.

For example:
Good Link: "Epic 24766: Field length change LDAP_ID"
Bad Link: "24766: Field length change LDAP_ID"

The type of work item of the bad link is missing. You'll need to ignore some types of link types that are not work items, such as "Attachments" and "Included in Builds".

I have switched my application to use the new method. Also, the old method would not list the number of bad links of a particular type.

By the way, you would not believe the number of bad "Mentions" and "Mentioned By" links that you probably all have!

Comments

Mike Shkolnik commented Apr 01 '14, 1:26 p.m. | edited Apr 01 '14, 1:27 p.m.

Well, some caveats with the simpler method. The work item type does not appear with the following work item link types:

Mentions / Mentioned By
Contributes To / Tracks
Affects Plan Item / Affected by Defect

I can see no way of differentiating between a good link and a bad link for those link types using this method. Since the Mentions and Mentioned By links are the most prevalent of bad links, this is a problem.

Mike Shkolnik commented Apr 01 '14, 5:48 p.m.

Unless I find a better method, I am using a hybrid approach. I make an API call for the whole list of links and then if a Modified By or a Modifies is found, it checks the textReference link of that work item as well. Thus the resulting excel export might look something like this:

"Mentions" has a "?" on Qty since the result of the API call is the same whether there are 2 or 10 bad textReference links.

It's all about the answers!

Related questions

Best way to check for bad links via the REST API?

3 answers

Your answer