Race to the Finish Line

[Alon Raskin]

Not a bad idea but I think the limitations are a show stopper for me (especially no 2).
 
I like your concept of the passer passing itself to the workflow. Its so OO.

Regards,
 
Alon Raskin
e: araskin at 3i-consulting.com <mailto:araskin at 3i-consulting.com> 
p: +1 207 409 4983
f:  +1 806 403 4983
 
http://www.themobileworkplace.com 
The easiest way to integrate SAP with any mobile device

________________________________

From: sap-wug-bounces at mit.edu on behalf of Mike Gambier
Sent: Wed 6/28/2006 13:14
To: sap-wug at mit.edu
Subject: RE: Race to the Finish Line



Alon,

One thing I tried in the past was pass the update to a seperate Workflow
instance that could receiver lots of changes and collate them to perform a
single update in one LUW.

Obvious limitations were:

1. Hard to establish order of updates if the same field is being modified
multiple times
2. How long should the receiver 'wait'?
3. Do the Workflows that are handing over the updates need to know when the
update has happened? (possible event linkage)

In the end I allowed the the 'Passer' Workflow to send itself along with the
actual updates it wanted to perform via the event container so that the
receiver Workflow could, if necessary, raise an event on the Passer Workflow
to say all was well or if an error occurred.

If the Passer Workflow didn't care to know eiether way it didn't pass itself
in the container.

MGT

>From: "LENAHAN Kari -TSDC" <kari.lenahan at torsdc.ca>
>Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>Subject: RE: Race to the Finish Line
>Date: Wed, 28 Jun 2006 12:11:38 -0400
>
>Maybe limit trigger event with a check function module; for example
>check the tables/logs to see if a workflow was already triggered for the
>same object/key within a specific timeframe.
>
>Please let me know if this suggestion is way off base.  I am workflow
>admin/support only, and do not do any programming.
>
>Thanks.
>
>   _____
>
>From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
>Of Alon Raskin
>Sent: Wednesday, June 28, 2006 11:54 AM
>To: SAP Workflow Users' Group
>Subject: Race to the Finish Line
>
>
>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


_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20060629/37ecb88c/attachment.htm