Showing results for 
Search instead for 
Did you mean: 

Tasks being fired twice

Former Member
0 Kudos

Hi experts.

My question regards to a workflow over the FIPP object.

This workflow has two parallel branches but only the completion of one is necessary. One branch contains a subworkflow that includes the "post document" task and the other branch contains a wait-event task that waits for the "posted" event of the object, this last branch is useful to prevent the posting of the document from "out" of the WF proccess.

The problem is that when the subworkflow is ended, and the document is posted, the task behind the parallel branches is being fired twice (it's a user's decission task, and the user is receiving it duplicated in the inbox). It seems that both branches complete its execution and continues like two different parallel "threads" with the execution without unifying in only one "thread" of execution.

Is this a performance issue? How can i slow one branch to prevent this behaviour??

Thanks and regards.


Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hello Ismael,

I assume that you have completed the customizing for "Release preliminary documents" or at least you have activated a dummy workflow variant to make these FIPP.Posted-events to come up?!

If you did so, you should have noticed a small activated checkbox when you look at the header of the preliminary document (go to transaction FBV3, enter your, enter the next screen and click on the tab "workflow" or the header icon). The checkbox <b>"release neccessary"</b> or something similar should be activated there.

This will prevent any user to post this document outside of the workflow or at least until the workflow says "document is released for posting".

You release a preliminary document through workflow by calling the object's method


This activates the flag "release" in the header. (The counterpart is FIPP.WorkflowReleaseReset).

Alternatively you can call the


with the flag set "ReleaseIgnore" = 'X'.

This way you don't have to use a secondary branch to observe the FIPP.Posted event anyhow.

Back to your problem: You're right if you suspect some kind of parallel execution. What happends here is: During the event processing the workflow system has a lookup-table to check which workitems/eventitems needs some kind of treatment. The order in which this is executed usually depends on in which order the workitems/eventitems are created. I have made the expirience that the first branch (left-hand side) is created/processed slightly before the next ones). Anyways, there are now two remote function calls committed for processing each of this event. Each of them could get it's own workprocess and therefore execute parallel.

<i>The problem that you have is more like a general workflow design problem.</i>

<b>This is how you solve</b> event observation in parallel tasks:

Container-Element "RELEASED"  type BOOLE-BOOLE = space
                      BRANCH 1/2
          |                               |
1: Eventitem FIPP.Posted       2:a) Release strategy
          |                         (sub workflow)
          |                      b) Get result from sub-
          |                         workflow and set
          |                         RELEASED-Flag
                          | (1/2)
                   Released = 'X'?
                |                    |
              (no)                 (yes)
                |                    |
                |                FIPP.Post

So the strategy is, to avoid having two or more things happening on one workflow instance for an event. You create a branch that supervises the other one. If an event that is supervised is defenitly created there you <i>have to put this outside the branch</i>.

Best regards,


Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Florin.

First of all, thank you for your response.

Yes, I've activated the release strategy for preliminary documents customizing and I is completely true that the parallel branch waiting for the "Posted Document" event is not neccessary at all, because nobody is going to be allowed to post documents outside of the workflow proccess. I was aware of this but I included that branch to make the WF more robust, or bulletproof if you prefer.

You're solution to the problem is great, I specially appreciate your explanation on why is happening this kind of "parallel threads".

Regarding the design tips, I completely agree with you, is just as simple as avoid having the wait-event task and the launch-event task in active parallel branches at the same time, in fact, I had came to the same solution before your reply. Other solution is to use the "asynchronous" version of the task ("PostAsynchron" method).

Thanks again Florin, ten points to you dude!