CQConnector sync rule names and referencing
Using the CQ Connector, we have the situation where one sync rule is referencing a field in another sync rule (using the Connect Field to Custom Attribute Transformer). This has been working great until now when we are connecting 3 or 4 projects in RTC potentially to different gateways. The sync rules must have unique names, so I have modified the sync rule names and updated the corresponding reference. However now I am getting blocked synchronization because it seems that new records are trying to reference the wrong sync rule (a sync rule in a different project with a different gateway).
I may have set something up wrong or need to clean out old data, but I believe this situation should be supported. Can you give me more insight on how sync rules are uniquely identified and referenced? I know how to view the synchronization status, but how can I find out exactly what sync rules are being referenced? Thanks for your help. Kyle Christianson IBM STG Rational Solutions Team |
7 answers
A couple of things...
Sync rule names should be unique within a Jazz repository. With the exception of the user sync rule, which is treated as a global sync rule, all other sync rules within a project area should only reference sync rules in the same project area. We only support the configuration where a CQ gateway is connected to one CQ user database and can sync those CQ records to one or more Jazz project areas across one or more Jazz servers, but the CQ record can only sync to one Jazz project area within the same Jazz server. |
|
Ok great, we should be following all those rules - or at least trying to...
I have given each project its own uniquely named sync rules and explicitly referenced only sync rules in the same project. But it still seems like some of the references are not getting resolved to the correct sync rules. I'll try to describe an example: Project 1 (connected to Gateway 1) syncRule_A1 syncRule_B1 Project 2 (connected to Gateway 2) syncRule_A2 syncRule_B2 The projects are in the same repository but connected to two different gateways (different CQ databases). syncRule_Ax references syncRule_Bx. I set up Project 1 first and everything was working. Then I shutdown Gateway 1 and set up Project 2. When I run the synctool, I get records in syncRule_A2 blocked by syncRule_B1 saying connection refused (because Gateway 1 is shutdown, but it really should be referencing Gateway 2). When I start Gateway 1, the connection refused message goes away which doesn't make sense because Project 2 shouldn't have anything to do with Gateway 1. Have you seen behavior like this before? How can I go about debugging the situation? |
|
One other thing that I should have mentioned regarding supported configuration is that a Jazz server can communicate with only one CQ gateway. So your scenario is not supported.
|
|
Really? This is essential for us, why would it not be supported? Each project has its own sync rules and its own external repository connection so why couldn't different projects connect to different gateways?
|
|
A Jazz item - work item, category, contributor can only be linked to one external object. Even if you're syncing work items from two different project areas to two different CQ user databases, it is likely that the same Jazz contributor will need to be synced to each database, so that would violate the constraint. There is also a problem with the external manager talking to two different gateways.
|
|
Okay, well we are only doing one way synchronization (from CQ to RTC), and we are not connecting to contributors at all. If this is the case, can we have multiple gateways connected to the same Jazz repository?
|
|
Unfortunately, I can't give you the green light because it is an untested and unsupported configuration and is known to have issues.
The problem you reported earlier with respect to the synctool could be an example of something that won't work in this configuration because it may be referencing the wrong gateway. |
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.