Commit Work

Alon Raskin araskin at 3i-consulting.com
Tue Jun 12 09:21:13 EDT 2007


Hey Gav,
 
Yes I agree. I think creating the wrapper is the option that I favour the most at this point. I just wondered if anyone else had other ideas/suggestions.
 
Alon Raskin

________________________________

From: sap-wug-bounces at mit.edu on behalf of Gavin Mooney
Sent: Mon 6/11/2007 18:11
To: SAP Workflow Users' Group
Subject: Re: Commit Work



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


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


More information about the SAP-WUG mailing list