In order to know that a work item and a CQ record are "in sync", a complete incoming/outgoing (or outgoing/incoming) cycle is needed, because the act of saving a work item or CQ record can cause further changes (e.g. from RTC process rules or CQ hooks). So the normal mode of operation for the synchronizer is to have outgoing synchronization enabled. Is there some reason why you have turned it off? This means that none of the changes made to work items, whether done by users or done as side effects of incoming synchronization from CQ, are being applied to your CQ records. So your CQ records are not reflecting the state of your RTC work items. Is that what you want?

We synchronized CQ WorkItems to RTC without error.

However, the Synchronization Status shows that we have Unsynchronized Pending outgoing, WorkItems, even though "Disable automatic outgoing synchronization" is checked in the External Repository Connection Properties.

Each time we update a CQ WorkItem, the synchronizer runs, and yet another Unsynchronized Pending outgoing WorkItem is logged in the Synchronization Status.

If we open one of these Unsynchronized records and click Retry Outgoing Synchronization, the Unsynchronized record disappears.

We can't deploy CQ->RTC synchronization to hundreds of users when hundreds of Unsynchronized Pending outgoing records will be logged on the first sync, and another one logged for each CQ change.

Please advise.

If you only want changes flowing in from CQ to RTC, then that should be reflected in your synchronization rules. For each property, you can indicate in which direction you want changes to flow. I'm guessing you have them set to both directions now. Basically, your configuration is an an inconsistent state, since your synchronization rules (I believe) are specifying bidirectional synchronization, but you've turned off one of those directions. So the system provides warnings of that inconsistency.

I'm also not sure what you mean by "logging" of the pending outgoing state. I don't think there is any logging going on. You can view the state of connected items in the Synchronization Status view; is that what you're referring to?

John

In order to know that a work item and a CQ record are "in sync", a complete incoming/outgoing (or outgoing/incoming) cycle is needed, because the act of saving a work item or CQ record can cause further changes (e.g. from RTC process rules or CQ hooks). So the normal mode of operation for the synchronizer is to have outgoing synchronization enabled. Is there some reason why you have turned it off? This means that none of the changes made to work items, whether done by users or done as side effects of incoming synchronization from CQ, are being applied to your CQ records. So your CQ records are not reflecting the state of your RTC work items. Is that what you want?

We synchronized CQ WorkItems to RTC without error.

However, the Synchronization Status shows that we have Unsynchronized Pending outgoing, WorkItems, even though "Disable automatic outgoing synchronization" is checked in the External Repository Connection Properties.

Each time we update a CQ WorkItem, the synchronizer runs, and yet another Unsynchronized Pending outgoing WorkItem is logged in the Synchronization Status.

If we open one of these Unsynchronized records and click Retry Outgoing Synchronization, the Unsynchronized record disappears.

We can't deploy CQ->RTC synchronization to hundreds of users when hundreds of Unsynchronized Pending outgoing records will be logged on the first sync, and another one logged for each CQ change.

Please advise.

Yes, we want outgoing synchronization disabled. We don't want RTC users changing CQ records. We are providing a read-only view of defects in CQ so that RTC users can link to them when planning.. This is one phase of a transition to supply all of our custom CQ function in RTC to our > 20,000 users.

Are you saying that "Disable automatic outgoing synchronization" doesn't work? If so, please open a defect on our behalf.

We need to deploy this soon without these additional Unsynchronized Pending outgoing WorkItem logs each time a CQ defect is synchronized.

Note that when synchronization rules are configured for incoming synchronization only, you would still need to enable outgoing synchronization. The synchronization process wouldn't send any changes to CQ, but it needs to run in order to see that the synchronization rules specify that no changes are to be synced out, and therefore the items should be considered "in sync", according to how the rules are specified.

Note also that there are going to be limits to one-way synchronization, since the CQ records and the RTC work items will be "drifting apart", and at some point it may not be possible to apply changes from CQ, because they won't make sense. For example, since work item state transitions are not being sent to CQ, then CQ records and work items can be in different states. Then, if a state transition occurs in CQ, it may fail to be applied to a work item, because that transition would be invalid, given the state of the work item.

If you only want changes flowing in from CQ to RTC, then that should be reflected in your synchronization rules. For each property, you can indicate in which direction you want changes to flow. I'm guessing you have them set to both directions now. Basically, your configuration is an an inconsistent state, since your synchronization rules (I believe) are specifying bidirectional synchronization, but you've turned off one of those directions. So the system provides warnings of that inconsistency.

I'm also not sure what you mean by "logging" of the pending outgoing state. I don't think there is any logging going on. You can view the state of connected items in the Synchronization Status view; is that what you're referring to?

John

In order to know that a work item and a CQ record are "in sync", a complete incoming/outgoing (or outgoing/incoming) cycle is needed, because the act of saving a work item or CQ record can cause further changes (e.g. from RTC process rules or CQ hooks). So the normal mode of operation for the synchronizer is to have outgoing synchronization enabled. Is there some reason why you have turned it off? This means that none of the changes made to work items, whether done by users or done as side effects of incoming synchronization from CQ, are being applied to your CQ records. So your CQ records are not reflecting the state of your RTC work items. Is that what you want?

We synchronized CQ WorkItems to RTC without error.

However, the Synchronization Status shows that we have Unsynchronized Pending outgoing, WorkItems, even though "Disable automatic outgoing synchronization" is checked in the External Repository Connection Properties.

Each time we update a CQ WorkItem, the synchronizer runs, and yet another Unsynchronized Pending outgoing WorkItem is logged in the Synchronization Status.

If we open one of these Unsynchronized records and click Retry Outgoing Synchronization, the Unsynchronized record disappears.

We can't deploy CQ->RTC synchronization to hundreds of users when hundreds of Unsynchronized Pending outgoing records will be logged on the first sync, and another one logged for each CQ change.

Please advise.

Yes, we want outgoing synchronization disabled. We don't want RTC users changing CQ records. We are providing a read-only view of defects in CQ so that RTC users can link to them when planning.. This is one phase of a transition to supply all of our custom CQ function in RTC to our > 20,000 users.

Are you saying that "Disable automatic outgoing synchronization" doesn't work? If so, please open a defect on our behalf.

We need to deploy this soon without these additional Unsynchronized Pending outgoing WorkItem logs each time a CQ defect is synchronized.

As I noted above, you need to enable outgoing synchronization so that the system evaluates your synchronization rules, discovers that no outgoing changes are wanted, and then transitions the synchronization status into the OK state. The ability to disable outgoing synchronization is just for temporarily shutting it down when there would be a problem communicating with the external system (e.g. the CQ connector gateway is shut down for maintenance).

Also, as I tried to explain, there is no logging of messages. A synchronization status object is maintained for each work item that is connected to a CQ record. The object can be in one of several states, like "OK", or "Pending Outgoing", or "Conflict". When you ask to see unsynchronized items, you are just querying for items whose state is not equal to "OK". Additional storage isn't being used when the state is not OK; that just makes such objects show up in the query results.

There seems to be a problem with your post editor, or I don't understand how to use it. I think the use of arrow symbols was the problem. I'll try again.

Each of our fields has a synchronization rule that is set to incoming only, CQ to RTC. I neglected to mention that in my first post.

When I select "Show Unsynchronized" on a synchronization rule, the Synchronization Status shows 40 Pending outgoing status messages, one for each new or changed CQ record. If I open one of these and click Retry Outgoing Synchronization, it appears to work, i.e., the status message disappears.

When we deploy the CQ to RTC synchronization to hundreds of users, hundreds if not thousands of Unsynchronized Pending outgoing status messages will be logged on the first sync, and another status message logged for each new or changed CQ record.

These status messages will soon become a storage problem for us and our users, as well as confuse any users that see the Unsynchronized Pending outgoing status messages.

If you can tell me how to attach a screen cap, I can show you the problem.

Please open a defect on our behalf.
Thanks, Denise