Avoid Participant Propagation
WorkItem3(fathers father)
|--WorkItem2 (father)
|--WorkItem1
We created an Operation Participant that when the user modifies an attribute in WorkItem1, it updates this value in the fathers WorkItem (WorkItem2).
The trouble we are finding is that when the value in WorkItem2 is automatically updated and saved by the Operation Advisor, another instance of the Operation Participant is triggered and tries to update the WorkItem3. Normal behavior, but not desired one: we need only one level of propagation.
We cant find the way of detecting who triggered the Save Operation, whether the user, or the "workItemServer.saveWorkItem2()" operation in the Participant.
Any idea about how to tackle it??
Appreciate any comment.
Thanks
Noel.
Accepted answer
First of all, thanks a lot for your answer.
I actually got to solve the problem by passing a flag between the participants. I found it the clearest way to perform simple communication between advisable operations (advisor/participants).
Works as follows:
Set the flag in the save operation of WorkItem 1:
>additionalSaveParameters.add(MY_FLAG);
>saveWorkItem3(workItem, references, workflowAction, additionalSaveParameters)
Receive the flag in the excution of the operation aprticipant in WorkItem 2:
>ISaveParameter saveParam = (ISaveParameter) operation.getOperationData();
>if(!saveParam.getAdditionalSaveParameters().contains(MY_FLAG){
//Execute propagation in WorkItem2
}
Hope this can help others.
NOEL.
2 other answers
Comments
Raffaele, if you are blocked by other advisors, you should fix the configuration for your role. Also the behavior is orchestrated and they are run in the order top to bottom. You have to satisfy all configured advisors, because that is the rule. They will be called by the save in a participant, but because they are advisors you should have no issue when saving the same work item. If you create work items in participants, you simply have to provide the data that is asked for.
Note, don't modify the triggering element in an advisor.
Hi Ralph, first of all thanks for your fast reply. I admit that after a workitem save, attributes status must remain coherent with respect to advisors, but in the case of both readonly attribute for type and state and readonly by condition this might be useful to permit the attribute to be written by the plugin but not modificable by the user.
Hi Rafaele,
I am not aware of hide for condition unfortunately. I don't think we have it. Please feel free to create an enhancement request.
I have only written into read only attributes so far with calculated values, as far as i can remember. If you can't write into a read only attribute using the API, how is data supposed to get in there anyway? If it is an issue of the state, change them before entering the state.
Another thought is to make the attribute read/write and only the presentation read only. Again, I haven't tried this with the API.
I'm using RTC 401, there are some attributes that become read only only if another wi is linked to a specific link type in the other case the same attributes are not readonly and mandatory (the latter scenatio permit the user to write the attribute). In the former case we would "inherit" values from the linked workitem (and remain "synchronized") but any user modification must be denied. (i know that a participant solve the issue, but the customer won't renunce to readonlyness).