Enqueue Errors - ECC 6.0

Wed Nov 12 09:43:50 EST 2008

Hi Andy,

You can only have one dialog task in one path of a fork.  What we had to
do was to create sub-workflows for all but one of the dialog tasks in
the fork.  That was a big project to go into all workflows and make that
change.

The waiting on events in parallel forks will work....you just cannot
have a dialog task under the wait step.  If you make your dialog task
underneath the event a sub-workflow, then your events will work fine.

SAP was adamant that it was working as designed and would not consider
modifying it.

Regards,

Sue T. Doughty

SAP Workflow Specialist

Old Dominion Freight Line, Inc.

500 Old Dominion Way

Thomasville, NC 27360

Phone:  (336) 822-5189

Toll Free (800 ) 432-6335, ext. 5189

Email:  sue.doughty at odfl.com

________________________________

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Catherall, Andy M
Sent: Wednesday, November 12, 2008 6:36 AM
To: SAP Workflow Users' Group
Subject: RE: Enqueue Errors - ECC 6.0

All

Context

-----------

We have recently started making changes to a workflow in ECC6. The
original design existed in our 4.6c system and has worked for years. As
the SAP instance was upgraded, the workflow remained. We have then
copied this workflow in ECC6, and are developing on the copy.  The
workflow handles parked MM invoices.

Issue

--------

This workflow has a main fork, and two parallel forks. These parallel
forks handle the BUS2081-POSTED and BUS2081-DELETED events. The main
fork allows the user the opportunity to resolve the issues with the
invoice and Post it (if complete) or save it (if still awaiting more
information). There is an 'advance with dialog' step immediately after
the invoice edit step, which raises a pop-up to confirm with the user
that they *did* mean "save", didn't they...?

Of course, if they selected "POST", we are expecting the posted event to
be raised (which it is), and for the other fork of the workflow to kick
in (as it used to do), and for some tidy-up and completion to occur
(which is not happening due to the locked workflow), and hence for our
main fork to be terminated as the workflow ends (but, as it is not
ending, the main fork continues...).

Based on the conversations below, it sounds like there is a fundamental
design paradigm shift - we can't have parallel forks waiting to respond
to event based on the users' actions, because the main fork will have
locked the workflow anyway. I take it this can't also be true for the
'new' header-level event handling??

Given that the discussion below occured several months ago, has the
debate or approach moved on? Is there now an updated view regarding
'best practice' design for this sort of functionality?

Many thanks

Andy

________________________________

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Sue Doughty
Sent: Tuesday 25 March 2008 13:07
To: SAP Workflow Users' Group
Subject: RE: Enqueue Errors - ECC 6.0

We are on ECC 6.0.  I have a new issue with the Enqueue errors.

We have workflows using Webservice to pass around a form via workflow
for approval and processing.  After the form has been processed, I have
a notification fork which sends a workflow (via a sub-workflow) with a
copy of the form that certain departments need to view - it could be one
or up to four sub-workflows.  Also in the fork is a background process
(via a sub-workflow) that checks the TOA01 table (via a method in the
BUS1065 BO) to insure that the image was stored with the employee
record.  The first step waits for 30 seconds and then checks every 10
minutes for 30 minutes before sending a notification to the Workflow
group if it fails to find it.

The problem is that as soon as the sub-workflow for the checking of the
TOA01 table starts, all of the other sub-workflows in the fork will not
continue until that sub-workflow finishes.  I get an error that the work
item number of the main workflow (top level) is locked by user WF-BATCH
(enqueue error).

I thought that as long as I was executing sub-workflows, I would not get
the enqueue errors.  Am I missing something?

Regards,

Sue T. Doughty

SAP Workflow Specialist

Old Dominion Freight Line, Inc.

500 Old Dominion Way

Thomasville, NC 27360

Phone:  (336) 822-5189

Toll Free (800 ) 432-6335, ext. 5189

Email:  sue.doughty at odfl.com

________________________________

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Sue Doughty
Sent: Tuesday, October 23, 2007 10:11 AM
To: SAP Workflow Users' Group
Subject: RE: Enqueue Errors - ECC 6.0

Hi Mike,

I've moved two of the three decisions and the call to PA40 into a sub
workflow and now all three branches of the fork can now be completed.

I replied back to OSS stating that I felt like it was not working
correctly and this is their response.....they will NOT do anything about
it and suggested, as you did, to do sub workflows:

thank for your response as well, and of course your valuable input

is always appreciated. Nevertheless we have now reached a level,

where you put into question the fundamental design / architecture

of the workflow runtime system.

An important feature of the workflow runtime system are so-called

"synchronous process chains" (advance with dialog), i.e. if there

is a sequence of dialog steps to be processed by the same user,

they are executed as one chain without going to the inbox in between.

A pre-requiste for this is the lock on the father workflow during

the entire process chain.

workflow F_______________________________

^ | ^ | ^

| | | | |

task ___W1___| v___W2___| v___W2___|

----------------------------------------------> time

In your case there are two of such process chains, which collide

because they are in parallel branches of a fork.

I talked again to my boss, who is not only development manager

but in this case also the responsible developer. He definitely

sees no room for tolerance here.

On the other side there should be a workaround by embedding the

individual branches into subflows, because only the direct father

and not the top-level workflow is locked. Hope this helps.

Mike, I really appreciate your help in this!!  

Regards, 

Sue T. Doughty 

SAP Workflow Specialist

OLD DOMINION FREIGHT LINE, INC.

500 Old Dominion Way, Thomasville, NC 27360

Toll Free :(800)432-6335, ext.5189 

Phone :(336)822-5189 Fax :(336)822-5149 

sue.doughty at odfl.com

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Mike Pokraka
Sent: Tuesday, October 23, 2007 9:47 AM
To: SAP Workflow Users' Group
Subject: RE: Enqueue Errors - ECC 6.0

OK, as I understand it:

User A in one branch executes a decision and is advanced to the next
step,

which is a transaction.

Before user A completes the txn, user B executes a decision in another

branch followed by another unrelated action. This fails because user A
has

locked the WF.

If I've understood this correctly then I'd call that a big fat bug. I

would suggest replicating this in a test WF in it's simplest form - does

it do the same without the decisions (i.e. just two PA40's in parallel

branches)? What if you use transactions other than PA40 in both
branches?

Simplify as far as possible and send it back to OSS. (and let us know
the

outcome).

Cheers,

Mike

On Tue, October 23, 2007 12:36 pm, Sue Doughty wrote:

> Hi Mike,

> 

> Thanks for your response.

> 

> It is a standard call to PA40.

> 

> Hi Mike,

> 

> Thank you for your response.

> 

> It is a standard call to PA40.

> 

> I agree...a task should NOT lock the TOP level workflow.

> 

> I did what you said and got the PA40 up and then tried to execute

> another branch doing something different.  It still locks the workflow

> at the top level.

> 

> I will try moving the decisions out into the sub workflow and see if

> that changes things.

> 

> Regards,

> Sue T. Doughty

> SAP Workflow Specialist

> OLD DOMINION FREIGHT LINE, INC.

> 500 Old Dominion Way, Thomasville, NC 27360

> Toll Free :(800)432-6335, ext.5189

> Phone :(336)822-5189 Fax :(336)822-5149

> sue.doughty at odfl.com

> -----Original Message-----

> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
Behalf

> Of Mike Pokraka

> Sent: Tuesday, October 23, 2007 4:46 AM

> To: SAP Workflow Users' Group

> Subject: RE: Enqueue Errors - ECC 6.0

> 

> Hi Sue,

> 

> OK, so that changes the picture a little. Regarding subWF, you should

> try

> putting the entire user dialog chain into the subwf - i.e. the
decision

> and the PA40.

> 

> I've had similar probs where a lock would cause a similar error and
the

> error monitoring job would pick it up - as per the OSS response.
However

> I

> am also not convinced this is right. Is this s standard "Call

> transaction

> PA40" type of method or does the code do something strange?

> 

> A task should NOT lock the top level workflow. That defeats the whole

> point of parallel execution. Yes there can problems if you and up with

> two

> branches joining at the same time and racing for the next step but a
WF

> should definitively be able to execute two steps in parallel otherwise

> we

> can all go home. Here's another test: when one user locks PA40, try to

> execute something else in the other branch after the decision - or a

> PA40

> on a different employee - in other words something that works. If that

> also fails then I say it's rubbish design that needs to be fixed.

> 

> Cheers,

> Mike

> 

> 

> On Mon, October 22, 2007 9:10 pm, Sue Doughty wrote:

>> Hi Mike,

>> 

>> I changed the PA40s to subworkflows.

>> 

>> I executed the workflow again and tried to execute the decision tasks

>> (which call the PA40 subworkflow).

>> 

>> It is still giving me an enqueue error on the Decision step at the

>> INSTANCE level if more than one fork is executed at a time.  It seems

>> like it is telling me that only one path of the fork can be executed

> at

>> a time.  If two people try to execute two different paths, it will
get

> a

>> locking error.  It is two difference paths of a fork and two separate

>> decision steps.

>> 

>> This can't be the way it is supposed to work!

>> 

>> Regards,

>> Sue T. Doughty

>> SAP Workflow Specialist

>> OLD DOMINION FREIGHT LINE, INC.

>> 500 Old Dominion Way, Thomasville, NC 27360

>> Toll Free :(800)432-6335, ext.5189

>> Phone :(336)822-5189 Fax :(336)822-5149

>> sue.doughty at odfl.com

>> 

>> -----Original Message-----

>> From: Sue Doughty

>> Sent: Monday, October 22, 2007 11:28 AM

>> To: 'SAP Workflow Users' Group'

>> Subject: RE: Enqueue Errors - ECC 6.0

>> 

>> Hi Mike,

>> 

>> Thanks for responding.

>> 

>> There is a decision task.  They can click to print forms or if they

> want

>> to do the action in PA40, they click "Execute Payroll (or whatever)

>> followup action".  The task that gets executed is a call to PA40.

>> 

>> 

>> Regards,

>> Sue T. Doughty

>> SAP Workflow Specialist

>> OLD DOMINION FREIGHT LINE, INC.

>> 500 Old Dominion Way, Thomasville, NC 27360

>> Toll Free :(800)432-6335, ext.5189

>> Phone :(336)822-5189 Fax :(336)822-5149

>> sue.doughty at odfl.com

>> 

>> -----Original Message-----

>> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On

> Behalf

>> Of Mike Pokraka

>> Sent: Monday, October 22, 2007 9:39 AM

>> To: SAP Workflow Users' Group

>> Subject: Re: Enqueue Errors - ECC 6.0

>> 

>> Hmmm, my first thougt was that this is complete nonsense from OSS.

>> Then I notice that they talk about a decision task. So, now I think

>> we're

>> missing a piece of info here - is this a decision or a PA40?

>> 

>> A possible workaround may be to put the PA40's into a subWF. It may

> only

>> lock the subworkflow. On the other hand it may also be a case of

>> rejecting

>> SAP's response - depending on this mystery decision task that is
PA40.

>> 

>> Cheers,

>> Mike

>> 

>> 

>> On Mon, October 22, 2007 1:26 pm, Sue Doughty wrote:

>>> We are in the process of upgrading from 4.7 to ECC 6.0.

>>> 

>>> 

>>> 

>>> We have a New Hire workflow that has a fork with three branches.

> Each

>>> branch goes to a different department and they all have a work item

>> that

>>> executes PA40 where they execute a specific action for the employee.

>>> 

>>> 

>>> 

>>> In 4.7, if two departments happened to hit the same employee at the

>> same

>>> time, the second department trying to execute the work item would
get

>> an

>>> error in PA40 - Employee is being processed by ######.  They would

>>> cancel out and come back later.  The work item would remain in their

>>> in-box.

>>> 

>>> 

>>> 

>>> 

>>> In ECC 6.0, the workflow gets an ENQUEUE error - Error when loading

>>> component: Work item 000000638111 locked (action FIND_FLOWITEM) and

>> then

>>> Work item 000000638111 locked by user E050889 (enqueue error)
(action

>>> FIND_BY_WIID_BY_WFM)

>>> 

>>> 

>>> The error is referencing the Workflow INSTANCE, not the work item

>> being

>>> executed.  The work item for the second user is then set to Complete

> -

>>> it never takes them to PA40.  They have no way of going back in
later

>>> and executing the action.

>>> 

>>> 

>>> 

>>> I opened a note with SAP and was told that it is working as
designed.

>>> See SAP's response below:

>>> 

>>> 

>>> 

>>> Here the lock did not occur during work item execution, but after

>>> execution during

>>> the so-called "callback", because the corresponding workflow (father

>>> work item) was locked. In such a case the work item (user decision)

>>> is COMPLETED and the workflow is suspended. Especially the so-called

>>> "synchronous process chain" (advance with dialog) is interrupted

>>> unless SWWERRE puts the subsequent work item (PA40) into the inbox

>>> of the user concerned.

>>> 

>>> According to our development manager this works as designed.

>>> 

>>> 

>>> 

>>> 

>>> 

>>> I am at a loss as to how to fix this problem.  I don't want to take

>> out

>>> the fork and have the departments execute the PA40 action one after

>> the

>>> other.  This would lengthen the time the workflow takes to get

> someone

>>> hired and I don't know which department I would do first....they all

>> do

>>> things in their own time.

>>> 

>>> 

>>> 

>>> Has anyone else encountered this problem?  Does anyone have any

>>> suggestions?

>>> 

>>> 

>>> 

>>> Any help would be greatly appreciated.

>>> 

>>> 

>>> 

>>> Regards,

>>> 

>>> Sue T. Doughty

>>> SAP Workflow Specialist

>>> 

>>> OLD DOMINION FREIGHT LINE, INC.

>>> 

>>> 500 Old Dominion Way, Thomasville, NC 27360

>>> 

>>> Toll Free :(800)432-6335, ext.5189

>>> Phone :(336)822-5189 Fax :(336)822-5149

>>> sue.doughty at odfl.com

>>> 

>>> 

>>> 

>>> 

>>> 

>>> ****************************

>>> CONFIDENTIALITY NOTICE: The information contained in this message
may

>> be

>>> confidential, privileged, proprietary, or otherwise legally exempt

>> from

>>> disclosure. If the reader of this message is not the intended

>> recipient,

>>> or an employee or agent responsible for delivering this message to

> the

>>> intended recipient, you are hereby notified that you are not

>> authorized to

>>> read, print, retain, copy or disseminate this message, any part of

> it,

>> or

>>> any attachments. If you have received this message in error, please

>> delete

>>> this message and any attachments from your system without reading
the

>>> content and notify the sender immediately of the inadvertent

>> transmission.

>>> Thank you for your cooperation.

>>> 

>>> _______________________________________________

>>> SAP-WUG mailing list

>>> SAP-WUG at mit.edu

>>> http://mailman.mit.edu/mailman/listinfo/sap-wug

>>> 

>> 

>> 

>> --

>> Mike Pokraka

>> Senior Consultant

>> Workflow Connections

>> Mobile: +44(0)7786 910855

>> 

>> _______________________________________________

>> SAP-WUG mailing list

>> SAP-WUG at mit.edu

>> http://mailman.mit.edu/mailman/listinfo/sap-wug

>> 

>> 

>> ****************************

>> CONFIDENTIALITY NOTICE: The information contained in this message may

> be

>> confidential, privileged, proprietary, or otherwise legally exempt

> from

>> disclosure. If the reader of this message is not the intended

> recipient,

>> or an employee or agent responsible for delivering this message to
the

>> intended recipient, you are hereby notified that you are not

> authorized to

>> read, print, retain, copy or disseminate this message, any part of
it,

> or

>> any attachments. If you have received this message in error, please

> delete

>> this message and any attachments from your system without reading the

>> content and notify the sender immediately of the inadvertent

> transmission.

>> Thank you for your cooperation.

>> 

>> _______________________________________________

>> SAP-WUG mailing list

>> SAP-WUG at mit.edu

>> http://mailman.mit.edu/mailman/listinfo/sap-wug

>> 

> 

> 

> --

> Mike Pokraka

> Senior Consultant

> Workflow Connections

> Mobile: +44(0)7786 910855

> 

> _______________________________________________

> SAP-WUG mailing list

> SAP-WUG at mit.edu

> http://mailman.mit.edu/mailman/listinfo/sap-wug

> 

> 

> ****************************

> CONFIDENTIALITY NOTICE: The information contained in this message may
be

> confidential, privileged, proprietary, or otherwise legally exempt
from

> disclosure. If the reader of this message is not the intended
recipient,

> or an employee or agent responsible for delivering this message to the

> intended recipient, you are hereby notified that you are not
authorized to

> read, print, retain, copy or disseminate this message, any part of it,
or

> any attachments. If you have received this message in error, please
delete

> this message and any attachments from your system without reading the

> content and notify the sender immediately of the inadvertent
transmission.

> Thank you for your cooperation.

> 

> _______________________________________________

> SAP-WUG mailing list

> SAP-WUG at mit.edu

> http://mailman.mit.edu/mailman/listinfo/sap-wug

> 

-- 

Mike Pokraka

Senior Consultant

Workflow Connections

Mobile: +44(0)7786 910855

_______________________________________________

SAP-WUG mailing list

SAP-WUG at mit.edu

http://mailman.mit.edu/mailman/listinfo/sap-wug

**************************** 
CONFIDENTIALITY NOTICE: The information contained in this message may be
confidential, privileged, proprietary, or otherwise legally exempt from
disclosure. If the reader of this message is not the intended recipient,
or an employee or agent responsible for delivering this message to the
intended recipient, you are hereby notified that you are not authorized
to read, print, retain, copy or disseminate this message, any part of
it, or any attachments. If you have received this message in error,
please delete this message and any attachments from your system without
reading the content and notify the sender immediately of the inadvertent
transmission. Thank you for your cooperation.

Cadbury Cocoa Partnership - a historic alliance to secure the future of
cocoa farming. Visit www.cadbury.com <http://www.cadbury.com/>  to learn
more

Please support our Purple Goes Green commitments and consider the
environment before you print this email

-----------------------------------------

This email (including any attachment) is confidential and may contain
privileged information. If you are not the intended recipient or receive
it in error, you may not use, distribute, disclose or copy any of the
information contained within it and it may be unlawful to do so. If you
are not the intended recipient please notify us immediately by returning
this email to us at mailerror at csplc.com <mailto:mailerror at csplc.com>
and destroy all copies.

Any views expressed by individuals within this email do not necessarily
reflect the views of Cadbury Holdings Ltd or any of its subsidiaries or
affiliates. This email does not constitute a binding offer, acceptance,
amendment, waiver or other agreement, or create any obligation
whatsoever, unless such intention is clearly stated in the body of the
email. Whilst we have taken reasonable steps to ensure that this email
and any attachments are free from viruses, recipients are advised to
subject this email to their own virus checking, in keeping with good
computing practice. We accept no liability for any damage sustained as a
result of any viruses. Please note that email received by Cadbury
Holdings Ltd or its subsidiaries or affiliates may be monitored in
accordance with applicable law. 

This email originates from Cadbury Holdings Ltd ("Cadbury") or Cadbury
UK ("Cadbury UK") as the case may be.

Cadbury Holdings Ltd: registered in England and Wales, registered no.
52457
Registered address: Cadbury House, Sanderson Road, Uxbridge, Middlesex
UB8 1DH United Kingdom. 

Telephone: +44 (0) 1895-615000  Fax: +44 (0) 1895-615001

Cadbury UK: a partnership of Cadbury UK Ltd, Trebor Bassett Ltd and The
Old Leo Company Ltd each of which is registered in England and Wales. 

Principal trading address: Cadbury House, Sanderson Road, Uxbridge,
Middlesex UB8 1DH United Kingdom. 

Telephone: +44 (0) 1895-615000  Fax: +44 (0) 1895-615001

-----------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20081112/d2a5f6d1/attachment.htm