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.
So if you restrict creation in RTC to other types there would be no outgoing sync.

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

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.

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.

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.