BAPI Step by step Guidance BAPI stands for Business Application Programming Interface.

There are 5 different steps in BAPI. - Create BAPI Structure - Create BAPI Function Module or API Method. - Create BAPI object - Release BAPI Function Module. - Release BAPI object.

Step1. Creating BAPI Structure: - Go to <SE11>. - Select Data Type & Enter a name. - Click on Create. - Note: Always BAPI should be in a development class with request number (Not Local Object). - Select Structure & hit ENTER. - Enter the fields from your database. Make sure that the first field is the Primary Key Field. - Then SAVE & ACTIVATE.

Step 2. Creating BAPI module: - Enter TR.CODE <SE37>. - Before entering any thing, from the present screen that you are in, select the menu Goto -> Function Groups -> Create Group. Enter a name (Note: This name Must start with ZBAPI)

Let this screen be as it is and open another window and there, enter TR.CODE <SE80). Click on the Third ICON that says Inactive Objects. Select the group that you just created and click on Activate. Notice that the group you created will disappear from the list of inactive objects. - Go back to <SE37> screen and enter a name and hit <ENTER>. Then enter the group name that you just created and activated. NOTE: When you release a function module the respective group will be attached to that particular application. It cannot be used for any other application. NEVER include an already existing group that is attached to another module.

Now click on the first Tab that says [ATTRIBUTES] and select the radio button that says remote-enabled module since we will be accessing this from any external system.

Then click on the second tab that says [IMPORT].

Enter a PARAMETER NAME, TYPE and the structure you created in the first step. Also select the check box Pa. All remotely enabled functional modules MUST be Pa enabled, where Pa means Passed by Value and if you dont select Pa, then that means it will be passed by reference..

Then click on tab that says [EXPORT].

Enter the following as is in the first three fields

RETURN

TYPE

BAPIRETURN (These 3 field values are always same)

Here also select Pa meaning Pass by value.

Note: BAPIRETURN contains structure with message fields.

Then SAVE and ACTIVATE.

Step 3. Creating BAPI object: - Enter Tr.Code <SWO1> (Note. It is letter O and not Zero). - Enter a name and then click on create. Enter details. NOTE: Make sure that that Object Type and Program name are SAME. - Enter Application M, if you are using standard table Mara. If you are using your own database then select Z at the bottom. - Then hit <ENTER>. - Now we have to add Methods. High light METHODS and then select the following from the menu: Goto Utilities -> API Methods -> Add Methods. - Enter function Module name and hit <ENTER>. - Select the second FORWARD ARROW button (>)to go to next step. - Check if every thing looks ok and again click on FORWARD ARROW button (>). - Then select YES and click on <SAVE>. - Now on a different screen goto TR.CODE <SE37>. Enter Function Module name and select from the top menu Function Module -> Release -> Release. - Goback to TR.CODE <SWO1>.

Here select the menu combination shown below in the same order. - Edit -> Change Release Status -> Object Type Component -> To Implemented. - Edit -> Change Release Status -> Object Type Component -> To Released. - Edit -> Change Release Status -> Object Type -> To Implemented.

- Edit -> Change Release Status -> Object Type -> To Released. - Then click on <SAVE>. - Then click on Generate Button (4th button from left hand side looks like spinning wheel). - Then Click on the button that says PROGRAM to see the source code.

To check if this is present in work flow goto TR.CODE <BAPI>. Here it shows business object repository. - First click on the middle button and then select ALL and hit ENTER. - Goto tab [ALPHABETICAL] and look for the object that you created. This shows that the BAPI object has been created successfully. BAPI Conventions Methods Parameters Standardized BAPIs Standardized Parameters Important things to remember.. BAPI/ALE Integration Methods

If the BAPI to be implemented is a standardized BAPI, use the generic names, for example, GetList, GetDetail. The method name must be in English (maximum 30 characters). The individual components of a BAPI name are separated by the use of upper and lower case.Example: GetList

Underscores ("_") are not allowed in BAPI names. Each BAPI has a return parameter that is either an export parameter or an

export table. So that customers can enhance BAPIs, each BAPI must have an ExtensionIn and an ExtensionOut parameter. Parameters

If standardized parameters are used, you have to use the names specified for standardized parameters. BAPI parameter names should be as meaningful as possible. Poorly chosen names include abbreviations and technical names (e.g. "flag", table names, etc.).

The parameter and field names must be in English with a maximum of 30 characters. The components of a parameter name in the BOR are separated by upper and lower case letters to make them easier to read. Example: CompanyCodeDetail Values that belong to each other semantically should be grouped together in one structured parameter, instead of using several scalar parameters. For ISO-relevant fields (country, language, unit of measure, currency), additional fields for ISO codes are provided. Unit of measure fields must accompany all quantity fields and currency identifiers must accompany currency amount fields. Standardized BAPIs

Some BAPIs provide basic functions and can be used for most SAP business object types. These BAPIs should be implemented the same for all business object types. Standardized BAPIs are easier to use and prevent users having to deal with a number of different BAPIs. Whenever possible, a standardized BAPI must be used in preference to an individual BAPI. The following standardized BAPIs are provided:

Reading instances of SAP business objects

GetList ( ) With the BAPI GetList you can select a range of object key values, for example, company codes and material numbers. The BAPI GetList() is a class method. GetDetail() With the BAPI GetDetail() the details of an instance of a business object type are retrieved and returned to the calling program. The instance is identified via its key. The BAPI GetDetail() is an instance method. BAPIs that can create, change or delete instances of a business object type

The following BAPIs of the same object type have to be programmed so that they can be called several times within one transaction. For example, if, after sales order 1 has been created, a second sales order 2 is created in the same transaction, the second BAPI call must not affect the consistency of the sales order 2. After completing the transaction with a COMMIT WORK, both the orders are saved consistently in the database.

Create( ) and CreateFromData( ) The BAPIs Create() and CreateFromData() create an instance of an SAP business object type, for example, a purchase order. These BAPIs are class methods. Change( ) The BAPI Change() changes an existing instance of an SAP business object

type, for example, a purchase order. The BAPI Change () is an instance method. Delete( ) and Undelete( ) The BAPI Delete() deletes an instance of an SAP

business object type from the database or sets a deletion flag. The BAPI Undelete() removes a deletion flag. These BAPIs are instance methods. Cancel ( ) Unlike the BAPI Delete(), the BAPI Cancel() cancels an instance of a business object type. The instance to be cancelled remains in the database and an additional instance is created and this is the one that is actually canceled. The Cancel() BAPI is an instance method. Add<subobject> ( ) and Remove<subobject> ( ) The BAPI Add<subobject> adds a subobject to an existing object instance and the BAPI and Remove<subobject> removes a subobject from an object instance. These BAPIs are instance methods.

BAPIs for Mass Data Processing

The BAPIs listed above for creating and changing data can also be used for mass processing. For more information see BAPIs for Mass Data Transfer [Extern] BAPIs for Replicating Business Object Instances

Replicate( ) and SaveReplica( ) The BAPIs Replicate() and SaveReplica() are implemented as methods of replicable business object types. They enable specific instances of an object type to be copied to one or more different systems. These BAPIs are used mainly to transfer data between distributed systems within the context of Application Link Enabling (ALE). These BAPIs are class methods. Other Less Used Standardized BAPIs

Programming GetStatus() BAPIs [Extern] Programming ExistenceCheck() BAPIs [Extern] Standardized Parameters

There are some parameters that can be created for various BAPIs because they contain the same or the equivalent data in all BAPIs. They should be implemented the same in all BAPIs.

Address parameters Specific reference structures are defined for address parameters in BAPIs. You should copy these structures to use in your BAPI, especially if the underlying object type uses the central address management (CAM). Change Parameters In BAPIs that cause database changes (for example, Change() and Create() BAPIs) you must be able to distinguish between parameter fields that contain modified values and parameter fields that have not been modified. This distinction is made through the use of standardized parameters. Extension parameters The parameters ExtensionIn and ExtensionOut provides customers with a mechanism that enables BAPIs to be enhanced without modifications. Return Parameters Each BAPI must have an export return parameter for returning messages to the calling application. To provide application programmers with a consistent error handling process for BAPI calls, all return parameters must be implemented in the same, standardized way. Selection Parameters Standardized selection parameters are used in BAPIs that can be used to search for specific instances of a business object type (e.g. in GetList() ). These parameters enable the BAPI caller to specify the relevant selection criteria. Test Run Parameters The parameter TestRun is used in write BAPIs (Create() and Change() ), to check the entries for the object instance in the database before actually creating the object instance. The creation of the object instance is only simulated and data is not updated. Text Transfer Parameters To transfer BAPI documentation texts (e.g. the documentation of a business object type), you have to create standardized text transfer parameters.

Important things to remember..

It is important to follow the guidelines below when develop9ng BAPIs: BAPIs must not contain CALL TRANSACTIO or SUBMIT REPORT BAPIs must not invoke a COMMIT WORK. instead use the BAPI TransactionCommit to execute the commit after the BAPI has executed. BAPI structures must not use includes. There should be no functional dependecies between two BAPIs BAPIs must perform there own authorization check BAPIs should not use dialogs BAPIs must not cause the program to abort or terminate. re4levant messages must be communicated through the return parameter. BAPI/ALE Integration

When you use the BAPIs for asynchronous messagning, the application in the sendig systen calls the generated ALE IDoc interface isntead of the BAPI. Asynchronous BAPIs use the ALE interface this way:

Creates an IDOC from the BAPI data Sends the IDOC to the target system Receives the IDOC in trhe target system, crreates the BAPI data from the IDoc and calls the BAPI An ALE interface for a BAPi is created in transaction BDBG.

What is the different between ALE, IDOC and BAPI? ALE

ALE is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems. When a new enterprise resource planning (ERP) solution such as R/3 is implemented, companies have to interface the ERP system with legacy systems or other ERP systems.

ALE provides intelligent mechanisms where by clients can achieve integration as well as distribution of applications and data.

ALE technology facilitates rapid application prototyping and application interface development, thus reducing implementation time.

The ALE components are inherently integrated with SAP applications and are robust, leading to a highly reliable system.

ALE comes with application distribution/integration scenarios as well as a set of tools, programs, data definitions, and methodologies that you can easily configure to get an interface up and running.

BAPI

BAPIs provide a stable, standardized method for third-party applications and components to integrate into the Business Framework. These interfaces are being specified as part of SAP's initiative with customers, partners and leading standards organizations. Also, SAP has implemented the emerging Object Application Group (OAG) specifications with BAPIs.

Pros and Cons for both BAPI and Call Transaction

BAPI One of the big plusses for BAPIs is that the interface and function are not supposed to change. This is a big plus when you do upgrades or hot packs

because the transaction can change (format, required inputs etc) which means you then need to update the call transaction.

Some of the BAPIs are better documented and easier to use than others.

You usually need to perform the BAPI that actually does the COMMIT after you call your BAPI.

The Program coding for calling a BAPI is usually cleaner than setting up the screen flow etc for the Call Transaction.

You don't need to worry about special data circumstances interrupting the normal data flow of the screens and causing errors because of that.

BAPIs probably have better performance since they don't do the screen flow processing.

In general if the BAPI exists for the transaction you want to perform and you can figure out how to use it the BAPI is probably the best way to go.

This is just from my experience working with both BAPI and Call Transaction. I have had some very good successes with BAPIs, but very occasionally found that I could not get the BAPI to perform the update I needed.

ABAP Tips by: Heather R Woytash

The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an

RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.

IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always an asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact, that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one of the message steps.

While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. Such a set-up is called an ALE-scenario.

The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data. The difference is made clear, when we think of a purchase order that is sent as an IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order. However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the purchase order also as a purchase order.

Differences Between BDC and BAPI What the difference between BDC and BAPI? What the exact situation where we can use BDC and BAPI?

BDC is the good old method of moving legacy data to SAP. BAPI is the new enhanced Application Interface through which data can be uploaded into SAP System. BDC is transaction oriented. Meaning, the data is uploaded into SAP through standard transactions. All checks, validations,exits that are applicable to the transaction are active while loading data into SAP. Simply saying, BDC is continuous running of transaction repeatedly without human intervention, data being picked from text file for each run. It is just a bundling of multiple executions of the same transaction and execute at once like a macro. Whereas BAPI is an interfacing method, through which SAP data can be processed from within SAP or from other non-SAP applications. BAPI can be termed as SAP transaction without dialog. All the screens of particular transaction is converted in the form of a Code Module. We can establish on-line interface with SAP data from non-SAP applications through BAPI's if they are enabled for Remote Access. Generally BDC is preferred if the data from the legacy system is moved to SAP single time. For example, at the time of Go-Live the data required for SAP is either downloaded from other software or manually prepared in excel sheets and uploaded into SAP at once. After that data or SAP has nothing to do with other software. BAPI's are preferred, if data exchange is online or continuous between SAP transactions or SAP and non-SAP applications. BAPI's are preferred in view of performance also. Data loading through BAPI's are more robust and faster comparatively, if they are called correctly. differences between IDOCs and BAPIs.

BAPIs in 3.1 are synchronous; in 4.+ they can be asynchronous (and I believe they then drive certain ALE/IDOCs).

BAPIs are called from the outside-in. That is, an external program invokes a BAPI that gets data from SAP to display or updates data in SAP. The BAPI concept does not include an event concept -- you cannot

tell SAP that when certain events happen to a "business object", to fire a message or a file to an external system.

BAPIs are invokable from Java or C/C++ or Visual Basic (and I think some people are using Delphi).

In 3.1x there are very few BAPIs to use. In 4.+ SAP has added a large number.

BAPIs are not totally immune to upgrades but if they are to be retired you supposedly will have them supported for two releases. Whether those are point or letter releases, I don't know. I believe that IDOCs may be more changable from release to release.

BAPIs are reasonably well documented and there is a common place to look to see what is available. IDOCs -- I have heard -- are poorly documented in terms of finding them, and IDOCs were done differently by different groups in SAP.

BTW, you can also use Java, C/C++, Visual Basic, ... to invoke RFCs in SAP and get or update data. That's how the BAPIs work since they utimately are sets of RFC calls (written to a design spec for BAPIs)

why a BAPI is faster than a call transaction?. E.g. If i have the BAPI: create_sales_document and I could also do a call transaction to va01. Wich one is better?. Why?.

A BAPI is faster because it is updating the DB "directly" through ABAP code. A BDC with call transaction goes through the whole screen sequence like any user would do, simply put, it is filling screens DIFFERENCE B/W COMMIT WORK and BAPI_TRANSACTION_COMMIT Commit work is used when you code directly in ABAP and make changes in the database and want to commit the database. BAPI_TRANSACTION_COMMIT is used when you make changes to the SAP database by calling a BAPI from outside SAP and want to commit the database. When you use a BAPI, you can not directly use commit work, instead you are allowed to use only BAPI_TRANSACTION_COMMIT.

Difference Between BAPI and RFC What is the main difference between BAPI and RFC and difference between BAPI and BDC?

BAPI is used only when it is available for the particular transaction like Delivery Sales order. but BDC can be used for any transaction which have screen and fields.

BAPI is directly updated the database instead BDC run through the screen flow.

So BAPI can't handle all the flow logic checking and enhancement put by programmer to faciliate the user requirement.

Difference between BAPI and BDC:

BAPI is a higher end usage for tranfering the data from SAP to non-SAP and vice-versa. for ex: if we are using VB application,where in that we want to connect to SAP and retireve the data,and then change and update the data in SAP for that purpose we can use that.

Apart from that, we can also use it for Uploading/Downloading the data from SAP to Non-SAP like BDC, provided we have an existing BAPI for that.

BAPI function modules will also do all the checks required for data integrity like Transactions for BDC.

There is one more advantage using BAPI instead of BDC. When we go for upgradation, there might be pozzibility to change the screen elements for transactions depending on the requirement. In that case,our BDC pgm may or may not work (depending on the screen changes they have made). Unless and until we prepare new BDC we cant use the old BDC pgm. But in BAPI, SAP promises that they are going to keep the old BAPI and for new functionality they will provide an upgraded BAPI. Until we write a new BAPI pgm, we can use the exisitng BAPI pgm.

How to Find Bapi for Particular Transaction in SAP How to find function module or Bapi for particular transaction in sap?

If you mean that you need to know what BAPI's a particular tranx uses, which I can only assume that's what you mean, then you should access the code behind the transaction and search for 'CALL'. That normally is the standard method that think that most people use.

Suppose you want to find the bapi for creating a sales order, you usually use transaction VA01 for this.

1. Find out the package of the transaction. Start Va01 go to system --> status. Double click on transaction Package is VA Open this package in SE80 Open business engineering-->Business object types Find the BO which sounds the most appropriate I would suggest BUS2032 Sales Order Double click. Open methods. Find the released method with from data or something similar in the name , Createfromdat2 Position the cursor in it and click the program button Scroll down to find the bapi used in this method

With this way you can also find out programs and FM's

2. Start va01 go to system-->status Double click transaction VA01 Double click on package Read the application component. (this is SD-SLS Sales) Then open the transaction BAPI Sales and distribution-->Sales-->sales order createfromdat2

Material Master creation/change BAPI_MATERIAL_SAVEDATA

I am trying to retrieve all material in the SAP system, but the only Business object I have found (Material) requires a key (Material Number)I can not force it to retrieve all materials Is there is a way I can use to retrieve all materials you have to use the Method MATERIAL.GETLIST. It gives you the material numbers of all your material. Then you have to get the detail material data with MATERIAL.GETDETAIL(material number).

MATERIAL ( BUS1001 ) is a Business Object in the BOR.