Commit Work
Mike Gambier
madgambler at hotmail.com
Fri Jun 15 04:15:46 EDT 2007
Paul,
If you're ever in these parts I'll be happy to show you the mess Workflow
can leave itself in when you're dealing with a system running on 22
application servers, on a system that is up for 16 hours a day 6 days a
week, used by 8,000+ users in two countries and supporting the billing of 16
million customers.
Trust me, it's not stable at these volumes. But, having said that it could
be a whole lot worse...
Mike GT
>From: Paul.Bakker at osr.treasury.qld.gov.au
>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: Fri, 15 Jun 2007 06:38:29 +1000
>
>Mike,
>
>Let me crawl out on a limb and say that in 4 years of doing workflow (over
>half a dozen sites), I have never found a workflow problem that couldn't be
>explained logically.
>
>Perhaps that is because I've never been to a real high-volume site like
>yours.. I don't know.
>
>Overall, I've always found SAP workflow to be a very stable, predictable
>system. As someone else noted, most problems are due to those pesky users.
>:-)
>
>cheers
>Paul from Brisbane
>
>
>
>|---------+---------------------------->
>| | "Mike Gambier" |
>| | <madgambler at hotma|
>| | il.com> |
>| | Sent by: |
>| | sap-wug-bounces at m|
>| | it.edu |
>| | |
>| | |
>| | 15/06/2007 01:36 |
>| | Please respond to|
>| | "SAP Workflow |
>| | Users' Group" |
>| | |
>|---------+---------------------------->
>
> >---------------------------------------------------------------------------------------------------------------------|
> |
> |
> | To: sap-wug at mit.edu
> |
> | cc:
> |
> | Subject: RE: Commit Work
> |
>
> >---------------------------------------------------------------------------------------------------------------------|
>
>
>
>
>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
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
>
>
>******************************************************************************************************************************************************
>
>Only an individual or entity who is intended to be a recipient of this
>e-mail may access or use the information contained in this e-mail or any of
>its attachments. Opinions contained in this e-mail or any of its
>attachments do not necessarily reflect the opinions of Queensland Treasury.
>
>The contents of this e-mail and any attachments are confidential and may be
>legally privileged and the subject of copyright. If you have received this
>e-mail in error, please notify Queensland Treasury immediately and erase
>all copies of the e-mail and the attachments. Queensland Treasury uses
>virus scanning software. However, it is not liable for viruses present in
>this e-mail or in any attachment.
>
>******************************************************************************************************************************************************
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug
_________________________________________________________________
Picture this – share your photos and you could win big!
http://www.GETREALPhotoContest.com?ocid=TXT_TAGHM&loc=us
More information about the SAP-WUG
mailing list