Commit Work

[Mowry, Douglas]

I've never found the COMMIT WORK to be a problem for BAPIs.  Many BAPIs
have a COMMIT parameter built in which works fine.  If not, just call
BAPI_TRANSACTION_COMMIT immediately after your BAPI and that works fine
as well.  I'll take a BAPI over a BDC any day.

 

Doug Mowry

________________________________

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Alon Raskin
Sent: Tuesday, June 12, 2007 9:06 AM
To: SAP Workflow Users' Group
Subject: RE: Commit Work

 

Hi Ed,


Thanks very much for the response. I have been burnt way too many times
by BDCs. Not to mention performance implications. Perhaps it is an OK
for workflows with low volumes but on an IS-U implementation (read Mike
Gambier Taylors response to see what I mean) a BDC is a recipe for
disaster.


Thank you for your input anyway.

 

Alon Raskin

 

________________________________

From: sap-wug-bounces at mit.edu on behalf of Edward Diehl
Sent: Tue 6/12/2007 08:43
To: SAP Workflow Users' Group
Subject: RE: Commit Work

Hi Alon,
I try to always use a BDC function to create a new object rather than a
BAPI.  A BAPI, if it is not called as an RFC, required an explicit
COMMIT WORK.  It may be some defect in my understanding, but I am not a
big fan of BAPIs for several reasons and this is just one of them.
 
Regards,
Ed Diehl



________________________________

Subject: Commit Work
Date: Mon, 11 Jun 2007 17:09:57 -0400
From: araskin at 3i-consulting.com
To: sap-wug at mit.edu

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20070612/2d3db6bb/attachment.htm