Commit Work

[Edward Diehl]

Hi Mike, et al,
OK! OK!  I said my understanding was defective (perhaps).  As for reasons, I have never, ever had a problem with BDCs (using the function module generator from SHDB) and I also use them a lot to usher the user through one or more screens on dialog tasks that call standard transactions (CALL FUNCTION ..USING) so I am comfortable with them.  The new SHDB handles the subscreens very well and that was not always the case.  
 
I find many BAPIs so complex as to be incomprehensible; e.g. the BAPI for creating a sales order.  User friendly???  I can create a SHDB function for creating a new material (MM01) faster that I can figure out how to use the BAPI to do the same thing.  
 
I know BDCs are old technology and the BAPI returns a lot of good information in BAPIRET and are probably more robust, but it is just my preference.  AND, I have had no problems getting my new objects saved in the database in time for my next workflow step.  Perhaps the update process sorts BAPIs to the bottom - :)
 
With greatest repect,
Ed 
 
 
 
 
> Date: Tue, 12 Jun 2007 14:26:52 +0100> Subject: RE: Commit Work> From: asap at workflowconnections.com> To: sap-wug at mit.edu> > Hi Ed,> No no no... By all means post your understandings and reasons, but BAPIs> are most very very definitively surely absolutely positively (can you see> a theme here) certainly unquestionably and beyond a shadow of a doubt the> better alternative to creating/changing objects in background.> They are stable, upgrade-friendly, simpler, more versatile.> > That said, I have to admit I'm curious what your several reasons are...?> > Cheers,> Mike> > On Tue, June 12, 2007 1:43 pm, Edward Diehl wrote:> >> > 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 WorkDate: Mon, 11 Jun 2007 17:09:57 -0400From:> > araskin at 3i-consulting.comTo: 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> > _______________________________________________> SAP-WUG mailing list> SAP-WUG at mit.edu> http://mailman.mit.edu/mailman/listinfo/sap-wug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20070612/877477b7/attachment.htm