It's all about the answers!

Ask a question

Multiple ClearQuest databases coupled to one RTC Project Area


Pascal van Kempen (23236) | asked Dec 03 '12, 12:56 p.m.
edited Dec 03 '12, 12:58 p.m.
Multiple ClearQuest databases coupled to one RTC Project Area

Hi

I am trying to import multiple ClearQuest databases into one RTC project Area, and facing some problems, which I tried to describe below:


We have the following scenario in place:

For a UCM component, we had a ClearQuest enabled UCM project running for developing a product. This UCM project used ClearQuest database A.
After releasing the product, we started a new ClearQuest enabled UCM project for maintenance on the product. This UCM project uses ClearQuest database B (same ClearQuest schema, just another DB name)


I imported the first UCM project into a RTC Project Area, following the instructions as worked out in https://jazz.net/library/article/550.

One "special" thing I had to do: as the regular user management is based on LDAP, but the ClearQuest user management is based on a separate environment, I did the mapping for the users based on their e-mail address.

So far, so good. Everything seems to work as designed.

 
Now I want to import the maintenance releases in my RTC project area I used for the 1st import, but I'm facing some issues:
- Importing the UCM_Project went ok
- Importing the activities resulted in "... synchronization status is pending blocked." messages

As the "pending blocked" in most of the cases is caused by or missing the UCM project or missing users, I tried to import the users from database B (it's almost the same set of users, but not entirely).

This resulted in a lot of messages like:
Syncing users CQ:cq.repo.cq-record:users/33554710@PMS_Schema/CVDEV ... synchronization status is UNINITIALIZED

Looking up the details of the synchronization via rules, show unsynchronized, I get empty records; nothing has been imported from ClearQuest (email, fullname and login name are empty)

After some investigation, I found out that 33554710 referred to the DBID of the user in the ClearQuest database.

For most users (a.o. this one), the DBID for the user is the same in both databases, but there are also examples where the DBID is different per database, or even worse: the same DBID number represents different users in the resepctive databases.

Having said this all, I was wondering:
- Is it possible anyhow what I am trying to do (coupling multiple ClearQuest databases to one RTC project area)
- Am I doing something wrong in here?
- If this should be possible: how can I import the users of the 2nd database or resolve my pending blocked issues?

(when I open the pending blocked records in the eclipse client, using show unsynchronized from the rules view, I get a java exception error: 
An internal error occurred during: "Fetching external proxy state for editor".

java.lang.IllegalArgumentException
    at java.net.URI.create(URI.java:842)
    at com.ibm.team.interop.rcp.ui.internal.ExternalProxyWorkingCopy.decodeURIList(ExternalProxyWorkingCopy.java:1239)
    at com.ibm.team.interop.rcp.ui.internal.ExternalProxyWorkingCopy.resolveExternalState(ExternalProxyWorkingCopy.java:823)
    at com.ibm.team.interop.rcp.ui.internal.ExternalProxyWorkingCopy.doRevert(ExternalProxyWorkingCopy.java:672)
    at com.ibm.team.interop.rcp.ui.internal.ExternalProxyWorkingCopy.access$5(ExternalProxyWorkingCopy.java:563)
    at com.ibm.team.interop.rcp.ui.internal.ExternalProxyWorkingCopy$RevertJob.run(ExternalProxyWorkingCopy.java:972)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.net.URISyntaxException: Illegal character in scheme name at index 0: (stateId:
    at java.net.URI$Parser.fail(URI.java:2809)
    at java.net.URI$Parser.checkChars(URI.java:2982)
    at java.net.URI$Parser.checkChar(URI.java:2992)
    at java.net.URI$Parser.parse(URI.java:3008)
    at java.net.URI.<init>(URI.java:578)
    at java.net.URI.create(URI.java:840)
    ... 6 more

eclipse.buildId=unknown
java.fullversion=JRE 1.6.0 IBM J9 2.4 Windows 7 amd64-64 jvmwa6460sr10fp1-20120202_101568 (JIT enabled, AOT enabled)
J9VM - 20120202_101568
JIT  - r9_20111107_21307ifx1
GC   - 20120202_AA
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments:  -product com.ibm.team.concert.product
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -product com.ibm.team.concert.product


Any help, support and/or advise is highly appreciated.

Kind Regards,
Pascal van Kempen


2 answers



permanent link
Yuhong Yin (25123) | answered Dec 04 '12, 11:42 a.m.
JAZZ DEVELOPER
Hello Pascal

First of all, what are the reasons that made you choose to use the CQ->RTC synchronizer, not the CQ->RTC importer to migrate your CQ data to RTC WIs?

Secondly, please note that 1 synchronizer Gateway can only work with 1 CQ user database. The issues you are facing with sync'ing over the database B are results of this known limitation.

You might be able to workaround the limitation by deploying and configuring another synchronizer gateway. But I am not entirely sure whether you will run into other issues due to the single project area in RTC.

Thanks

- Yuhong

Yuhong Yi
Development Manager
ClearCase/RTC, ClearQuest/RTC Connectors & Integrations
Email: yyin@us.ibm.com

permanent link
Pascal van Kempen (23236) | answered Dec 05 '12, 10:30 a.m.
Hi Yuhong

Thanks for the answers.

To start with your first question: I was looking to the possibilities for importing UCM projects into RTC, and found the article I mentioned. I followed the instructions in that document, and that one used the synchronizer.

However, I will take a look at the importer later on to see if it suits our needs. If you have some good manual/article about it, I will be glad to receive it.

I used a synchronizer gateway to synch with the first CQ database. After that was finished, I modified the gateway and synched the 2nd CQ database.
Later this week, I will try to setup 2 gateways in parallel, see if that resolved my issue.

Thanks so far.


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.