Multiple terminating events...

[Breslavets, Sergey]

I see...
on the other hand, if you use terminating events entirely for differentiating
between exceptions, synch step with result variable (kinda like user decision)
might be a good alternative - you'll get all different outcomes you want plus
it's easier on your system...
 
Regards,
Sergey
 
-----Original Message-----
From: Michael Pokraka [mailto:workflow at quirky.me.uk]
Sent: Thursday, June 12, 2003 5:43 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Multiple terminating events...
 
 
Hi Sergey,
That would probably work, but this is turning into a mess from the requirements
aspect. Some time back we went down the route of seperate & parallel tasks
because client decided detailed reports and stats were important.
Now they want more control than a 'data incomplete' warning box, thus the
terminating events (raised by the transaction after the input is validated). A
warning dialog box is not good enough, so this requires loops, so they lose task
duration stats. So now we're waiting for client to inform us which they want
(anyone familiar with the situation?? :-)
We're slowly getting pushed towards the (ugh) scenario of having different
terminating events depending on which task/which fierlds were edited (yuk).
 
Thanks for your input....
 
Cheers
Mike
 
 
On Wed, Jun 11, 2003 at 04:59:44PM -0500, Breslavets, Sergey wrote:
> Mike, here's really simple workaround:
> assign some parameter (Taks ID for example) in the binding for the terminating
> event that would be different for all your tasks, and pass it to the workflow
> container... After event is triggered you'll know which tasks did that by
> analyzing the container variable...
>
> Thanks,
> Sergey
>
> -----Original Message-----
>> From: Michael Pokraka [mailto:workflow at quirky.me.uk]
> Sent: Wednesday, June 11, 2003 4:21 AM
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: Multiple terminating events...
>
>
> 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