difference between BAPI and IDOCs

[Former Member]

What is the difference between BAPI and IDOC. When to use BAPI and when to use IDOC?

[Former Member]

I got it from this link.

http://www.saptechies.com/difference-andor-similarities-between-bapi-and-idocs/

There are many differences between IDOCs and BAPIs.

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 firea message or a file to an external system.

BAPIs are invokable from Java or C/C++ or Visual Basic

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 thoseare 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. IDOC 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).

Regards,

Maha

[Former Member]

Hi Eashwar,

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.

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.

[Former Member]

BAPI

BAPI (Business Application Programming Interface) is an API method of a business object which intern is a RFC enabled Function Module.

Business Objects are the Objects which has business sence associated to it. Ex. Sales Orders, Purchase Orders etc.

The Properties of BAPI are:

Every BAPI name should start with letters 'BAPI'.

It is an API method of a Business Object.

it does not contain a internal COMMIT statement in the Function Module.

It does not contain "CALL TRANSACTION" statements.

BAPI do not raise 'EXCEPTIONS'.

a RETURN structure is defined as an interface parameter of a BAPI which is used to log all the errors, warnings and the successful processes tha are triggered in the course of execution of a BAPI.

A successful execution of a BAPI requires the data to be commited and this process of performing a COMMIT is achieved by calling the BAPI_TRANSACTION_COMMIT' explicitly if there are no errors logged in the RETURN structure.

There are two types of BAPI's: Instance Dependent & Instance Independent.

BAPI provides an access to the SAP system for external applications to have the business data processed in the form of web services. When BAPI's are used to post the data in SAP system these are used as Function Modules.

for further information check following:

Go to the below link for BAPI.

http://help.sap.com/saphelp_nw04/helpdata/en/e0/9eb2370f9cbe68e10000009b38f8cf/frameset.htm

BAPI

http://help.sap.com/saphelp_nw2004s/helpdata/en/7e/5e114a4a1611d1894c0000e829fbbd/frameset.htm

http://www.sapgenie.com/abap/bapi/example.htm

http://help.sap.com/saphelp_46c/helpdata/en/9b/417f07ee2211d1ad14080009b0fb56/frameset.htm

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

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

http://www.sapgenie.com/abap/bapi/example.htm

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDAPII/CABFAAPIINTRO.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFABAPIREF/CABFABAPIPG.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE8/BCFESDE8.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFABAPIREF/CABFABAPIPG.pdf

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDAPII/CABFAAPIINTRO.pdf

ALE Architecture:

It consists of an Outbound process, an Inbound process, and an Exception – Handling process.

Outbound Process:

ALE Outbound Process in SAP sends data to one or more SAP Systems. It involves four steps.

1. Identify the need of IDoc: This step starts upon creating a application document, can relate to a change to a master data object.

2. Generate the Master IDoc: The document or master data to be sent is read from the database and formatted into an IDoc format. This IDoc is called as a Master IDoc.

3. Generate the Communication IDoc: The ALE Service layer generates a separate IDoc from the Master IDoc for each recipient who is interested in the data. Separate IDocs are generated because each recipient might demand a different version or a subset of the Master IDoc. These recipient-specific IDocs are called Communication IDocs and are stored in the database.

4. Deliver the Communication IDoc: The IDoc is delivered to the recipients using an asynchronous communication method. This allows the sending system to continue its processing without having to wait for the destination system to receiver or process the IDoc.

Inbound Process:

The inbound process receives an IDoc and creates a document in the system.

1. Store the IDoc in the database: The IDoc is received from the sending system and stored in the database. Then the IDoc goes through a basic integrity check and syntax check.

2. Invoke the Posting Module: The control information in the IDoc and configuration tables are read to determine the posting program. The IDoc is then transferred to its posting program.

3. Create the Document: The posting program reads the IDoc data and then creates a document in the system. The results are logged in the IDoc.

Over view of IDocs:

IDoc is a container that is used to exchange data between any two processes. The document represented in an IDoc is independent of the complex structure SAP uses to store application data. This type of flexibility enables SAP to rearrange its internal structure without affecting the existing interface.

IDoc interface represents an IDoc Type or IDoc data. IDoc Type represents IDoc’s definition and IDoc Data is an instance of the IDoc Type.

IDoc Types:

IDoc type structure can consist of several segments, and each segment can consist of several data fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments and arrangement of the segments. Segments define a set of fields and their format.

An IDoc is an instance of an IDoc Type and consists of three types of records.

i. One Control record: each IDoc has only one control record. The control record contains all the control information about an IDoc, including the IDoc number, the sender and recipient information, and information such as the message type it represents and IDoc type. The control record structure is same for all IDocs.

ii. One or Many Data records: An IDoc can have multiple data records, as defined by the IDoc structure. Segments translate into data records, which store application data, such as purchase order header information and purchase order detail lines.

iii. One or Many Status records: An IDoc can have multiple status records. Status record helps to determine whether an IDoc has any error.

Message in IDoc Type:

A Message represents a specific type of document transmitted between two partners.

Outbound Process in IDocs:

Outbound process used the following components to generate an IDoc. A customer model, and IDoc structure, selection programs, filter objects, conversion rules, a port definition, an RFC destination, a partner profile, service programs, and configuration tables.

The Customer Model:

A customer model is used to model a distribution scenario. In a customer model, you identify the systems involved in a distribution scenario and the message exchanged between the systems.

Message control:

Message control is a cross application technology used in pricing, account determination, material determination, and output determination. The output determination technique of Message control triggers the ALE for a business document. Message control separates the logic of generating IDocs from the application logic.

Change Pointers:

The change pointers technique is based on the change document technique, which tracks changes made to key documents in SAP, such as the material master, customer master and sales order.

Changes made to a document are recorded in the change document header table CDHDR, and additional change pointers are written in the BDCP table for the changes relevant to ALE.

IDoc Structure:

A message is defined for data that is exchanged between two systems. The message type is based on one or more IDoc structures.

Selection Program:

Is typically implemented as function modules, are designed to extract application data and create a master IDoc. A selection program exists for each message type. A selection program’s design depends on the triggering mechanism used in the process.

Filter Objects;

Filter Objects remove unwanted data for each recipient of the data basing on the recipients requirement.

Port Definition:

A port is used in an outbound process to define the medium in which documents are transferred to the destination system. ALE used a Transactional RFC port, which transfers data in memory buffers.

RFC Destination:

The RFC destination is a logical name used to define the characteristics of a communication link to a remote system on which a function needs to be executed.

Partner Profile:

A partner profile specifies the components used in an outbound process(logical name of the remote SAP system, IDoc Type, message type, TRFC port), an IDoc’s packet size, the mode in which the process sends an IDoc (batch versus immediate), and the person to be notified in case of error.

Service Programs and Configuration Tables:

The outbound process, being asynchronous, is essentially a sequence of several processes that work together. SAP provides service programs and configuration tables to link these programs and provide customizing options for an outbound process.

Creation of IDoc:

Basic Type:

Basic IDoc type defines the structure and format of the business document that is to be exchanged between two systems.

Segments:

Segments form the basic building blocks of an IDoc type and are used to store the actual datta. A segment type is the name of a segment and is independent of the SAP elease. A segment definition is the release-specific name of a segment.

Steps in creating Segments:

T.Code WE31

Enter the name for your segment type and click on the create icon.

Type the Short text.

Enter the variable names and data elements.

Save and Go back.

Go to Edit -> Set Release.

Repeat the steps to create more segments.

IDOC TYPE:

Business data is exchanged with an external system using the IDoc Interface.

IDoc types (Special Structures) An IDoc type is defined through its permitted segments. Segments can be dependent on each other (parent and child segments). The IDoc interface can check for each IDoc whether thhe segments contained are compatible with thhe definitiion of its type. This systax check is activated or deactivated in the Partner Profiles.

Steps in creating IDoc Type:

T.Code WE30 to create IDoc Type.

Enter the Object Name, Select Basic Type and click Create Icon

Select the create new option and enter a description for your basic IDOC type and press enter

Select the IDoc name and click Create icon

The system prompts us to enter a segment type and its attributes

Choose the appropriate values and press enter

The system transfers the name of the segment type to the IDoc editor.

Follow these steps to add more number of segments to Parent or as Parent-child relation.

Save it and go back.

Go to Edit -> Set Release.

Message Type:

Steps in Creating Message Type:

T.Code WE81.

change the details from Display mode to Change mode

After selection, the system will give this message "The table is cross client (See help for further info)". Press enter.

Click New Entries to create new Message Type.

Fill details

Save it and go back.

Assign Message Type to IDoc Type:

T.Code WE82

Change the details from Display mode to change mode.

After selection, the system will give this message "The table is cross client (See help for further info)". Press enter.

Click New Entries to create new Message Type.

Fill details

Save it and go back.

regard

mukesh goyal

[Former Member]

Dear Eeshwar,

As you want to understand the difference between IDocs and BAPIs I have jotted down some differences, advantages and disadvantages of both as well as their uses as you wanted to know.

=============================================

IDocs and BAPI are very different, so it should be easy to choose between them depending on your requirements.

=============================================

IDOCS

=============================================

>IDocs are processed asynchronously and no information whatsoever is returned to the client, but IDocs - by using tRFC - support guaranteed delivery.

Advantages

>System can work even if target system not always online. The IDoc will be created and sending will just continue once you get connected to the other system.

>No additional programming required. You just need to set up the configuration.

Disadvantages

>Receipt/processing on the target system may not be immediate.

>The sending system has no way to know whether the target system actually received what you sent (unless you use ALE).

>If there is no SAP standard IDoc available for your requirement, it's harder to create a customized IDoc than a customized BAPI.

Use of IDoc:

An IDoc that is sent to the inbound channel of the Integration Server is converted from native IDoc format to IDoc XML format by the IDoc adapter.

EDI and ALE are typical use cases for IDocs.

=============================================

BAPIS

=============================================

> BAPIs are called synchronously and (usually) return information.

> BAPIs are reasonably well documented and there is a common place to look

to see what is available.

Advantages

>You can tell if your sending was successful or not

>Sending to/processing on the other side is immediate

>Easier to create your own BAPI than your own IDoc

Disadvantages

>Will only work if you have an active online connection.

>Some programming required to call the BAPI.

Use of BAPI:

BAPIs should only be implemented within the context of a meaningful business scenario.

For examples of BAPI scenarios refer to Overview of ALE Integration Scenarios in the Library of ALE Business Processes. SAP developers will also find templates for defining and documenting BAPI scenarios.

Every BAPI should be based on a model of a scenario in which it can be usefully employed.

Keep in mind whilst you are planning the scenario that COMMIT WORK commands must not be used in BAPIs. COMMIT WORK commands can adversely effect the process flow of the scenario and how the BAPIs in the scenario work together.

Best Regards,

Rajesh

Please reward points if found helpful.