Commit Work

Thu Jun 14 08:25:09 EDT 2007

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