<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Hi Mike, et al,<BR>
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. <BR>
<BR>
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. <BR>
<BR>
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 - :)<BR>
<BR>
With greatest repect,<BR>
Ed <BR>
<BR>
<BR>
<BR>
<BR>
<BR>> Date: Tue, 12 Jun 2007 14:26:52 +0100<BR>> Subject: RE: Commit Work<BR>> From: asap@workflowconnections.com<BR>> To: sap-wug@mit.edu<BR>> <BR>> Hi Ed,<BR>> No no no... By all means post your understandings and reasons, but BAPIs<BR>> are most very very definitively surely absolutely positively (can you see<BR>> a theme here) certainly unquestionably and beyond a shadow of a doubt the<BR>> better alternative to creating/changing objects in background.<BR>> They are stable, upgrade-friendly, simpler, more versatile.<BR>> <BR>> That said, I have to admit I'm curious what your several reasons are...?<BR>> <BR>> Cheers,<BR>> Mike<BR>> <BR>> On Tue, June 12, 2007 1:43 pm, Edward Diehl wrote:<BR>> ><BR>> > Hi Alon,<BR>> > I 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 COMMIT<BR>> > WORK. It may be some defect in my understanding, but I am not a big fan<BR>> > of BAPIs for several reasons and this is just one of them.<BR>> ><BR>> > Regards,<BR>> > Ed Diehl<BR>> ><BR>> ><BR>> > Subject: Commit WorkDate: Mon, 11 Jun 2007 17:09:57 -0400From:<BR>> > araskin@3i-consulting.comTo: sap-wug@mit.edu<BR>> ><BR>> > A colleague of mine is having an issue and I wanted to see if anyone has<BR>> > seen this before. I have seen this issue creep up on different<BR>> > implementations so I am sure I am not the first to handle this.<BR>> ><BR>> ><BR>> ><BR>> > Step 1 creates a new document (doesn't matter what it is, its IS-U) by<BR>> > calling a BAPI<BR>> ><BR>> > The BAPI returns the ID of the new object which can be seen in the<BR>> > container of the Workflow<BR>> ><BR>> > Step 2 then calls SYSTEM.GenericInstantiate to get an instance of the<BR>> > newly created document<BR>> ><BR>> > Step 2 errors claiming that the object does not exist.<BR>> > I suggested to him to uncheck the Advance with Dialog step as I thought<BR>> > that this would 'force' the WF sub-system to do a COMMIT WORK between<BR>> > steps but this did not seem to work. I was sure that the Workflow<BR>> > sub-system always executes a COMMIT WORK between steps. Is that not the<BR>> > case? We did a test, and created a method where all it did was execute a<BR>> > COMMIT WORK. We 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?<BR>> > Regards,<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > Alon Raskin<BR>> > _______________________________________________<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>