Header events to complete workflow

[Michael Pokraka]

Hi Jocelyn,
Yes, I suppose it does make sense to have 'normal' completion as part of =
the
flow, and is ironically the same argument as to why I wanted to distingui=
sh
them in the first place.... Doh!
 
I haven't had the opportunity to do the reevaluate bit as escalation is
usually deadline bound, but it does seem a really neat idea.
 
Thanks for your input.
Cheers
Mike
 
Dart, Jocelyn wrote:
> Mike,
> That becomes a bit of a design distinction.
>
> After all, CANCELLED means I aborted out of this workflow, i.e. this
> workflow instance is no longer relevant.
> COMPLETED means I completed the process normally, i.e. I have followed =
the
> modelled path through to the end.
>
> I would not see a problem with using a fork where I want to show events=
 that
> are part of the modelled flowchart, and header terminating events for e=
vents
> that are interruptions to the normal flow.
>
> If you really want to have both in the header events, you could use the
> evaluate pre/post conditions option.  However either way what has happe=
ned
> will show on the workflow log and that should be the first port of call=
 for
> any administrator.
>
> Plus the cancellation stuff is all very nice, but the *really* good opt=
ion
> is to "Reevaluate agents on active work items"... great for adding extr=
a
> approvers in escalation! :-)
> Jocelyn
>
> -----Original Message-----
>> From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of
> Michael Pokraka
> Sent: Thursday,22 July 2004 4:43 AM
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Header events to complete workflow
>
>
> Greetings,
> I'm faced with another niggly little bit in using the new event handlin=
g at
> WF header level on a 4.7/620 system,
>
> I suspect the answer is no go, but....
> Problem: Using header events it seems to only be possible to cancel the
> workflow, not to complete it. This is an important difference, as e.g. =
a
> changed event should leave the WF in a status CANCELLED, but a 'Complet=
ed'
> event (via status management) should leave the WF in a status COMPLETED=
.
>
> For consistency I like to use one or the other; we can have a parallel =
fork
> with a bunch of wait for event branches alongside the flow, or neatly l=
ist
> the events in the header. Otherwise it just becomes a trap for the WF a=
dmin
> to get confused at some point.
> I really like the functionality offered by the header event handling -
> restarting a new WF with the same container comes close to a workflow
> version of sliced bread. So if I want to use that and I also want to ha=
ve an
> 'external completion' event I'm stuck with building a mixed event handl=
ing.
> Or is this the whole intent behing the header event stuff?
>
> Any thoughts?
> Cheers
> Mike
>
>