It's all about the answers!

Ask a question

Avoid Participant Propagation

Noel Gimeno (1521317) | asked Apr 15 '11, 7:07 a.m.
We have the following WI structure:

WorkItem3(fathers father)
|--WorkItem2 (father)

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.

Accepted answer

permanent link
Noel Gimeno (1521317) | answered Jul 17 '12, 7:06 a.m.
Hi Eduardo. I have just received an update on this question.
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:
>saveWorkItem3(workItem, references, workflowAction, additionalSaveParameters)

Receive the flag in the excution of the operation aprticipant in WorkItem 2:
>ISaveParameter saveParam = (ISaveParameter) operation.getOperationData();
        //Execute propagation in WorkItem2

Hope this can help others.

Ralph Schoon selected this answer as the correct answer

Ralph Schoon commented Jul 17 '12, 7:43 a.m.

Hi Noel, thanks for this great post!

Nicolás Rodríguez commented Jul 31 '12, 4:30 p.m.

Great Solutions!!! thanks!

SEC Servizi commented May 21 '13, 10:38 a.m.

This is what we were looking for.


Noel Gimeno commented May 21 '13, 5:01 p.m.

Really glad it helped you!

2 other answers

permanent link
Eduardo Bello (4401821) | answered Apr 17 '11, 7:48 p.m.
Hi, I had the same problem and tried to get some help here. As I got nothing, I use a simple manual solution: common plug-in+session manager.

Here is some more information:

permanent link
Raffaele Petta (111) | answered Apr 02 '13, 10:30 a.m.
 Hi, I'm facing the same problem but instead of the infinite loop behaviour I'm obtaing a blocking one by several advisors. Is there a way to make a builtin advisor to skip the execution if a postop already run?
I mean there exist a builtin FLAG to skip builtin advisor executions?

Ralph Schoon commented Apr 02 '13, 10:50 a.m.

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.

Raffaele Petta commented Apr 02 '13, 11:14 a.m.

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.

BTW (if there is no possibility to obtain that) is there the possibility to hide an attribute in the presentation if a  conditio(server or js side) macthes? 
Thank you again

Ralph Schoon commented Apr 02 '13, 11:32 a.m. | edited Apr 02 '13, 11:32 a.m.

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.

Raffaele Petta commented Apr 02 '13, 2:43 p.m.

 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).

Regarding the ability of calculated values to write on fields, regardless of readonlyness, did you mean a presentation (always) readonly or state by state one? 

Your answer

Register or to post your answer.