Commit Work

[Dart, Jocelyn]

How well a workflow handles exceptions is entirely dependent on how well
the workflow developer modelled the exceptions in the first place.
Workflow can't respond to an error it has no knowledge of.  The workflow
developer has to expose the error as an exception with the appropriate
exception type - then workflow can take the appropriate remedial action
for that exception type - i.e. automatic retry, email notification to
administrator and retry through SWPR, or follow an alternate modelled
workflow path.  

This is also why negative testing is a critical part of workflow
development. 

In the latest releases (7.0) where I am working I have noticed that the
ABAP OO exception handling seems to be better - i.e. even unexpected
system exceptions are getting picked up by workflow automatically. 

Regards,
Jocelyn Dart
Senior Consultant
SAP Australia Pty Ltd.
Level 1/168 Walker St.
North Sydney 
NSW, 2060
Australia
T   +61 412 390 267
M   + 61 412 390 267
E   jocelyn.dart at sap.com
http://www.sap.com

The information contained in or attached to this electronic transmission
is confidential and may be legally privileged. It is intended only for
the person or entity to which it is addressed. If you are not the
intended recipient, you are hereby notified that any distribution,
copying, review, retransmission, dissemination or other use of this
electronic transmission or the information contained in it is strictly
prohibited. If you have received this electronic transmission in error,
please immediately contact the sender to arrange for the return of the
original documents. 
Electronic transmission cannot be guaranteed to be secure and
accordingly, the sender does not accept liability for any such data
corruption, interception, unauthorized amendment, viruses, delays or the
consequences thereof.
Any views expressed in this electronic transmission are those of the
individual sender, except where the message states otherwise and the
sender is authorized to state them to be the views of SAP AG or any of
its subsidiaries. SAP AG, its subsidiaries, and their directors,
officers and employees make no representation nor accept any liability
for the accuracy or completeness of the views or information contained
herein. Please be aware that the furnishing of any pricing information/
business proposal herein is indicative only, is subject to change and
shall not be construed as an offer or as constituting a binding
agreement on the part of SAP AG or any of its subsidiaries to enter into
any relationship, unless otherwise expressly stated. 


-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Catherall, Andy M
Sent: Tuesday, 19 June 2007 8:14 PM
To: SAP Workflow Users' Group
Subject: RE: Commit Work

Hi guys 

Thanks for this information. I'm looking forward to an upgrade...


In general, our workflows have been fairly stable. Certainly we have not
been witness to the scope & scale of problems Mike describes (and we are
using workflows quite extensively, most of them custom or customised).
Also, in general, the problems we have seen have been more to do poorly
handled coding errors occuring during the processing by WF-BATCH.

Given how much workflow relies upon RFC to do its work, I find it a
little surprising that the "Workflow-Logical-Unit-of-Work" appears to be
such a poorly defined concept. If the RFC has errored, I'd like to be
able to run it again - for example, by setting the step and the workflow
to 'error' and running SWPR. I find that SWPC rarely seems to find
workflows that have died in the manner described.

With regard to using standard workflows over custom, I find that the
error handling in the standard workflows is generally too simplistic.
They're fine if they are working well, but do not process exceptions (to
the process) particularly well. 

Cheers
Andy

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Mike Pokraka
Sent: 15 June 2007 10:14
To: SAP Workflow Users' Group
Subject: RE: Commit Work

Ahem, I usually find that the simple one requiring little coding is the
most difficult one.
It's far too easy to just start coding. When I feel the need for it I
usually first get away from the problem, go for a walk around the block
or do other stuff and then come back to look at standard alternatives.
It's amazing how much you can do with very little code if you just think
carefully about design...

On a different note to Mike: I've found 4.6c to be a little less than
stable in high volume scenarios. On 620 however the picture is quite
different, the whole event handling and event queue and a lot of other
stuff has been completely rewritten - in workflow terms 620 really is a
huge upgrade under the hood and I suspect your experiences are the
reason for the rewrite.

Cheers,
Mike


On Thu, June 14, 2007 8:19 pm, Munday,Sherie J. wrote:
> Rick,
> We never hide from hard work.... :o)
> My last sentence meant that if companies did not need the programming,

> they would need fewer outside consultants, thus making many of our 
> fellow wuggers unhappy.
> <grinning back at ya>  :o)
> Sherie
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On 
> Behalf Of Sample, Rick
> Sent: Thursday, June 14, 2007 2:38 PM
> To: SAP Workflow Users' Group
> Subject: RE: Commit Work
>
> 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%20Pa
>>r
>>k
>>&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scen
>>e
>>=
>>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
>
>
> _______________________________________________
> 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
>


--
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 
 
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