Decision method is coded to remember last option

Tue Jun 18 06:09:57 EDT 2002

Yes, Stephan hard to believe, I know.

The delinquent workitem belonged to an invoice approval workflow =
processed
by an
manager in Ireland, and whose responsibility was resolved by a custom =
table.
The actual recipient was one expense approver in the UK whose names
exclusively=20
appear in the org plan.  The only connection between the two workflows =
is
that=20
both attachment tasks are used in both.=20

I spoke to the UK expense approver and he remembers receiving a second
attachment=20
to complete either at the same time or at the next logon, which he =
again
processed
assuming he had done something wrong the first time.

When I have time, I will try to recreate this using trace functions in
development.

regards

Phil

 =20

-----Original Message-----
From: Becker Stephan (extern)
[mailto:Stephan.Becker.ext at mchw.siemens.de]
Sent: 18 June 2002 09:20
To: SAP-WUG at MITVMA.MIT.EDU
Subject: AW: Decision method is coded to remember last option

Hmm, on the point that explicit confirmation should not be used in
conjunction with a decision task, I beg to differ. SAP are delivering a
workflow engine complete with the workflow builder which is essentially =
a
toolbox for developers. The elements of the toolbox should work if =
sensibly
combined. An end confirmation on a decision that could trigger huge
payments, is sensible use I would argue..=20

SAP are saying that the OSS note 455350 has now replaced note 329227 =
which
originally solved the problem.. 329227 was successfully integration =
tested
in our system, I have just done a quick test of our 4.6C hot package 28 =
test
system that includes note 455350, and it seems to work fine.

On your second point, it is hard to comment without analysing the log =
data,
but I would find it very surprising if two workflows influenced each =
other
that were not designed to.. have a look where else that user could be
derived from..

Hth,
Stephan

-----Urspr=FCngliche Nachricht-----
Von: Kisloff, Philip B [mailto:Philip.Kisloff at astrazeneca.com]
Gesendet: Montag, 17. Juni 2002 17:24
An: SAP-WUG at MITVMA.MIT.EDU
Betreff: Re: Decision method is coded to remember last option

Hi Stephan

The WI display FM was blank, so I checked with SAP. They told me that =
as=20
1. TS8267 does not come with confirm-end-of-processing checked,=20
2. the WF definition does not display this from the task,
3. there is always cancel as the last option anyway
then the explicit completion popup should not be activated with =
decision
tasks.

OK, I do accept that. As a postscript, we just had a very unusual =
incident
directly=20
caused by having the decision task incorrectly configured:

The decision task had a deadline modelled, and a follow-on task =
advancing
with dialog=20
from the rejection outcome forcing the creation of a rejection reason
attachment.=20
A user rejected the decision, but did not explicitly complete the step.
While the result
parameter held the rejection option, deadline monitoring caused the WI =
to
complete. Guess
what happened next ? The follow-on task ended up with a completely =
different
user who had=20
just happened to be processing the same task defined in a completely
different workflow.=20

And I have the logs to prove it.

Phil   =20

=20

-----Original Message-----
From: Becker Stephan (extern)
[mailto:Stephan.Becker.ext at mchw.siemens.de]
Sent: 28 May 2002 17:21
To: SAP-WUG at MITVMA.MIT.EDU
Subject: AW: Decision method is coded to remember last option

Hi there,

I just came across this issue. It comes in two flavours:

When processing a user decision with confirmation, take out the =
function
module in the "WI display" tab of the activity maintenance in the WS, =
then
it'll work all right. The cause for this error is that variables are =
being
passed sloppily when processing user decisions inline in the inbox =
through
the said function module.. SAP say they will not fix this as it is =
seldom=20

When processing methods with result parameters and end confirmations =
(like
any old approval), something similar happens. This is cured by an OSS =
note
(number escapes me at present..).

Hth,
Stephan

-----Urspr=FCngliche Nachricht-----
Von: Kisloff, Philip B [mailto:Philip.Kisloff at astrazeneca.com]
Gesendet: Dienstag, 28. Mai 2002 17:25
An: SAP-WUG at MITVMA.MIT.EDU
Betreff: Decision method is coded to remember last option

Hi all,

We are in 4.6C, and when I cancel processing of a generic user decision =
task
using the confirmation prompt,
the workitem returns to my inbox as expected. What is not expected by =
me is
when I re-process the decision
I can not change the original result - I am presented with the =
confirmation
prompt again.

I checked the code and found the following. I think this was introduced =
as
standard because the object header does
indicate any modifications. I'm sure it never worked like this before, =
does
anyone know what's up? I understand from
colleagues this behaviour has been known about through several patches, =
we
are currently on SAPKB46C28.

*-{
  SWC_GET_ELEMENT CONTAINER   '_RESULT'  WI_RETURN.
  IF SY-SUBRC EQ 0.
    IF NOT WI_RETURN IS INITIAL.
      I_AM_ALREADY_PROCESSED =3D 'X'.
    ENDIF.
  ENDIF.
*-}

Regards

Phil