Fork behaviour question

Tue Oct 8 19:47:31 EDT 2002

Hi Michael,
Using  a wait for event step in a fork is a standard way of ensuring
the workflow will still continue if manual action is taken outside
of workflow for whatever reason.

However that approach doesn't really help you for a severe error scenario.

What I would suggest is explicitly handling the error in your workflow
using an approach ike the following:

1. Make sure the method that is going into error reports back the error
by an exception - I assume it does if the workflow is going into error status.

2. In your step linked to the task/method that goes into error, activate
the Outcome for that error so that you are modelling the error in your workflow.
In the path after your new method-error outcome, it's usual to send at
least a mail or preferably a work item to someone asking them to fix the
problem manually, and then wait for the event that indicates it was fixed.

E.g you could have a send mail step + a  wait for event step,
or just use a work item with a terminating event.

But again explicit handling of errors is something you should only worry
about if you have a continuing issue at your site as you now seem to have,
and ultimately it is a business decision as to whether the error should
be handled by changing the workflow or by changing user behaviour.

Hope that helps.
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: Pokraka, Michael [mailto:michael.pokraka at kcc.com]
Sent: Wednesday, 2 October 2002 11:12 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Fork behaviour question

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.

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