Why Synchronize attribute is required post addition of new custom attributes in RTC?
Hi,
We are going to add a custom attribute of type Multi-select in Project Area. As part of procedure post configuring the attribute in presentation we need to synchronize this attribute for the existing workitems. We are facing a challenge as we have close to 400000 workitems for which we need to synchronize new attribute. We have written a java client using RTC client APIs to synchronize this but that also takes time.
We want to understand what will happen if we configure the new custom field in Editor presentation and do the synchronize attribute activity over a span of time say 1 week or 10 days as we have 4 million workitems to synchronize.
Will that break anything?
Thanks,
Accepted answer
Disclaimer, this is a forum and not support.
My take on this is as follows:
- When a new attribute is introduced, this attribute is only added to a work item when it is created after the attribute has been defined, or if the attribute gets set for the first time manually or by the UI.
- All work items that have been created before the work item attribute was newly defined do not have that attribute and no value for it.
- I think work item queries using the attribute will not find work items that do not have the attribute. Reporting the same. The editor presentations will show N/A for the attribute and you might or might not be able to select a value.
- Synchronize attributes checks each item, if it hasAttribute() for the new attribute and then creates the attribute (similar to (com.ibm.team.workitem.common.model.IWorkItem.addCustomAttribute(IAttribute)?) for the new attribute.
- There are likely multiple ways to implement the synchronize. https://rsjazz.wordpress.com/2012/11/19/using-an-expression-to-synchronize-attributes-for-work-items-of-a-specific-type/ shows one way of doing it using updateWorkItemType.
- I am not sure if there would be anything that breaks, but I assume that in the areas I mention above you might get unexpected results.
public final static String SKIP_MAIL = "com.ibm.team.workitem.common.internal.skipMail"; //$NON-NLS-1$
You can add this to the save work item to suppress mail notification for the call.
Just my 2 cents.
Comments
Hi Ralph,
Thanks for you quick reply. So only the workitem quering based on the custom attribute will be consistent as all workitems would not have this attribute. So even if I synchronize the attributes over a span of time it wont create any problem other than querying right?
I have written the client using the same link you mentioned above.
I believe so, the synchronize in the UI is meant to do exactly that. Please consider to use
workingCopy.getAdditionalSaveParameters().add(IAdditionalSaveParameters.SKIP_MAIL);
To suppress the e-mail notifications. This is something to consider for all bulk operations using the JavaAPI.
It might be a good idea to throttle down the load of this by pausing every now and then and keeping an eye on the monitoring, just to be sure.
Ok Thank you very much. I plan to do this activity over weekend when the user activity is minimum. Also I noticed that for synchronizing attributes for 3000 workitmes takes 40 minutes. So we plan to do this activity over a span of time.