Race to the Finish Line

[Mike Pokraka]

Hi Alon,

If creating a custom table is not an obstacle:
Use a table ZwhateverQUEUE.

The Workflow or trigger function checks this table for the object key. 
If found, add some kind of reference to self and any event parameters 
and stop. If not found, add ref as well, but continue to run.

When a Workflow has finished with the object in question, it checks the 
queue for any other references to the object. If found, trigger a new 
Workflow. Then remove self from queue.

There are obviously a couple of minor synchronization/locking details to 
be sorted (you could even use an event to trigger the next WF). You 
could even use a controller WF to trigger WF's and listen for their 'I'm 
done' events before checking the queue - you get the basic idea.

Cheers,
Mike


Alon Raskin wrote:
> Hi Everyone,
>  
> Problem: I have multiple instances of the same workflow that are triggered at the same time. Of course, the first thing that happens is that each instance tries to update the Business Partner (the same one) and this results in a large number of temporary application errors. This is no big deal but if I have 50 instances of the WF for the same Business Partner then I am going to get a lot of errored workflows.
>  
> Possible (sucky) solution: One obvious thing I can do to alleviate this problem is to put in a random wait step and this will hopefully reduce (or remove) the number of errored workflows. I dont like this solution as I hate putting in random wait steps unless there is a business need for this. 
>  
> Can anyone can suggest a better solution?
>  
> Look forward to your input.
>  
> Alon Raskin
> e: araskin at 3i-consulting.com <mailto:araskin at 3i-consulting.com> 
> p: +1 207 409 4983
> f:  +1 806 403 4983
>  
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>