Commit Work

[Mike Pokraka]

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