<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
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.<BR>
<BR>
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.<BR>
<BR>
Regards,<BR>
Ed<BR>
<BR><BR>> Date: Tue, 12 Jun 2007 17:23:28 +0100<BR>> Subject: RE: Commit Work<BR>> From: asap@workflowconnections.com<BR>> To: sap-wug@mit.edu<BR>> <BR>> Hmmm... well, my experience has always been the opposite :)<BR>> The last time I had a chance to argue with BDCs because there were no<BR>> BAPIs was with MIRO and that little PO selection button and it's resulting<BR>> popup. I remember it clearly as we spent several days on that brick wall.<BR>> <BR>> Agreed, sometimes bapis may seem (!) a little more work up front, but one<BR>> trick here is to only use the bit that you need. Think of it like the ABAP<BR>> equivalent of taking the little bit of time to code something into a<BR>> function module so that it can be reused elsewhere. The hidden benefits<BR>> are enormous and often only apparent later - when you upgrade or have to<BR>> change something. You can drop a BAPI into a portal environment and don't<BR>> care whether it talks to your old EBP system or a shiny new ECC6.<BR>> <BR>> As to updates, I've always found the transactions (i.e. BDC) to be the<BR>> less reliable :-) See my other post with the SAP doco link regarding the<BR>> commit logic.<BR>> <BR>> Cheers,<BR>> Mike<BR>> <BR>> On Tue, June 12, 2007 4:05 pm, Edward Diehl wrote:<BR>> ><BR>> > Hi Mike, et al,<BR>> > OK! OK! I said my understanding was defective (perhaps). As for reasons,<BR>> > I have never, ever had a problem with BDCs (using the function module<BR>> > generator from SHDB) and I also use them a lot to usher the user through<BR>> > one or more screens on dialog tasks that call standard transactions (CALL<BR>> > FUNCTION ..USING) so I am comfortable with them. The new SHDB handles the<BR>> > subscreens very well and that was not always the case.<BR>> ><BR>> > I find many BAPIs so complex as to be incomprehensible; e.g. the BAPI for<BR>> > creating a sales order. User friendly??? I can create a SHDB function<BR>> > for creating a new material (MM01) faster that I can figure out how to use<BR>> > the BAPI to do the same thing.<BR>> ><BR>> > I know BDCs are old technology and the BAPI returns a lot of good<BR>> > information in BAPIRET and are probably more robust, but it is just my<BR>> > preference. AND, I have had no problems getting my new objects saved in<BR>> > the database in time for my next workflow step. Perhaps the update<BR>> > process sorts BAPIs to the bottom - :)<BR>> ><BR>> > With greatest repect,<BR>> > Ed<BR>> ><BR>> ><BR>> ><BR>> ><BR>> >> Date: Tue, 12 Jun 2007 14:26:52 +0100> Subject: RE: Commit Work> From:<BR>> >> asap@workflowconnections.com> To: sap-wug@mit.edu> > Hi Ed,> No no no...<BR>> >> By all means post your understandings and reasons, but BAPIs> are most<BR>> >> very very definitively surely absolutely positively (can you see> a<BR>> >> theme here) certainly unquestionably and beyond a shadow of a doubt the><BR>> >> better alternative to creating/changing objects in background.> They are<BR>> >> stable, upgrade-friendly, simpler, more versatile.> > That said, I have<BR>> >> to admit I'm curious what your several reasons are...?> > Cheers,> Mike><BR>> >> > On Tue, June 12, 2007 1:43 pm, Edward Diehl wrote:> >> > Hi Alon,> > I<BR>> >> try to always use a BDC function to create a new object rather than a> ><BR>> >> BAPI. A BAPI, if it is not called as an RFC, required an explicit<BR>> >> COMMIT> > WORK. It may be some defect in my understanding, but I am not<BR>> >> a big fan> > of BAPIs for several reasons and this is just one of them.><BR>> >> >> > Regards,> > Ed Diehl> >> >> > Subject: Commit WorkDate: Mon, 11 Jun<BR>> >> 2007 17:09:57 -0400From:> > araskin@3i-consulting.comTo:<BR>> >> sap-wug@mit.edu> >> > A colleague of mine is having an issue and I<BR>> >> wanted to see if anyone has> > seen this before. I have seen this issue<BR>> >> creep up on different> > implementations so I am sure I am not the first<BR>> >> to handle this.> >> >> >> > Step 1 creates a new document (doesn't<BR>> >> matter what it is, its IS-U) by> > calling a BAPI> >> > The BAPI returns<BR>> >> the ID of the new object which can be seen in the> > container of the<BR>> >> Workflow> >> > Step 2 then calls SYSTEM.GenericInstantiate to get an<BR>> >> instance of the> > newly created document> >> > Step 2 errors claiming<BR>> >> that the object does not exist.> > I suggested to him to uncheck the<BR>> >> Advance with Dialog step as I thought> > that this would 'force' the WF<BR>> >> sub-system to do a COMMIT WORK between> > steps but this did not seem to<BR>> >> work. I was sure that the Workflow> > sub-system always executes a<BR>> >> COMMIT WORK between steps. Is that not the> > case? We did a test, and<BR>> >> created a method where all it did was execute a> > COMMIT WORK. We<BR>> >> inserted this step in between the BAPI and the> ><BR>> >> System.GenericInstantiate and everything worked beautifully. So it is> ><BR>> >> definitely a commit issue. Perhaps WF treats methods marked as BAPIs> ><BR>> >> differently to standard methods and doesn't not do an explicit COMMIT> ><BR>> >> WORK? If so, how do people get around this?> > Regards,> >> >> >> >> ><BR>> >> Alon Raskin> > _______________________________________________> ><BR>> >> SAP-WUG mailing list> > SAP-WUG@mit.edu> ><BR>> >> http://mailman.mit.edu/mailman/listinfo/sap-wug> >> > > -- > Mike<BR>> >> Pokraka> Senior Consultant> Workflow Connections> Mobile: +44(0)7786<BR>> >> 910855> > _______________________________________________> SAP-WUG<BR>> >> mailing list> SAP-WUG@mit.edu><BR>> >> http://mailman.mit.edu/mailman/listinfo/sap-wug_______________________________________________<BR>> > SAP-WUG mailing list<BR>> > SAP-WUG@mit.edu<BR>> > http://mailman.mit.edu/mailman/listinfo/sap-wug<BR>> ><BR>> <BR>> <BR>> -- <BR>> Mike Pokraka<BR>> Senior Consultant<BR>> Workflow Connections<BR>> Mobile: +44(0)7786 910855<BR>> <BR>> _______________________________________________<BR>> SAP-WUG mailing list<BR>> SAP-WUG@mit.edu<BR>> http://mailman.mit.edu/mailman/listinfo/sap-wug<BR><BR></body>
</html>