CQ Connector Problem

Did you create your sync rules by running the (new in RTC 2.0) setup wizard, or did you create them by hand? Can you post the XML form of your user sync rule (copied from the Source page of the editor)?

I'm just going through some planning phases and I started configuring the RTC-CQ Connector, the problem I am having right now is that all my primary record type syncs is being blocked by a user sync rule that is Uninitialized.

I can't seem to find a way to remove this sync or stop it, but looking at the user sync status all the fields are blank. Did I miss something bigger during the user sync rule setup ?

-Sean

John thanks for the reply, I have this setup as a bi-directional sync with this setup.

-Sean

<xml>

<syncRule>

    <name>sample02.cq.tr-hk.cq.users</name>

    <externalTypeName>com.ibm.rational.clearquest.users</externalTypeName>

    <syncItemTypeName>Contributor</syncItemTypeName>

    <syncItemTypeNsURI>com.ibm.team.repository</syncItemTypeNsURI>

    <syncItemTypeQualifier></syncItemTypeQualifier>

    <itemManager>com.ibm.team.interop.service.managers.kernel.ContributorManager</itemManager>

    <externalManager>com.ibm.team.interop.service.managers.clearquest.CQExternalManagerForUser</externalManager>

    <maxCycleCount>0</maxCycleCount>

    <syncAllItemStates>false</syncAllItemStates>

    <propertyMappings>

        <propertyMapping>

            <externalPropertyName>email</externalPropertyName>

            <itemPropertyName>EmailAddress</itemPropertyName>

            <incoming>true</incoming>

            <outgoing>true</outgoing>

            <itemIdentifier>false</itemIdentifier>

            <externalIdentifier>false</externalIdentifier>

            <externalModifier>false</externalModifier>

            <requiredItemProperties></requiredItemProperties>

            <requiredExternalProperties></requiredExternalProperties>

        </propertyMapping>

        <propertyMapping>

            <externalPropertyName>login_name</externalPropertyName>

            <itemPropertyName>UserId</itemPropertyName>

            <incoming>true</incoming>

            <outgoing>true</outgoing>

            <itemIdentifier>true</itemIdentifier>

            <externalIdentifier>true</externalIdentifier>

            <externalModifier>false</externalModifier>

            <requiredItemProperties></requiredItemProperties>

            <requiredExternalProperties></requiredExternalProperties>

        </propertyMapping>

        <propertyMapping>

            <externalPropertyName>fullname</externalPropertyName>

            <itemPropertyName>Name</itemPropertyName>

            <incoming>true</incoming>

            <outgoing>true</outgoing>

            <itemIdentifier>false</itemIdentifier>

            <externalIdentifier>false</externalIdentifier>

            <externalModifier>false</externalModifier>

            <requiredItemProperties></requiredItemProperties>

            <requiredExternalProperties></requiredExternalProperties>

        </propertyMapping>

    </propertyMappings>

</syncRule>

Note that outgoing synchronization of RTC users to CQ user records is not supported; CQ user records cannot be created or modified via synchronization. Which direction did the synchronization of your primary record types occur in? (If you look at the synchronization status for one of them, does the text for "Last synchronization attempt" say "Incoming" or "Outgoing"?)

Incoming synchronization (from CQ to RTC) will create RTC user records as necessary, to correspond with referenced CQ user records, but outgoing synchronization will be blocked unless there are existing CQ user records corresponding to RTC user records (and the correspondence is by identical UserId/login_name properties).

John,

That makes more sense, so I really should not of had a two-way sync in the first place.
I have been synchronizing my primary record type in both directions, and it was partly successful.

Now I think I have some cruft laying around in both systems from my various tests and need to do some housekeeping, I saw a post from you elsewhere describing a similar the process, will this work in a generic case as I continue testing?

http://jazz.net/forums/viewtopic.php?t=3938

You cannot change the name of CQ database you sync with unless you basically start from scratch, and delete all synchronization information. You would need to delete the synchronization rules from RTC (you could export them first in order to preserve them and re-import them later), and you would need to delete all CQ records of type JazzConnectorChangeEvents, JazzConnectorQueryInfo, and JazzConnectorSyncHistory. (You would have to create queries that select all records of each of those types, then do bulk delete operations on them.)

-Sean

Yes, to "start over", you need to export the sync rules from RTC, delete them, then import them again, and delete all instances of any record type whose name begins with "JazzConnector" in your CQ database.

John,

That makes more sense, so I really should not of had a two-way sync in the first place.
I have been synchronizing my primary record type in both directions, and it was partly successful.

Now I think I have some cruft laying around in both systems from my various tests and need to do some housekeeping, I saw a post from you elsewhere describing a similar the process, will this work in a generic case as I continue testing?

http://jazz.net/forums/viewtopic.php?t=3938

You cannot change the name of CQ database you sync with unless you basically start from scratch, and delete all synchronization information. You would need to delete the synchronization rules from RTC (you could export them first in order to preserve them and re-import them later), and you would need to delete all CQ records of type JazzConnectorChangeEvents, JazzConnectorQueryInfo, and JazzConnectorSyncHistory. (You would have to create queries that select all records of each of those types, then do bulk delete operations on them.)

-Sean

Figured I would add my issue hear... Been working to get the connector working, and having an issue with getting the syncs to actually complete. I have an incoming sync that is erroring out with the message:

Incoming at 8/5/09 8:40:04 AM CDT
Error occurred:
java.lang.RuntimeException: java.lang.RuntimeException: There was a problem trying to retrieve a CQ object with URI CQ%3Acq.repo.cq-record%3Ausers%2F33554462%407.0.0%2FISSU2.
java.lang.RuntimeException: There was a problem trying to retrieve a CQ object with URI CQ%3Acq.repo.cq-record%3Ausers%2F33554462%407.0.0%2FISSU2.

This is when it is attempting to push the user from CQ over to RTC. I am also getting a bunch of blocked syncs as well on workitems from RTC over to CQ???

Thanks,
Derrick

Do you have a rule for the incoming users ? You need to have atleast one per repo, the problem I was having was that I misconfigured that rule to try and sync from RTC to CQ, where it should only be CQ to RTC.

-Sean

Figured I would add my issue hear... Been working to get the connector working, and having an issue with getting the syncs to actually complete. I have an incoming sync that is erroring out with the message:

Incoming at 8/5/09 8:40:04 AM CDT
Error occurred:
java.lang.RuntimeException: java.lang.RuntimeException: There was a problem trying to retrieve a CQ object with URI CQ%3Acq.repo.cq-record%3Ausers%2F33554462%407.0.0%2FISSU2.
java.lang.RuntimeException: There was a problem trying to retrieve a CQ object with URI CQ%3Acq.repo.cq-record%3Ausers%2F33554462%407.0.0%2FISSU2.

This is when it is attempting to push the user from CQ over to RTC. I am also getting a bunch of blocked syncs as well on workitems from RTC over to CQ???

Thanks,
Derrick

There may be more information in the CQ Gateway log file as to what sort of error it is encountering. Check the cqgateway.log file in the gateway/tomcat/logs directory under the installation directory.

I checked the logfile, and this is the full message from the log file.

05 Aug 2009 09:24:32,421 [http-8081-Processor24] DEBUG com.ibm.rational.interop.level1                     - Retrieving  cq.repo.cq-record:users/33554462@7.0.0/ISSU2 using TeamAPI

05 Aug 2009 09:24:32,906 [http-8081-Processor24] DEBUG com.ibm.rational.interop.level1                     - cq.repo.cq-record:users/33554462@7.0.0/ISSU2 not found using TeamAPI

05 Aug 2009 09:24:32,906 [http-8081-Processor24] DEBUG com.ibm.rational.interop.level2                     - Releasing CQInteropEventHandler-7.0.0/ISSU2-new

05 Aug 2009 09:24:32,906 [http-8081-Processor24] DEBUG com.ibm.rational.interop.level2                     - Closing CQInteropEventHandler-7.0.0/ISSU2-new

05 Aug 2009 09:25:31,812 [CQ Interop Polling] DEBUG com.ibm.rational.interop.level2                     - Using CQInteropEventHandler-7.0.0/ISSU2-CQ Interop Polling

05 Aug 2009 09:25:31,812 [CQ Interop Polling] DEBUG com.ibm.rational.interop.level2                     - Got handler for CQ Interop Polling

05 Aug 2009 09:25:31,812 [CQ Interop Polling] DEBUG com.ibm.rational.interop.level2                     - Releasing CQInteropEventHandler-7.0.0/ISSU2-CQ Interop Polling

Any ideas???

Thanks,
Derrick

In a private conversation with Derrick, I found out that he swapped CQ databases after initially synchronizing with one of them. That invalidates all the links back to CQ records that are stored in RTC, hence the "not found" messages coming from the CQ Connector Gateway.