Commit Work

[Mike Pokraka]

Erm... to be completely British about it: hear hear. Short for "hear him,
hear him". http://en.wikipedia.org/wiki/Hear_hear

Cheers,
Mike

On Tue, June 12, 2007 2:22 pm, Alon Raskin wrote:
> Here here (that's British for I agree).
>
> Well I only partially agree. I still don't like the idea of doing my own
> explicit COMMIT WORK.
>
> Alon
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu on behalf of Mowry, Douglas
> Sent: Tue 6/12/2007 09:14
> To: SAP Workflow Users' Group
> Subject: RE: Commit Work
>
>
>
> 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
>
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>


-- 
Mike Pokraka
Senior Consultant
Workflow Connections
Mobile: +44(0)7786 910855