about BAPI

[Former Member]

Hi Team ,

I need to create a BAPI.

what I know about BAPI is it is a Function Module which is

RFC enabled..

But I don't know the proper steps how to create a BAPI assign it to BOR and that stuff.

Can anyone Plz provide me some documentation or step by step process of how to create a BAPI .

Thanks & Regards ,

PAVAN.

[Former Member]

Hi Pavan ,

search in this Forum itself.

Tcodes: SWO1,BAPI,SE37

Implementation Project for New BAPIs 
This form will guide you through all the work steps necessary for implementing BAPIs. It also enables you to create a checklist to document the steps as you complete them, thereby providing you with a record of the creation process for your BAPI.  
Complete this form for each of your projects. One project may cover either a single BAPI, or several BAPIs within the framework of one scenario. However, there must only be one person responsible for each project.  

Overview: 

Project Organization 
Scenario Analysis 
BAPI Design 
Defining BAPI Data Structures 
Creating BAPI Function Modules 
 Defining BAPI Methods in the BOR 
Documenting BAPIs 
BAPI/ALE Integration - Generating IDocs 
ToDo Checks and Tests 
Release 
 
 

 

 Project Organization 
 
Project name  
 
Person responsible for project  
 
Quality Manager  
 

 

 Scenario Analysis 
BAPIs are always implemented as part of an integration scenario. This ensures that the various BAPIs complement each other and provide structured, focused access to SAP functionality. 
When analyzing the scenario, you must answer the following questions:  

What requirements need to be met?  
How can the business process be described in business terms? (= business process description)  
How can the business process be described in software terms? (= scenario description)  
Which business objects are affected? Can you use an existing object model?  
Which methods (BAPIs) are required? 
You can find further information in the BAPI Programming guide under 'Analysis' 

 
 
Name of the ALE integration scenario  
 
 Object model exists. 
 
The following BOR methods (BAPIs) must be implemented for the scenario: 
Business Object Method (BAPI) Function module 
   
   
   
   
   
 
 

 

 BAPI Design 
During the design phase, you must define the BAPI signature at a conceptual level. Then describe the contents of the BAPI and specify the parameter names and parameter structure. You can find detailed information on the design phase in the BAPI Programming guide under 'Designing the BAPI'. 
During the design phase, you must bear in mind that there is a series of standard methods and parameters that provide certain basic functions. If the BAPIs you want to implement and their parameters are included in this category, then you must adhere to the relevant guidelines. You can find an overview in the BAPI Programming guide under 'Standardized  BAPIs' and under 'Standardized Parameter'.

When you are working on the implementation of a BAPI, you must consider whether, based on its functionality, it is an instance method or a class method.

Instance methods refer to a specific instance of a business object; for example, the SalesOrder.GetDetail  BAPI displays the detailed data for precisely one sales order (which you must specify). Such methods are defined as instance-dependent in the BOR.  Class methods do not refer to a specific instance of a business object; for instance, the SalesOrder.GetList BAPI gets a list of all available sales orders that fulfill certain criteria. Class methods include standardized create methods. Create methods are used to create new instances; for example, the SalesOrder.Create BAPI creates a new sales order in the SAP System. Such methods are defined as instance-independent in the BOR.  

You must adhere to the following conventions for BAPI methods:
 
 You must establish whether you are dealing with an instance method or a class method. 
 
 The method name must be in English (maximum 30 characters). 
 
 The individual name components of BAPI names are marked by initial capital letters. Underscores ("_") are not permitted in BAPI names.  
 
 Every BAPI must have a return parameter that is either an export parameter or an export table. 
 
 Every BAPI must have an ExtensionIn and an ExtensionOut parameter to enable customer enhancements.
You can find further information on customer enhancements of BAPIs in the document titled 'Customer Enhancement and Modification of BAPIs'. 
 
The following conventions are valid for parameters: 
 
 The parameter and field names must be in English (maximum 30 characters). 
 
 The individual name components of parameter names are marked by initial capital letters to ensure maximum readability. 
 
 Fields that are ISO-relevant (country, language, quantity, currency) have additional fields for ISO codes. 
 
 You must include quantity unit fields for all quantity fields, and currency descriptors for all currency amount fields. 
 
 

 

 Defining BAPI Data Structures 
You must now define, in the ABAP Dictionary, all data structures (including domains and data elements) that are required for the parameters of the BAPI to be implemented. You can find further information on defining BAPI data structures in the  BAPI Programming guide under 'Actions in the ABAP Dictionary'. ABAP Dictionary (SE11) 
The following conventions are valid in this phase: 
 
Conventions for BAPI data structures: 
 
 Each parameter must refer to a data structure in the ABAP Dictionary. For structured parameters, this is always the overall BAPI data structure. However, if the parameter consists of only one field, then it must refer to a field in a BAPI data structure.  
 
 You must create specific data structures for BAPIs, which must be independent of the data structures that are used generally in SAP applications. 
Tool: existing internal structures can be mapped to existing BAPI structures using a module to map fields that is automatically generated by a mapping tool (Transaction BDBS). 
Mapping Tool  
 
 All data structure names must begin with < namespace > BAPI.  
 
 You must not use APPENDs or INCLUDEs in BAPI data structures.  
 
Conventions for field names. 
 
 Fields in structures must have easily understandable English names that are no longer than 30 characters.
Tool: Internally at SAP, you can use the BAPIFELD report to create a list of proposals for English field names for an ABAP Dictionary structure. You can find a description of how to use this report in the report documentation. 
Report BAPIFELD 
 
 You must also create an easily understandable English default name that is no longer than 30 characters for each data element. This name then becomes the proposal always given by the BAPIFELD SAP internal report.
Tool: The BAPIFELD report shows which data elements still need to be processed. Enter the default field name for the data element in the ABAP Dictionary using Definition ® Default field name. 
Report BAPIFELD 
 
Conventions for Input Help 
 
 Individual values or a value table may be maintained for a domain, which enables you to use the F4 help.  
 
 All useful input help (that can be used with the HelpvaluesGetList service BAPI) must be maintained for the data structures/data elements.
To do this, you must specify foreign keys for the fields of a BAPI structure. If a value table has been defined for a field domain, then a foreign key is mandatory.  
 
Technical Conventions 
 
 Internal data presentation is used for all parameters. 
Tool: 
Mapping Tool  
 
 If both an internal and an external key are stored in the database, then the external key must be used for the BAPI interface.  
 
 Field that are ISO-relevant (country, language, quantity, currency) have additional fields for ISO codes.  
 
 All currency fields use the BAPICURR domain. In special cases you can also use the BAPICUREXT domain.  
 
 You must always use a decimal point.  
 
 All quantity and currency amounts must have the decimal point in the correct place.
Reason: BAPIs always have standardized amount representations with decimal points. Therefore you must use function modules BAPI_CURRENCY_CONV_TO_EXTERNAL and BAPI_CURRENCY_CONV_TO_INTERNAL to convert currency amounts. .  
 
 For quantity fields, the reference field/reference table must be set correctly to the quantity unit field.  
 
 All data elements for date fields have the format YYYYMMDD.  
 
Conventions for BAPI/ALE Integration 
 
 BAPI structure names must not be longer than 27 characters, otherwise the automatically generated segment name will be too long and will require manual correction.  
 
 Individual fields in a data structure have a maximum length of 250 bytes.  
 
Conventions for Customer Developments 
 
 IBUs, partners and customers must always observe the namespaces defined by SAP when creating data structures (domains or data elements).  
 
 

 

 Creating BAPI Function Modules 
Once the parameters have been defined, the function module on which the BAPI is based is implemented in the Function Builder (Transaction SE37). Function Builder (SE37)  
When creating this module, you must observe the following rules: 
 The BAPI is a transactional BAPI.
For more information see the BAPI Programming guide under 'Transaction Model for Developing BAPIs'. 
 
 All function modules must correspond to the following naming convention: BAPI_<Business-Object>_<Method>. 
A maximum of 30 characters is permitted. If you need to, you can use abbreviations that correspond to the above convention, as long as the assignment to the business object remains clear. 
 
 All BAPIs for one SAP business object type should be summarized to a function group. 
You should only deviate from this rule in exceptional cases. 
 
 BAPIs for different object types must not be summarized to a function group.  
 
Interface Definition 
A BAPI parameter must be defined both in the function module and in the method for that business object type in the BOR. The definitions must be identical in both cases, excepting only the key fields of the business object type.

You can find further information on interface definition in the BAPI Programming guide under 'Defining the interface'.

The following conventions are valid for key fields with function module interfaces :
 
 
 For instance methods, all BOR key fields are mandatory import parameters in the function module. BOR key fields cannot be export parameters in the function module.  
 
 For class methods, BOR key fields cannot be export parameters in the function module (exception: create methods). BOR key fields also cannot exist as import parameters in the function module.  
 
 For create methods, all BOR key fields for that method are export parameters in the function module. BOR key fields (as for all class methods) cannot be import parameters in the function module. Create methods are defined as instance-independent in the BOR.  
 
If key fields occur as parameters in function modules, then you must observe the following conventions: 
 
 You must use the fully defined key, not the partial key.             
 
 Each key for the business object type has its own parameter in the function module.  
 
 The function module parameter and the BOR key field have the same name. (Underscores ("_") are not allowed in the parametername in the Functuin Builder.) 
 
You must also observe the following conventions for function module interfaces: 
 
 In the Function Builder only capitalization is used. Because of this underscores ("_") are allowed and recommended in order to mark the individual name components of parametername. (Example: ExtensionIn, in the Function Builder: EXTENSION_IN).  
 
 You must use the BAPIPAREX structure for parameters ExtensionIn and ExtensionOut.  
 
 You must base the return parameter on structure BAPIRET2.  
 
 The function module must be RFC-capable.  
 
Implementing the Function Module 
The most important BAPI-specific requirements for function module coding are as follows: 
 
 
 A BAPI must not execute a  COMMIT-WORK command. 
 
 The database can only be changed by updating.  
 
 A BAPI cannot display anything on the screen, that is, it cannot create lists, queries or dialog boxes.
This is valid not just for the BAPI itself, but also for all function modules called indirectly from the BAPI.  
 
 You cannot use exceptions in a BAPI.
Instead, all error messages are returned to the calling program using the standardized parameter Return.  
 
 A BAPI itself cannot cause program termination, it can only return the corresponding message (message type A, termination message) in the return parameter.  
 
 You must provide customer exits to enable customer enhancements of BAPIs.
You can find further information on customer enhancements of BAPIs in the document titled 'Customer Enhancement and Modification to BAPIs'.  
 
You can find a comprehensive overview of all requirements that you must meet in the  BAPI Programming guide under ' Implementing the Function Module'. 
 
 

 

 Defining BAPI Methods in the BOR 
Once the implementation of the function module is complete, you must define the BAPI as a business object method. This not only enables central storage in the Business Object Repository (BOR), but also object-oriented access to the BAPI and the option to link to the ALE distribution model (for ansychronous BAPIs). BOR (SWO1)

Use the BOR/BAPI Wizard to implement the BAPI as a method in the BOR. This automatically generates the BOR method from the function module. In the BOR, first choose the change mode for the object you are working on and then the menu path:  

Utilities ® API methods ® Add method

Follow the steps in the wizard. You will have to complete a few additional tasks in the wizard. Note the following points in particular: 
 
 Initial capital letter for each word. 
 
 Ensure that the import and export behavior of the table parameters is correctly maintained in the BOR.
Reason: Unlike function modules, in the BOR you can differentiate between import and export for tables. You should only choose Import/Export if the table has actually been imported or exported.  
 
 The return parameter must always be defined as export.  
 
Apart from simplifying the tasks, the wizard also ensures that the BAPI interface is identical in both the BOR and the function module. This is particularly important for the following aspects: 
 
 For every function module parameter there is a BOR parameter (or a key field) with the same name (and vice versa).  
 
 These two parameters refer to the same ABAP Dictionary structure.  
 
 These two parameters have the same characteristics (mandatory or optional, import, export or table parameters).  
 
Note: If you cannot use the BOR/BAPI wizard (for example, if you are changing the BAPI at a later date or redefining a method), work on the method in the BOR itself. If you are doing this, you must take particular care to observe the points listed above. BOR (SWO1)

IBUs, customers and partners must also observe the following additional points:
 
 
 You must read the document titled 'Customer Enhancement and Modification to BAPIs'.  
 
 As a customer you can create your own BAPIs for your own business object types, or you can define a subtype for an existing SAP business object type. You must not define new BAPIs for SAP business object types, since this constitutes a modification.
See 'Customer Enhancement and Modification to BAPIs' for details.  
 
 You must create all development objects (business object types, BAPIs and parameters) in your own namespace.  
 
 

 

 Documenting BAPIs 
For the BAPI  to be used correctly (particularly by users outside the SAP System) you must provide all relevant information in the documentation.  
BAPI documentation is automatically transferred from the function module documentation. Create comprehensive raw documentation for each BAPI and each parameter in the Function Builder (SE37). This will then be processed by the documentation developers. You can find further information on BAPI documentation in the BAPI Programming guide under 'BAPI Documentation'. 
 
 All BAPIs and all parameters are fully documented. 
 
 The return parameter documentation contains all relevant error messages.  
 
 The documentation developer then saves the active version of the function module and parameter documentation 
(otherwise the documentation cannot be translated). 
 
 The business objects have been documented in the BOR.  
 

 

 BAPI/ALE Integration - Generating IDocs 
BAPIs are integrated into the ALE distribution model. ALE distribution is asynchronous and based on messages. ALE distribution is the preferred means of integration for distributed SAP Systems, for instance, for distributing master data.
As of Release 4.0, BAPIs are the standardized interfaces for ALE-supported distribution. ALE services, such as asynchronous calls, use of the distribution model, monitoring and error processing, can all be used for BAPIs. The IDocs required for ALE services can be generated from the BAPIs.
 
 Message types are created and IDocs are generated for all write BAPIs. 
Generate ALE Interface for BAPI (BDBG)   
 
 All IDocs are released.
Releasing IDocs is currently linked to authorizations.  
 
 The BAPI interface and the IDoc interface are identical. 
Ensure that, when you have changed a BAPI, the message type, the IDoc type and the segments are regenerated.  
 
You can find further information in the document titled 'Using ALE-Services'.  
 

 

 ToDo Checks and Tests 
You must run special tests and carry out ToDo checks in order to ensure that the BAPIs, the business object types and the documentation are correct. 
You can find further information on the test phase in the BAPI Programing guide under 'Testing and Releasing'. 
 
 A ToDo check has been carried out for the BAPIs and no messages with priority 1 or 2 were displayed. 
 
 he single test and the integration test were successful. 
 
 The documentation has been checked for completeness and clarity. 
 

 

 Release 
Once all the tests have been completed successfully, the BAPIs and all related development objects must be released in order for them to be available to the customer. This can happen once the following conditions have been met: 
 All required documentation has been created. 
 
 No consistency errors were found. 
 
You must carry out the following steps when releasing a BAPI: 
 
 Release the BAPI function module (in the Function Builder). 
 
 Release the business object type (in the BOR). 
 
 Release the BAPI as a method in the BOR.  
 
 For potential write BAPIs: Release the IDoc and its segments. 
 

regards

Prabhu

[dani_mn]

http://www.sappoint.com/abap.html

http://www.sapbrain.com/TOOLS/default.html

Regards,

Wasim Ahmed

[Former Member]

hi

Check out the link

http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html

http://www.sap-img.com/bapi.htm

Regards,

Richa

[Former Member]

hi,

share your mail id i will send you the docs with screen shots

Nandha

[Former Member]

Hai Pavan

Bapi to create customer master

-

---

BAPI_CUSTOMER_CREATEFROMDATA

BAPI_CUSTOMER_CREATEFROMDATA1

Or you can use FM SD_CUSTOMER_MAINTAIN_ALL

what is BAPI?

BAPI stands for Business API(Application Program Interface).

I have answered this question before..

A BAPI is remotely enabled function module ie it can be invoked from remote programs like standalone JAVA programs, web interface etc..

You can make your function module remotely enabled in attributes of Function module but

A BAPI are standard SAP function modules provided by SAP for remote access. Also they are part of Businees Objest Repository(BOR).

Please check out this thread..

Also refer to the following links..

www.sappoint.com/abap/bapiintro.pdf

www.sap-img.com/bapi.htm

www.sap-img.com/abap/bapi-conventions.htm

www.planetsap.com/Bapi_main_page.htm

www.sapgenie.com/abap/bapi/index.htm

Checkout !!

http://searchsap.techtarget.com/originalContent/0,289142,sid21_gci948835,00.html

http://techrepublic.com.com/5100-6329-1051160.html#

http://www.sap-img.com/bapi.htm

http://www.sap-img.com/abap/bapi-conventions.htm

http://www.sappoint.com/abap/bapiintro.pdf

Java Connector(JCO) can call not only BAPI's but also the function modules which are remotely enabled..

BAPI's as i said earlier are remotely enabled function modules..

Hence, JCO can call also BAPI's(n not only BAPI's as u mentioned).

The steps to be followed are :

1. Find out the relevant BAPI (BAPI_SALESORDER_CHANGE for VA02).

[for VA01 use BAPI_SALESORDER_CREATEFROMDAT2]

2. Create a Z program and call the BAPi (same as a Funtion module call).

2. Now, if you see this BAPi, it has

-> Importing structures.

eg: SALESDOCUMENT: this will take the Sales order header data as input.

-> Tables parameters:

eg: ORDER_ITEM_IN: this will take the line item data as input.

Note :

Only specify fields that should be changed

Select these fields by entering an X in the checkboxes

Enter a U in the UPDATEFLAG field

Always specify key fields when changing the data, including in the checkboxes

The configuration is an exception here. If this needs to be changed, you need to complete it again fully.

Maintain quantities and dates in the schedule line data

Possible UPDATEFLAGS:

U = change

D = delete

I = add

Example

1. Delete the whole order

2. Delete order items

3. Change the order

4. Change the configuration

Notes

1. Minimum entry:

You must enter the order number in the SALESDOCUMENT structure.

You must always enter key fields for changes.

You must always specify the update indicator in the ORDER_HEADER_INX.

2. Commit control:

The BAPI does not run a database Commit, which means that the application must trigger the Commit so that the changes are read to the database. To do this, use the BAPI_TRANSACTION_COMMIT BAPI.

For further details... refer to the Function Module documentation for the BAPi.

Thansk & regards

Sreeni