Commit Work

Tue Jun 12 09:21:07 EDT 2007

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 10600 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20070612/cd395f87/attachment.bin