BAPI's in workflow

[Dart, Jocelyn]

Hi Ignasi/Mark,
 
Re BAPIs not having access to all table fields especially customer
extensions, check your release and BAPI for the use of
BAPI EXTENSION PARAMETERS.
 
This is a relatively new concept but it is gradually being added to more
and more BAPIs.  Basically it allows you to use optional parameters
to nominate additional fields to be passed which will automatically be
applied to underlying tables.   It's simple to use, but there are
restrictions as of course the underlying tables to which you can
talk depend on which BAPI you are using.  However they are great for
handling customer extension fields and other fields which are normally
not accessible via the BAPI - thereby helping to cut down the follow
up work.   Particularly useful where you have used standard user exits or
append
structures to make additional fields available or mandatory, but the
technique
does allow you to pass in standard SAP fields which aren't normally
accessible via
the BAPI parameters also.
 
Look for BAPI parameters called EXTENSIONIN or EXTENSIONOUT and check
for matching OSS notes specifying the details per BAPI, e.g. OSS note
336589 for purchase order BAPI.
 
Peter is correct in saying that BAPIs are more about interfacing than
workflow.  However they are usually more efficient and reliable than
doing a "CALL TRANSACTION USING" in your methods.  You do need to read
up on them, for instance, some require an explicit commit process.
Best resource is http://sapnet.sap.com/bapi.
 
For myself, with regard to workflow I use them within a method in the same
way that I would use a function module or CALL TRANSACTION USING in a
method,
i.e. create a method to accept my workflow parameters, set up the parameter
structures for the BAPI(s), call the BAPI(s), analyse any error return from
the BAPI(s),
send out an appropriate business object exception.  It's not uncommon that
one business task may involve calling multiple BAPIs.  It's your choice
whether
you call the BAPI as a function module or as a method of a business object.
 
It's all grist to the mill.
Regards,
        Jocelyn Dart
Consultant (BBP, Ecommerce, Internet Transaction Server, Workflow)
SAP Australia
Email jocelyn.dart at sap.com <mailto:jocelyn.dart at sap.com>
Tel: +61 412 390 267
Fax: +61 2 9935 4880
 
 
 
-----Original Message-----
From: Mark Huffman [mailto:m.r.huffman at worldnet.att.net]
Sent: Friday, 29 December 2000 7:29 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: BAPI's in workflow
 
 
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.
> **********************************************************************