Commit Work

Thu Jun 14 14:37:38 EDT 2007

I agree with the statement about WF being very stable. A few hiccups now
and then but so minor not worth investigating. (Sun Spots?)
I agree with the statement you should keep it simple as possible. 

But, I don't understand the last point. If it is hard, don't do it?
<grin>

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Munday,Sherie J.
Sent: Thursday, June 14, 2007 1:01 PM
To: SAP Workflow Users' Group
Subject: RE: Commit Work

Mike,
I know you programmers will shoot me for this one...  But our company
knows SAP Workflow to be one of the most stable consistent tools we
have.  We have a policy of absolute minimal coding, custom workflows
using Business Object Types with just a bit of extending.  The errors we
generally find are data problems or user errors.  Hearing of your many
issues confirms my suspicions that staying simple is beneficial to the
company (although it does lead to less work for the consultants).
Cheers,
Sherie 

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Mike Gambier
Sent: Thursday, June 14, 2007 11:37 AM
To: sap-wug at mit.edu
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%20Par
>k
>&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

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug