Multiple terminating events...

[Soady, Phil]

Now the true requirements emerge.
 
How long did logical step x take.
and What was changed....
 
 
Why not keep it simple and record start and end time in the WFLOW as container
variables.  The logical start and end times.
 
This container variables can be passed to WIS via the WIS build user exit.
 
After the step is complete, the next step can read the document/ chg docs
whatever to see what has changed.
 
If not enough has happened, loop back.  Original start variable, not lost
since it is you own container variable.
 
Keep the workflow simple, as control with own variables and a big brother
method after each step...
 
hope it doesn't get too ugly...
Cheers
 
Phil Soady
Senior Consultant
Business Technologies
SAP Australia
* : 0412 213 079
* : phil.soady at sap.com
 
 
 
 
 
-----Original Message-----
From: Michael Pokraka [mailto:workflow at quirky.me.uk]
Sent: Thursday, June 12, 2003 8:43 PM
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