Commit Work

Thu Jun 14 11:36:57 EDT 2007

Andy,

We see a lot of COMMIT issues in our system when it comes to Workflow in 
4.6c, and when I mean a lot I mean all sorts of issues, not just simple 
steps.

We see the following on occasion, sometimes often:

1. Events that are raised but never heard, even though the event listener is 
out there, waiting.

2. Steps completing but the DB updates not being fast enough for the 
Workflow (even with COMMIT WORK AND WAIT explicitly stated in the Method 
code, of course LUW concept is boken here).

3. Branches of forks not shutting down when they should (WF becomes 
completely frozen)

4. Loops not terminating when their end condition is set (WF becomes 
completely frozen)

5. Sub-WFs completing but their Parents still waiting for them to finish (WF 
becomes completely frozen)

6. Deadlines that end but the WF does nothing afterwards (WF becomes 
completely frozen)

7. Event containers going 'missing'.

All of these really are down to the Workflow service jobs, SWEQSRV, SWERRE 
and SWWDHEX encountering various types of problems (and probably issuing 
ROLLBACK statements) and/or the LUW handling being incorrect with partial 
commits taking place that Workflow can't handle.

Things like screen messages, short dumps, WF syntax/definition glitches and 
unexpected Commits inside code all have a nasty tendancy to interrupt these 
programs and therefore expose the whole process chain to unrecoverable 
breaks.

The phrase often quoted around here about Workflow is that it is 'flaky' and 
needs constant attention. To be honest we have literally tens of thousands 
of WFs in trouble system-wide and it's often really tough to know what to do 
next, particularly after time has elapsed. For most of our WFs we have had 
to turn off the technical log due to our volumes so we have all become 
familiar with the underlying tables to find out waht's going on.

Thankfully, as we all should know, SAP do give us some handy Transactions to 
help: SWIA, SWPR, SWPC (in increasing order of severity). But, often these 
programs require the Workflow entries to be in a consistent state to qualify 
for selection and/or reprocessing. So 'adjustment' of the tables is 
sometimes required... And sometimes direct calling of the Workflow Admin 
Functions becomes inevitable...

We've recently gone back to SAP and asked them to provide us with a better 
tool to analyse the health of our running WF instances. Will publish here 
any progress on that front.

Knowing what to do and when is all part of the skill required to look after 
Workflow I suppose.

Mike GT

>From: "Catherall, Andy M" <andy.m.catherall at csplc.com>
>Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>Subject: RE: Commit Work
>Date: Thu, 14 Jun 2007 06:25:09 -0600
>
>Hi
>
>To expand this 'Commit Work' debate a little further (sorry), I'm
>curious to understand better the implications of Commits in background
>work items.
>
>I've had problems where the code in a background step has errored poorly
>(SAP standard, too!), which has caused the WF to stall quietly, awaiting
>the return from a method that will never complete. Finally, I receive
>the notification from the batch job to say that the Work Item is at
>status 'started'.
>
>A quick look in SM58 shows the error on the RFC that spawned the
>background job. The underlying cause of the error is corrected
>(sometimes, it is little more than an object locked by a user) and the
>RFC can be resubmitted.
>
>What I have discovered is that you cannot assume the LUW is correct, or
>that the workflow will resume correctly - or even at all.
>
>My theory is this that the code being run as a separate session via RFC
>is frequently not *designed* specifically for this, and has Commits in
>places that destroy the LUW. Based on this theory, it would be
>preferable to use BAPIs where possible, and only commit at appropriate
>logic points.
>
>Thoughts...?
>
>I'm also curious to know if there is any wisdom on restarting background
>tasks that have errored... On 4.6c
>
>
>Thanks
>Andy
>
>
>
>-----Original Message-----
>From: sap-wug-bounces at mit.edu@CADSCHW On Behalf Of "Alon Raskin"
><araskin at 3i-consulting.com>
>Sent: 12 June 2007 14:21
>To: SAP Workflow Users' Group
>Subject: RE: Commit Work
>
>Hi Mikey,
>
>I completely understand your point of view. There is just something
>about doing my own COMMIT WORK (and wait) in the method that makes me
>feel uncomfortable. It means that I am going to end the LUW myself and
>not give the caller (the workflow sub-system) a chance to do its own
>COMMIT WORK or ROLLBACK.
>
>To be honest I have only seen a COMMIT WORK 'break' things once. It was
>on an IS-U implementation in Sydney, and the workflow just hung. When we
>removed the COMMIT WORK all was well. I guess the COMMIT WORK was
>leaving the workflow tables in some sort of inconsistent state.
>
>I am sure there has to be a better way...
>
>Perhaps the answer is to never call BAPIs directly from a Workflow but
>rather wrap the BAPI in a 'standard' method. 'The Good Book' (not the
>one with Abraham and Moses but the one with Rickayzen and Dart) even
>mentions it is a good idea to wrap BAPI calls in standard methods but it
>suggests this for different reasons then the one I am thinking of.
>
>Ps. I am coming to the UK in 2nd and 3rd week of July. Any chance of a
>Poker game with the boys?
>
>Alon Raskin
>e: araskin at 3i-consulting.com <mailto:araskin at 3i-consulting.com>
>p: +1 207 523 3489
>c: +1 207 409 4983
>f:  +1 806 403 4983
>
>
>________________________________
>
>From: sap-wug-bounces at mit.edu on behalf of Mike Gambier
>Sent: Tue 6/12/2007 04:04
>To: sap-wug at mit.edu
>Subject: Re: Commit Work
>
>
>
>Hey Gavin & Alon,
>
>On that same UK project (which is still going on by the way, only now
>it's live with 16 million customers and going to be upgraded to ERP 2005
>at some point), we still occasionally see DB update issues every now and
>then, even with explicit COMMIT WORK AND WAIT statements littered (as
>you say) inside the BOR Methods.
>
>After more analysis the problems seem to be related to timing issues
>with object instances that have their own buffering (and when the
>buffers are refreshed), buffering at the DB level for SQL performance
>and V1 and V2 updates actually being carried out at the DB level.
>
>Simply put Workflow can sometimes be too quick to proceed to the next
>step, particularly when the system its on as a whole has a lot of
>traffic.
>
>My advice to anyone who absolutely positively needs to have performed
>the update in a previous step first is to:
>
>a) Consider adding explicit COMMIT WORK AND WAIT statements driven by
>optional importing parameters to their methods - more load on the system
>and delays to the Workflow but a greater chance of success. You can then
>experiment by setting the parameters on certain sensitive steps to see
>if this helps. If it doesn't you can always remove the flag setting in
>the binding later.
>
>b) remember to refresh buffered instances after the data has been
>updated.
>Often overlooked this one. Same goes for the binding to between the step
>and the Workflow. If you have specified the binding make sure any
>updated instances are actually passed back to the WF container.
>
>c) build in to the WF definition decent error handling and possible
>retries (e.g. temporary exceptions). Think about how certain you have to
>be that the previous DB update has actually worked to carry on with the
>WF. Sometimes after several tries you may actually want to stop the WF
>altogether because it would be too risky to carry on.
>
>Regards,
>
>Mike GT
>
> >From: "Gavin Mooney" <gavinmooney at gmail.com>
> >Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> >To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> >Subject: Re: Commit Work
> >Date: Mon, 11 Jun 2007 19:11:41 -0300
> >
> >Hey Alon,
> >
> >When I was looking into this issue once on 4.6C (for a project in the
> >UK that you may remember) I found that the code was littered with
> >explicit COMMIT WORK statements, including after the execution of each
> >step. I don't know if this has changed in the newer releases but my
> >guess is that by being a COMMIT WORK and not a COMMIT WORK AND WAIT
> >statement, you can still have update problems.
> >
> >We didn't see this just with BAPIs though. As far as I remember we
> >resolved it either by creating a custom wrapper method that called the
> >standard one and then executed a (SAP authorised) COMMIT WORK or by
> >using async methods and terminating events.
> >
> >I'd be interested to see what experiences other members of the group
> >have had....
> >
> >Regards,
> >Gavin
> >
> >2007/6/11, Dave Weston <Dave.Weston at clockwork.ca>:
> > > Alan, in step 1 are you also calling BAPI_TRANSACTION_COMMIT at the
> > > end
> >to do the commit and apply the changes to the db ? you can also use the
>
> >WAIT parameter to wait for the update to take place as well.
> > >
> > > Dave
> > >
> > >
> > > -----Original Message-----
> > > From: sap-wug-bounces at mit.edu on behalf of Alon Raskin
> > > Sent: Mon 6/11/2007 5:09 PM
> > > To: SAP Workflow Users' Group
> > > Subject: Commit Work
> > >
> > > A colleague of mine is having an issue and I wanted to see if anyone
>
> > > has
> >seen this before. I have seen this issue creep up on different
> >implementations so I am sure I am not the first to handle this.
> > >
> > >
> > > *
> > >
> > >         Step 1 creates a new document (doesn't matter what it is,
> > > its
> >IS-U) by calling a BAPI
> > > *
> > >
> > >         The BAPI returns the ID of the new object which can be seen
> > > in
> >the container of the Workflow
> > > *
> > >
> > >         Step 2 then calls SYSTEM.GenericInstantiate to get an
> > > instance
> >of the newly created document
> > > *
> > >
> > >         Step 2 errors claiming that the object does not exist.
> > >
> > > I suggested to him to uncheck the Advance with Dialog step as I
> > > thought
> >that this would 'force' the WF sub-system to do a COMMIT WORK between
> >steps but this did not seem to work. I was sure that the Workflow
> >sub-system always executes a COMMIT WORK between steps. Is that not the
>
> >case? We did a test, and created a method where all it did was execute
> >a COMMIT WORK. We inserted this step in between the BAPI and the
> >System.GenericInstantiate and everything worked beautifully. So it is
>definitely a commit issue.
> >Perhaps WF treats methods marked as BAPIs differently to standard
> >methods and doesn't not do an explicit COMMIT WORK? If so, how do
> >people get around this?
> > >
> > > Regards,
> > >
> > > Alon Raskin
> > >
> > >
> > >
> > > _______________________________________________
> > > SAP-WUG mailing list
> > > SAP-WUG at mit.edu
> > > http://mailman.mit.edu/mailman/listinfo/sap-wug
> > >
> > >
> > >
> >_______________________________________________
> >SAP-WUG mailing list
> >SAP-WUG at mit.edu
> >http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>_________________________________________________________________
>Need a break? Find your escape route with Live Search Maps.
>http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park
>&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=
>1118863&encType=1&FORM=MGAC01
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>P please don't print this e-mail unless you really need to.
>
>-----------------------------------------
>
>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 
>e-mail to us at mailerror at csplc.com and destroy all copies.
>Any views expressed by individuals within this e-mail do not necessarily 
>reflect the views of Cadbury Schweppes Plc or any of its subsidiaries' or 
>affiliates'. This email does not constitute a binding offer, acceptance, 
>amendment, waiver or other agreement, unless such intention is clearly 
>stated in the body of the email.  Whilst we have taken reasonable steps to 
>ensure that this e-mail and attachments are free from viruses, recipients 
>are advised to subject this mail to their own virus checking, in keeping 
>with good computing practice.
>Please note that e-mail received by Cadbury Schweppes Plc or its 
>subsidiaries or affiliates may be monitored in accordance with applicable 
>law.
>
>Cadbury Schweppes plc registered in England, Company Number 00052457
>whose Registered Office is at 25 Berkeley Square, London, W1J 6HB United 
>Kingdom
>Telephone:+44 (0) 20 7409 1313 Fax:+44 (0) 20 7830 5200
>-----------------------------------------
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug

_________________________________________________________________
Like puzzles? Play free games & earn great prizes. Play Clink now. 
http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2