RTC->CQ Outgoing sync caused by creation of record in RTC
![]()
I have been working with the CQ / RTC synchronizer for a while now, and I have always been under the impression that the synchronization is always initiated from the CQ side. However, in a recent deployment of the synchronizer, the team wanted to be able to synchronize the CQ record, with a workitem type in RTC that they also wanted to be able to create manually. So some of these workitems would be created by the synchronizer, and others would be created manually. This worked ok in that the synchronizer does create the items, and it is possible to create them directly in RTC. The problem is, for the ones created in RTC, sometime after they are created, the synchronizer is trying to do an outbound sync based on my synchronization rule. ???? This is failing, and means I have all sorts of synchronization errors listed when I check for them. This I didn't expect, and I don't understand why this is happening. Is there some way to ensure that outgoing synchs aren't attempted for these workitems not created by the synchronizer?
Thanks. |
6 answers
![]()
Ralph Schoon (63.3k●3●36●46)
| answered Jan 19 '11, 12:49 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Chris,
the Synchronizer always targeted to be able to synchronize RTC and CQ records in both directions. Especially if you changed the description or other attributes in RTC many users would want that to be reflected in CQ. Options you have: I think you can remove the work items making problems from synchronization in the error view. I think there is an option or a property in the synchronization rule editor or another view related to synchronizing that disables outgoing synchronization. Typically it is set up to only sync in and out only certain types. If the synchronizations rules where correctly set up for the type you would actually get CQ records for RTC work items created of that type. So if you restrict creation in RTC to other types there would be no outgoing sync. Another thing you could look into is the synchronization direction in the Sync Rules. you could restrict what is synchronized out per attribute. However, if outgoing sync is enabled I would assume that creations in RTC would still be attempted to be brought over to CQ potentially creating an issue due to missing required data. Ralph I have been working with the CQ / RTC synchronizer for a while now, and I have always been under the impression that the synchronization is always initiated from the CQ side. However, in a recent deployment of the synchronizer, the team wanted to be able to synchronize the CQ record, with a workitem type in RTC that they also wanted to be able to create manually. So some of these workitems would be created by the synchronizer, and others would be created manually. This worked ok in that the synchronizer does create the items, and it is possible to create them directly in RTC. The problem is, for the ones created in RTC, sometime after they are created, the synchronizer is trying to do an outbound sync based on my synchronization rule. ???? This is failing, and means I have all sorts of synchronization errors listed when I check for them. This I didn't expect, and I don't understand why this is happening. Is there some way to ensure that outgoing synchs aren't attempted for these workitems not created by the synchronizer? |
![]()
Thanks for the response Ralph. See my comments below.
the Synchronizer always targeted to be able to synchronize RTC and CQ records in both directions. Especially if you changed the description or other attributes in RTC many users would want that to be reflected in CQ. Both directions is fine in general, but I only want that to happen for record pairs initially created in CQ. In other words: Good workflow: (what I want) 1. Create a "Feature" record in CQ. 2. Synchronizer creates the associated EPIC workitem in RTC, including all mapped fields -> attributes. 3. User updates a mapped attribute in the associated EPIC workitem in RTC, and the change is propagated back to the associated field in the linked CQ Feature record. Bad workflow: (what I don't want, but what is happening) 1. User manually creates an EPIC workitem in RTC. 2. The auto outgoing synchronization attempts to synchronize this change with a CQ record (I am not even sure if it is trying to create a new CQ record, or somehow update an existing one) This fails with a sync error. * What I really want here is for the auto outgoing synchronization to only auto sync those records created by the incoming sync from CQ, but I don't know if it is possible to do that. Ideally, a way to qualify outgoing synchronizations from RTC using a query (in the same way that the query is used on the ClearQuest side) would be great. I think you can remove the work items making problems from synchronization in the error view. We can't really remove the work item. It was created because it is needed. If you mean we can use the "Stop Synchronizing" action that is available in the Synchronization Status listing, you are right, that does remove the external connection proxy, however, 60 seconds later it gets recreated by the auto outgoing sync process. If you know of a way to tell RTC to Stop Synchronizing and never try again, I would love to know about it. If there is a way to do that, I could script a solution. I think there is an option or a property in the synchronization rule editor or another view related to synchronizing that disables outgoing synchronization. Yes, there are a couple of places where auto outgoing sync can be disabled, including in the External Repository Connection properties, however, again, that would disable it completely, which isn't what I am looking for. Typically it is set up to only sync in and out only certain types. If the synchronizations rules where correctly set up for the type you would actually get CQ records for RTC work items created of that type. If you are suggesting that I should create a special workitem type and restrict that type to only be created by the synchronizer process, that is a good solution and is what I have always done in the past. However my current customer doesn't want to use a special workitem type. They want to have the synchronized data be put into EPICs, which they also want to be able to created in RTC. :( Another thing you could look into is the synchronization direction in the Sync Rules. you could restrict what is synchronized out per attribute. However, if outgoing sync is enabled I would assume that creations in RTC would still be attempted to be brought over to CQ potentially creating an issue due to missing required data. That doesn't really help me. This is really what is happening right now. The outgoing sync is failing for these workitems created in RTC, so no real records are being created in CQ. I just want to try and stop these outgoing sync errors from showing up so that they don't obfuscate real errors that I need to deal with for "real" synchronizations based on records created in CQ. Thanks, Chris |
![]()
There is no option to only sync out work items that were created by syncing in from CQ. The only other kind of option for filtering the work items that are synced out (besides the type of the work item) is the team area that the work item is associated with. In the sync rule editor, you can select a subset of the team areas in the project area containing the sync rule; that will restrict creation of new CQ records to only those work items associated with the selected team areas. Work items are associated with team areas indirectly, based on the category they are Filed Against and/or the iteration they are Planned For. So if you could arrange that EPIC items connected to CQ records are filed against a category associated with a special "EPICS for CQ" team area, then you might be able to do what you want.
|
![]()
Thanks John. I think that is a good idea, but I believe that the Filed Against category tends to change for the different team areas who would be implementing the EPIC.
I have been thinking about a scripted solution like the following: 1. Turn off auto-sync on the RTC side, 2. Write a script that does the following every 2/3 minutes: a) Get a handle on the IInteropManager object b) Get the listing of proxies associated with the sync rule in question (findProxybySyncRule) c) Iterate through the proxies looking for those that are associated with workitems that were created from the CQ side d) For those proxies associated with CQ side based workitems, force a sync out I am not sure if this will work, but I am probably going to give it a try, unless you think its not worth pursuing. There is no option to only sync out work items that were created by syncing in from CQ. The only other kind of option for filtering the work items that are synced out (besides the type of the work item) is the team area that the work item is associated with. In the sync rule editor, you can select a subset of the team areas in the project area containing the sync rule; that will restrict creation of new CQ records to only those work items associated with the selected team areas. Work items are associated with team areas indirectly, based on the category they are Filed Against and/or the iteration they are Planned For. So if you could arrange that EPIC items connected to CQ records are filed against a category associated with a special "EPICS for CQ" team area, then you might be able to do what you want. |
![]()
I think that would work in principle; you'd basically be replacing the outgoing sync polling task with one that you've implemented. There would be a number of details to work through. It wouldn't be a "script", but a Java application, right? (Or are you thinking of some sort of bridge mechanism between a scripting language and Java?)
Thanks John. I think that is a good idea, but I believe that the Filed Against category tends to change for the different team areas who would be implementing the EPIC. There is no option to only sync out work items that were created by syncing in from CQ. The only other kind of option for filtering the work items that are synced out (besides the type of the work item) is the team area that the work item is associated with. In the sync rule editor, you can select a subset of the team areas in the project area containing the sync rule; that will restrict creation of new CQ records to only those work items associated with the selected team areas. Work items are associated with team areas indirectly, based on the category they are Filed Against and/or the iteration they are Planned For. So if you could arrange that EPIC items connected to CQ records are filed against a category associated with a special "EPICS for CQ" team area, then you might be able to do what you want. |
![]()
Sorry, I use the term script for everything. Yes, it would be a Java application making use of the plainjava apis.
I think that would work in principle; you'd basically be replacing the outgoing sync polling task with one that you've implemented. There would be a number of details to work through. It wouldn't be a "script", but a Java application, right? (Or are you thinking of some sort of bridge mechanism between a scripting language and Java?) Thanks John. I think that is a good idea, but I believe that the Filed Against category tends to change for the different team areas who would be implementing the EPIC. There is no option to only sync out work items that were created by syncing in from CQ. The only other kind of option for filtering the work items that are synced out (besides the type of the work item) is the team area that the work item is associated with. In the sync rule editor, you can select a subset of the team areas in the project area containing the sync rule; that will restrict creation of new CQ records to only those work items associated with the selected team areas. Work items are associated with team areas indirectly, based on the category they are Filed Against and/or the iteration they are Planned For. So if you could arrange that EPIC items connected to CQ records are filed against a category associated with a special "EPICS for CQ" team area, then you might be able to do what you want. |
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.