Commit Work

Tue Jun 12 14:02:46 EDT 2007

Upon reflection there are some BAPIs I could not live without - function group CVBAPI for DMS stuff, for example.  And, yes, don't do BDCs with popups or tablecontrols or arrays of checkboxes.  I just object to the "everything including the kitchen sink" design philosophy behind most BAPIs.

BTW, have you tried writing a BAPI call in CRM and had to call a BAPI not resident in the CRM system - especially a very complex BAPI?  The BDC is really no more help here but the interface is simpler.

Regards,
Ed
> Date: Tue, 12 Jun 2007 17:23:28 +0100> Subject: RE: Commit Work> From: asap at workflowconnections.com> To: sap-wug at mit.edu> > Hmmm... well, my experience has always been the opposite :)> The last time I had a chance to argue with BDCs because there were no> BAPIs was with MIRO and that little PO selection button and it's resulting> popup. I remember it clearly as we spent several days on that brick wall.> > Agreed, sometimes bapis may seem (!) a little more work up front, but one> trick here is to only use the bit that you need. Think of it like the ABAP> equivalent of taking the little bit of time to code something into a> function module so that it can be reused elsewhere. The hidden benefits> are enormous and often only apparent later - when you upgrade or have to> change something. You can drop a BAPI into a portal environment and don't> care whether it talks to your old EBP system or a shiny new ECC6.> > As to updates, I've always found the transactions (i.e. BDC) to be the> less reliable :-) See my other post with the SAP doco link regarding the> commit logic.> > Cheers,> Mike> > On Tue, June 12, 2007 4:05 pm, Edward Diehl wrote:> >> > 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_______________________________________________> > 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/f487400d/attachment.htm