It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×4,321
×3,951
×1,220

question asked: Jul 04 '13, 4:09 a.m.
question was seen: 4,399 times
last updated: Jul 05 '13, 6:50 p.m.

Related questions

How to know the rrc server owningApplicationKey_REST API related

0
Qing Qing Chen (1●1●1) | asked Jul 04 '13, 4:09 a.m.
I am writing a Rest API tool to retrieve all projects on the clm server.

When comes to RRC, it failed.

How can I know the owingApplicationKey for a specific RRC server automatically?

It seems that the RRC Rest API depends on the JTS server, when given a RRC server address, how I can know its JTS server address?

 

2 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Fabian Lomeli (221●3) | answered Jul 04 '13, 11:55 a.m.
JAZZ DEVELOPER
Hi Qing,
If you want to know the RM active projects, you might want to use:
GET https://<server>:<port>/rm/discovery/RMCatalog?private=true&accept=*

Not sure about the JTS but if you look at the rootservices of your RM application, you might get what you need about how to know what is the url for the JTS service:
GET https://<server>:<port>/rm/rootservices

Hope that helps
Comments
Bas Bekker commented Jul 04 '13, 12:31 p.m.
JAZZ DEVELOPER

Yes, good point Fabian, you can get the JTS url by doing a get on /rm/rootservices

0
permanent link
Bas Bekker (1.4k●4) | answered Jul 04 '13, 11:55 a.m.
JAZZ DEVELOPER
How are you trying to retrieve the RRC projects, or in other words, what API are you using? The only public REST API is the OSLC API, which you probably are aware of. If not, here can find the tutorial: OSLC Workshop

And yes, RRC uses JTS for storing its data, and that is configured during CLM setup. Both the JTS address and the RRC owning application key is not explicitly exposed outside the RRC application.
Comments
Qing Qing Chen commented Jul 04 '13, 10:29 p.m.

Hi Bas,
Thanks for your reply.

The background is that I am writing a Perl script to get the history information for all projects on a CLM server.
 
I tried to get the active project information by this way,
$server/service/com.ibm.team.process.internal.service.web.IProcessWebUIService/projectAreasPaged?hideArchivedProjects=true&owningApplicationKey=JTS-Sentinel-Id&pageNum=0&pageSize=1000

The $server can be RTC, RQM,RRC root service like  https://<server>:<port>/jazz,https://<server>:<port>/qm,https://<server>:<port>/dm

And this will return me a json format dataset, and I can process to get each project ID, and project name.




Qing Qing Chen commented Jul 04 '13, 10:29 p.m.


But when comes to RRC, I fount out that the RRC can not work like this way. The REST API for RRC to get the project list is,

$server/service/com.ibm.team.process.internal.service.web.IProcessWebUIService/projectAreasPaged?hideArchivedProjects=true&owningApplicationKey=8815b0584&pageNum=0
The server is not the the https://<server>:<port>/rm, must be replaced with its jts root service https://<server>:<port>/jts.
So that is the reason I want to find out the way to get the jts root service for a rrc server and the way to figure out the  owningApplicationKey, seems like the owningApplicationKey changes for different RRC server.

Bas Bekker commented Jul 05 '13, 6:49 p.m. | edited Jul 05 '13, 6:50 p.m.
JAZZ DEVELOPER

Yes, the owningApplicationKey is assigned upon RM registering with JTS, and is a different unique ID each time. But like said earlier, RM does not expose this key to the outside. Actually the owningApplicationKey is mainly a JTS internal mechanism and RM does not make use of it.

Your workaround would be using the RM OSLC public API with the GET https://<server>:<port>/rm/discovery/RMCatalog?private=true&accept=*
request to obtain the project areas. Which would be better anyway, as it is the public API we support, while the requests you are showing are non-public API request, that can change over time.

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.