Fork behaviour question

Wed Oct 2 09:11:48 EDT 2002

Hi Jocelyn,
Thanks you for your informative response (and Tomasz). I couldn't agree with
you more for most of it (and yes I know the causes of the errors). Though
I'm currently stuck with something akin to waiting for an oil tanker to do a
U-turn as the error resolution is not that simple.

The fork in question is a standard 'wait for event' which catches any
activity that happens outside the workflow. If anything doesn't go according
to plan, the users go in via different userid's / transactions or whatever
(scenarios are numerous, hence the oil tanker analogy).

I was curious if this is a 'standard practice' solution, whether a fork is
intended (from a theoretical point of view) to handle an error situation.
Though I'd by now be inclined to agree with you that it shouldn't proceed if
there is an error in the other branch.

Thanks
Michael

-----Original Message-----
From: Dart, Jocelyn [mailto:jocelyn.dart at sap.com]
Sent: 02 October 2002 12:33
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Fork behaviour question

Hi Michael,
I agree with Tomasz - errors are errors and should either be resolved
or you redesign your workflow to explicitly handle the errors in a
less disruptive way.

My usual approach for the first iteration of a new workflow is to
let severe but unlikely errors such as updates failing be handled
by going into error status and being picked up by the error monitoring
job SWWERRE.  More common errors related to neglected or tardy data
maintenance I try to handle explicitly in a less disruptive way, e.g.
no agent found or send-mail failure due to bad/missing email addresses.

There are a number of ways of handling these:
e.g. using secondary priorities in responsibilty rules to pick up a
default agent, if no agent found in a function module based rule
making the workflow administrator the default agent, checking if the
email address is valid before sending a mail and sending the message
to someone to correct the email address or sending it to their SAP inbox
instead.

What I wouldn't do is ignore errors - workflow is about improving your
business processes - not about perpetuating poor behaviours.  If these
other paths are in your fork they should be there as a necessary part
of your business process.

If you are using a standard SAP workflow template then these other
paths are also there for a purpose.

Perhaps what really needs to happen is a little diagnosis to find out
what is causing these errors (if you don't already know) and a discussion
with your business process owner and any other affected parties to decide
on the best way to prevent them from a business perspective.

Regards,
        Jocelyn Dart
Consultant (SRM, EBP, Workflow)
and co-author of the book
"Practical Workflow for SAP"
SAP Australia
email: jocelyn.dart at sap.com
phone: +61 412 390 267
fax:   +61 2 9935 4880

-----Original Message-----
From: Zmudzin,Tomasz,VEVEY,GL-DS/DM [mailto:Tomasz.Zmudzin at nestle.com]
Sent: Wednesday, 2 October 2002 7:18 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Fork behaviour question

Michael,

I'm making this up right now -- but I guess that's design. I would rather
assume that errors are real errors if they get reported to workflow, so they
should be taken care of, not forgotten. And if we accept them to happen, why
do we bother reporting them to workflow?

As a quick work-around: you could also explicitly model the behavior of the
branch that fails to handle these cases appropriately.

It's again a matter of personal taste & modeling style.

Kind regards,
Tomasz

-----Original Message-----
From: Pokraka, Michael [mailto:michael.pokraka at kcc.com]
Sent: Wednesday,2. October 2002 10:54
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Fork behaviour question

Greetings,
I've noticed the following annoying behaviour:

The workflow has a fork: 2 parallel & 1 necessary branch.
In the standard scenario, one branch completes, which causes the other to
cancel and life goes on.

However: If branch one has an error and branch two completes, nothing
further will happen until a manual restart. Its this the standard behaviour
as it's probably undesirable in a few (most?) scenarios I can think of
offhand - we don't care about errors as long as the necessary branches are
fulfilled.

Effectively this means I have to model redundant 'delete the other branch'
steps within forks to make sure things get done.

Is this by design or a bug?

Cheers
Michael

----------------------------------------------------------------------------
--
This e-mail is intended for the use of the addressee(s) only and may contain
privileged, confidential, or proprietary information that is exempt from
disclosure under law.  If you have received this message in error, please
inform us promptly by reply e-mail, then delete the e-mail and destroy any
printed copy.   Thank you.

 ===========================================================================
==

------------------------------------------------------------------------------
This e-mail is intended for the use of the addressee(s) only and may contain privileged, confidential, or proprietary information that is exempt from disclosure under law.  If you have received this message in error, please inform us promptly by reply e-mail, then delete the e-mail and destroy any printed copy.   Thank you.

 =============================================================================