CQConnector sync records moved in/out of selection query
My team has the CQ Connector set up and we have imported existing CQ records with the synctool. The synchronization is working fine, however we believe there is a severe design flaw with the connector. The problem we are experiencing is that users can create a CQ record outside of our defined sync query. Then if a user modifies the CQ record so it is selected by the sync query, it never gets created in RTC.
The reverse situation is also a severe problem. A user may modify a currently syncing CQ record so it is no longer selected by the query. In this case the connected RTC work item never gets updated and is in an invalid state. We are aware that we could tell our users to create new duplicate CQ Defects which fall into the sync selection criteria, but this is not an acceptable solution. Do you have any solutions/workarounds to this problem? Kyle Christianson IBM STG Rational Solutions Team |
11 answers
Sounds like something is preventing the incoming sync from occurring, because in both situations that you have mentioned, the CQ record should be synced. That is, if a record is initially not selected by the filter query but becomes selected, it should start syncing. And once it starts syncing, it continues to sync, even if the filter query no longer selects it.
Whenever a change occurs to a record that is a candidate for syncing, a change event record is created for it in the JazzConnectorChangeEvents table. You can query this record type to see if there is an entry for the CQ record that is not syncing. A record is removed from this table once it is successfully synced. So an entry in this table means the record has yet to be synced or an attempt was made but there was an error. Also, view the CQ Gateway log or Jazz server log for errors. And in the RTC client, go to the Synchronization Rules view. Select the project area, right-click, and choose the Show All Unsynchronized to see what records are not being synced and the reasons why. We will probably need to take your situation offline. |
|
Hi Lorelei, thanks for the reply.
in both situations that you have mentioned, the CQ record should be synced. That is, if a record is initially not selected by the filter query but becomes selected, it should start syncing. And once it starts syncing, it continues to sync, even if the filter query no longer selects it. This is not what we are observing. When I modify a CQ record so the filter query no longer selects it, I get no synchronization and I do not see an entry in the JazzConnectorChangeEvents table at all. (I do see entries in the JazzConnectorChangeEvents table when modifying other fields) I have checked all the logs and the unsynchronized records and see no problems. Whenever a change occurs to a record that is a candidate for syncing, a change event record is created for it in the JazzConnectorChangeEvents table. So how does a record become a candidate for synching? |
|
This is very bizarre. I tried to recreate your scenario w/ a simple filter query. Modified a CQ defect that was syncing such that it didn't meet the query filter and it continued to be synced. I also modified an existing CQ defect that did not originally satisfy the query such that the change did satisfy the query and the record was synced.
You can try this experiment. Turn off the CQ gateway. Make a change to a CQ defect that was syncing so that it no longer satisfies the query filter. then query the JazzConnectorChangeEvents table to see if an entry for that record is created. Also try that same experiment with an existing CQ defect that does not satisfy the query filter. By any chance are you syncing to more than one RTC project area? Regarding how a CQ record becomes a candidate for syncing, there is hook code that is fired after a CQ record is committed that runs the query filters to see if the record satisifies the query criteria. If it does, then an entry is created in the change events table. If it doesn't satisfy the criteria but has been synched before, ie. an entry for that record exists in the JazzConnectorSyncHistory table, then a change event record is created. |
|
Thanks again for the quick reply!
I have tried your experiment with turning off the CQ gateway and observing the JazzConnectorChangeEvents table. I see entries come appear when I make normal changes to the record, but I do not see entries when making a change that makes the record no longer selected by the filter query. I also do not see entries in the table when modifying an existing CQ record to satisfy the filter query. I am not syncing to more than one RTC project currently, but we would like to in the future. I am wondering if we have an old version of the JazzInterop package applied to CQ. Here is my setup: CQ version 7.1.1.2 with JazzInterop package 1.06 CQ Connector Gateway 2.0.0.2iFix1 What versions are you on? |
|
There is a newer version of the JazzInterop package that was introduced in 2.0.0.2 ifix2 but I don't think that would address the problem that you are experiencing.
What is the feature level of the CQ schema repository that you are using? |
|
|
|
Here's another thing to try that involves modifying the hook code that generates the change event records.
In the CQ Designer, check out the schema and go to Global Scripts -> Perl -> Change History Scripts. Change the line: %ignoreFields = ("history", true); to %ignoreFields = ("history", true, "locked_by", true); Save and check in the schema, and then upgrade the user db. If the script is read-only, enable editing by typing at a command prompt: packageutil enablepackageediting -dbset your_schema_repo_name_goes_here admin_acount admin_password -enable admin_account After the changes have been made, make the script read-only: packageutil enablepackageediting -dbset your_schema_repo_name_goes_here admin_acount admin_password -disable admin_account |
|
Actually, nevermind that hook change. That's for a different fix. I need to do more investigation into this.
|
|
I think I just reproduced this problem, which is unfortunate for me, yet it is progress.
|
|
This is what I have discovered. If you were to modify the CQ record in the CQ Windows client such that the record no longer satisfies the query filter, you will get an action_notification hook error about referencing a users record with a value of 0. That hook is our change history script being executed to determine if the record is a candidate for syncing. So the hook execution fails, a change event is not created, but the CQ record is committed since the hook is a post-commit hook.
If you were to perform the same action in the CQ Eclipse client, the hook execution fails silently, that's why you don't see the change event created. In feature level 7, the data type of the locked_by field was changed from an INT to a reference, yet this value of 0 remains. There is a RATLC bug, RATLC01299305, on this issue. So you have a couple of options. 1). Use feature level 6. 2). Apply the hook change that I had mentioned previously which will ignore the locked_by field. 3). Wait for us to fix it in 3.0 or possibly 2.0.0.2 ifix5. |
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.