Commit Work

Tue Jun 12 07:46:48 EDT 2007

Hi all,

One solution might lie in the technique used for the business communication interface with use of the BO MESSAGE and RECIPIENT. This is nothing to do with sending emails, but creating a link between two separate business objects in one step. 

An example of where else this is used in the function module ARCHIV_WFL_PROCESS. I'm thinking of a solution where one object is created [SWO_QUERY_VERB_PARAMETERS]and it's returned ID [INFO]is used to invoke a second method [SWO_INVOKE] all in the same workflow step.

I've played around with this enough to recommend it is a general solution to the problem, only I've observed the process and think it's worth a closer look.

Phil

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu]On Behalf
Of Mike Gambier
Sent: 12 June 2007 09: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