BAPI's in workflow

[Mark Huffman]

I have wrestled with BAPIs within methods for much of this past year and
have a few comments to add:
 
Usually a BAPI will require one or more large structures as input
parameters. I find it better to populate the structures in one step and
then call the create/change bapi in following step. One benefit is that
this allows better error handling and to some extent you can evaluate
your container elements with standard workflow steplogs (though that
also seems to be a problem with large structures - maybe someone else
has some advice on that point).
 
Be aware that the BAPI may not do everything that you need - either the
SAP developers have not included all table fields in the structures, or
your team may have added extensions to the underlying tables (adding US
centric fields like SSN is a common example). So in this case, although
you may want to call the BAPI to do the heavy work of creating the
master data - there may be follow on steps to update the master data.
There are various ways of handling this.
 
For some BAPIs, it may be useful to look at the real function module
that actually creates/changes the master data. Sometimes this is
straightforward and sometimes it isn't. For example, in the ISU area, we
found that it was often easier to call the ISU function module directly
from within the method, rather than "fiddling" with what the BAPI
allowed.
 
caveat emptor,
 
Mark
Roehlen, Peter wrote:
>
> Hi Ignasi,
>
> I don't know about your second question, but here are some thoughts on the
> first:
>
> - BAPIs are just a business object type method that conform to a particular
> convention.  Ie all BAPIs are busines object type methods, but not all
> methods are BAPIs.
> - BAPIs primarily provide a useful interface for external systems to access
> SAP functionality in an object oriented (OO) type way.  Eg creating an SAP
> Sales Order from MS Excel etc.
>
> BAPIs used in workflow steps have the following restrictions that other
> methods may not:
> - they are never (at least in principal) dialog steps and therefore are
> effectively only good for background processing.
> - they are not supposed to handle the complete transaction (ie a seperate
> method call to commit the transaction is required).
>
> I suspect that BAPIs as a technology grew more out of the desire for a
> better way of interfacing SAP with external systems than as anything to do
> with workflow.
>
> As a workflow developer, you would only use a BAPI if it was appropriate (ie
> your step can run in background etc.)  As a business object type developer,
> you would only make a method a BAPI if the requirements of the method fit in
> with the BAPI conventions.
>
> Cheers
>
> Peter Roehlen
> Team Lead - SAP Technical & Development
> Powercor Australia Ltd
> (03) 5430 4704 / 0409 950 263
>
> -----Original Message-----
>> From: Aliana Portugal, Ignasi [mailto:IAliana at fecsa.es]
> Sent: Tuesday, 19 December 2000 2:19
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: BAPI's in workflow
>
> Hi,
>
> 2 questions:
>
> 1) Does anybody know what are the BAPI's used for in workflow and what's de
> difference between a method based on a BAPI and a method that isn't?
>
> 2) Which one is the table that contains all the inbox documents (the
> workflow table and the office table)?
>
> Thanks.
>
> Ignasi Aliana (PWC)  -  SIE2000
> Centro de Soporte de WF / CA
> ialiana at fecsa.es / 93 6002490
> **********************************************************************
> Powercor Australia Ltd. This email and any file attachments are
> confidential and intended solely for the use of the individual or
> entity to whom they are addressed. If you have received this email in
> error please tell us immediately by return email and delete the
> document.
> **********************************************************************