Multiple terminating events...

[Michael Pokraka]

I like it, that's really neat! Unfortunately doesn't fit this flow. The tasks are also executed in series as well as parallel, as well as forks within forks. All in all this object could route to over 100 people.
Actually, thinking about your suggestions made me realize that this is nearly impossible. I can identify the originating workflow node the terminating event container (and possibly Jocelyn's idea of a check fn), but some nodes also use dynamic parallel execution (e.g. one per country), which becomes really nasty to try to match up terminating events..
 
Back to the drawing board.... but thanks both for your (as usual) excellent suggestions.
Cheers
Mike
 
On Wed, Jun 11, 2003 at 09:51:41AM +0200, Soady, Phil wrote:
> Another Idea....
> the task is changed to listen to a NEW terminating event on a new object
> where the key is extended with this magic piece of info in the container.
>
>
> The parallel fork has an extra branch. The fork is complete when n-1 of n are complete.
>
> This new branch has a loop.
> The loop waits for the original event.
> The next step is to issue the NEW event based on your container variable.
>
> When all original events have been sent, then all new terminating keys
> have been generated and Fork completes.
>
> ....
> Just thinking out loud
>
> cheers
>
>
> Phil Soady
> Senior Consultant
> Business Technologies
> SAP Australia
> * : 0412 213 079
> * : phil.soady at sap.com
>
>
>
>
>
> -----Original Message-----
>> From: Dart, Jocelyn
> Sent: Wednesday, June 11, 2003 9:50 AM
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: Multiple terminating events...
>
>
> Hi Mike,
> Sounds like a rare case where you need a check function module on a terminating event. Regards, Jocelyn Dart.
>
> -----Original Message-----
>> From: Michael Pokraka [mailto:workflow at quirky.me.uk]
> Sent: Wednesday,11 June 2003 3:49 AM
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Multiple terminating events...
>
>
> Hi all,
> We've a minor dilemma we're puzzling over:
>
> A workflow sends tasks based on the same object method to a few people in a fork. A new requirement now needs these to be asynchronous with a terminating event.
>
> The problem: How to tell which terminating event belongs to which task??? User A can start and leave it, user B starts and completes his task - user A gets the terminating event.
>
> There are differences in the container, and what would be ideal is to be able to interrogate the terminating event's container to determine which task it belongs to, but somehow can't find a way around this...
>
> Any ideas would be welcome.
> Cheers
> Mike