Re: bapi

Former Member · ‎2008 May 06

what are the differences between bapi function modules and normal function modules

Former Member · ‎2008 May 06

Hi,

RFC is Remote Function Call - a function module, which can be called remotely from outside

BAPI is also a Remote enabled function module but the difference between BAPI and RFC is in BAPI there is a bussiness object attached to it which calls SAP application internally.

**********************************************

can you explain RFC and BAPI???

The difference between RFc and BAPI are business objects. You create business objects and those are then registered in your BOR (Business Object Repository) which can be accessed outside the SAP system by using some other applications (Non-SAP) such as VB or JAVA. in this case u only specify the business object and its method from external system in BAPI there is no direct system call. while RFC are direct system call 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.

RFC is the protocol used to call functions in an R/3 system by a caller external to R/3 or to call programs external to R/3 from an R/3 system. Functions can only be called via RFC, if they are tagged as RFC functions in the SAP development workbench. They are then called RFC function modules. BAPIs are complete sets of (BAPI) function modules that model a business application.

RFC is the protocol used by SAP for remote communication, that is, for communications between remote independent systems.RFC is used for communications between two independent SAP systems, or for communications between an SAP system and a non-SAP system, such as an external application. It can also be used for communications between modules on the same system.Using the RFC interfaces you can extend the functionality of R/3 applications from an external program.

An R/3 system also contains Business Application Programming Interfaces (also called Business APIs, or BAPIs), which provide a programming interface to business objects. BAPIs are a set of methods for working with and manipulating SAP business objects.Internally, BAPIs are implemented as function modules stored in the R/3 Function Builder. Each BAPI has an equivalent internally-named function module. However, you should use the BAPI and not the function module behind it, because the BAPI provides a stable, object-oriented view of R/3 applications and data. The internal function modules or even the fact that the BAPIs are implemented as function modules are not guaranteed to remain the same in future releases of R/3.

BAPI stands for Business Application Programming Interface.

It is a library of functions that are released to the public

as an interface into an existing SAP system from an external

system.

RFC is the protocol used to call functions in an R/3 system

by a caller external to R/3 or to call programs external to

R/3 from an R/3 system.

Functions can only be called via RFC, if they are tagged as

RFC functions in the SAP development workbench. They are

then called RFC function modules. BAPIs are complete sets of

(BAPI) function modules that model a business application.

When you are familiar with web developments: RFC can be

compared to HTTP and BAPIs are CGI applications.

In other words: A BAPI function is a function module that

can be called remotely using the RFC technology.

*****************************************************************************

RFC and BAPIs are remote enabled function modules. They are practicly the same. A BAPI is one step further as it usually is a self contained business function, such as "Create Purchase Order", or "Change Sales Document". BAPIs interface is very well defined and documented. BAPIs can be found in the BAPI browser via transaction BAPI. RFCs are just remote enabled function modules.

BAPI stands for Business Application Programming Interface. It is a library of functions that are released to the public as an interface into an existing SAP system from an external system.

RFC is the protocol used to call functions in an R/3 system by a caller external to R/3 or to call programs external to R/3 from an R/3 system. Functions can only be called via RFC, if they are tagged as RFC functions in the SAP development workbench.

*******************************************************************************

BAPIs are RFCs, the only difference is that BAPIs usually encapulate some complete business object. For example, creating a sales order, the BAPI would do all of the steps required to create a sales order.

**************************************************************************************

Regards,

Shiva.

Former Member · ‎2008 May 06

BAPI stands for Business API(Application Program Interface).

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 BAPIs are standard SAP function modules provided by SAP for remote access. Also they are part of Businees Objest Repository(BOR).

Both Function Modules and BAPIs can be Remote Enabled and we can create both custom BAPIs and custom Function Modules. The Main difference between a BAPI and a Normal Function module is that a BAPI does a specific Business Process, for example creating sales orders, while Function module performs specific functions, which forms a part of a Business Process.

Another difference will be that the BAPI will return the Status of the Execution using the "Return" table and for Function modules we use the sy-subrc check to determine the Status.

While accessing an SAP system through an RFC, BAPI is preferred to a Function module, as the External user will be more aware of the Business Processes in SAP rather than the Business Functions.

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.

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

Please check out this thread..

I hope it helps.

Best Regards,

Vibha

Please mark all the helpful answers

Former Member · ‎2008 May 06

Hi

RFC and BAPIs are remote enabled function modules. They are practicly the same. A BAPI is one step further as it usually is a self contained business function, such as "Create Purchase Order", or "Change Sales Document". BAPIs interface is very well defined and documented. BAPIs can be found in the BAPI browser via transaction BAPI. RFCs are just remote enabled function modules.

BAPI stands for Business Application Programming Interface. It is a library of functions that are released to the public as an interface into an existing SAP system from an external system.

RFC is the protocol used to call functions in an R/3 system by a caller external to R/3 or to call programs external to R/3 from an R/3 system. Functions can only be called via RFC, if they are tagged as RFC functions in the SAP development workbench.

Function Modules;

Check this matter.

Function Modules are Global ABAP programs created by SAP for reusable purpose.they have IMPORT,EXPORT and TABLE parameters, and EXCEPTIONS to through when error occurs.

You can create them from TCode SE37.

Go through the following doc:

Function modules are cross-program, reusable procedures that are organized into function groups, and whose functions are implemented between the statements FUNCTION and ENDFUNCTION. Function modules and their interfaces are created in the Function Builder.

Function Module Interfaces

The parameter interface of a function module is defined in the Function Builder. It includes the definition of interface parameters and the specification of exceptions that can be triggered by a function module. The Function Builder automatically generates comment lines below the FUNCTION statement in the source code of the function module, which represent the interface of the function module with the following syntax:

Syntax

... IMPORTING parameters

EXPORTING parameters

CHANGING parameters

TABLES table_parameters

{RAISING

The syntax and semantics of IMPORTING, EXPORTING, CHANGING, RAISING, and EXCEPTIONS mainly correspond to the definition of method interfaces with CLASS-METHODS. The additional option of defining table parameters using TABLES is obsolete.

Interface parameters

The interface parameters are defined on the relevant tab pages in the Function Builder.

IMPORTING parameters are input parameters. When the function module is called, a suitable actual parameter must be specified for every non-optional input parameter. The content of the actual parameter is passed to the input parameter when the call is made. The content of an input parameter for which 'pass by reference' is defined cannot be changed in the function module.

EXPORTING parameters are output parameters. When the function module is called, a suitable actual parameter can be specified for every output parameter. The content of an output parameter that is defined for 'pass by value' is transferred to the actual parameter if the function module is completed without errors. An output parameter that is defined for pass by reference is not initialized when the function module is called.

CHANGING parameters are input and output parameters. When the function module is called, a suitable actual parameter must be specified for every non-optional input or output parameter. When the function module is called, the content of the actual parameter is passed to the input/output parameter, and when the function module is completed, the content of the input/output parameter is passed to the actual parameter.

TABLES parameters are table parameters. Table parameters are obsolete CHANGING parameters that are typed as standard tables with a header line. If an internal table without a header line or a table body is passed as an actual parameter to a formal parameter of this type, an empty local header line is generated in the function module. If an internal table with a header line is used as an actual parameter, both the table body and the header line are passed to the function module. Pass by value is not possible in formal parameters defined using TABLES. Formal parameters defined with TABLES can be replaced by formal parameters defined with CHANGING. A local work area can be created for the internal table in the function module by using the addition LIKE LINE OF itab of the DATA statement.

Exceptions

The exception of a function module are defined on the Exceptions tab page in the Function Builder. Here you can select exception classes to define whether class-based exceptions are declared or non-class-based exception are defined. Class-based exceptions are represented in the above syntax by RAISING, and non-class-based exceptions are represented by EXCEPTIONS.

The addition RAISING is used to declare class-based exceptions that can be propagated from the function module to the caller. Exceptions in the categories CX_STATIC_CHECK and CX_DYNAMIC_CHECK must be explicitly declared, otherwise a propagation can lead to an interface violation. A violation of the interface leads to the treatable exception CX_SY_NO_HANDLER. Exceptions of the category CX_NO_CHECK are implicitly always declared. The declaration of exceptions of the category CX_STATIC_CHECK is statically checked in the syntax check. For exceptions of the category CX_DYNAMIC_CHECK, the check is not performed until runtime. In a function module in which class-based exceptions are declared with the RAISING addition, the statement CATCH SYSTEM-EXCEPTIONS cannot be used. Instead, the relevant treatable exceptions should be handled in a TRY control structure.

The addition EXCEPTIONS is used to define a list of non-class-based exceptions that can be triggered in the function module using the statements RAISE or MESSAGE RAISING. Exceptions defined in this way - as with formal parameters - are bound to the function module and cannot be propagated. If an exception of this type is triggered in a function module, and no return value has been assigned to it with the homonymous addition EXCEPTIONS of the CALL FUNCTION statement when the call was made, this leads to a runtime error.

Note

For new developments after release 6.10, SAP recommends that you work with class-based exceptions that are independent of the function module.

RFC is a technology which is used to access a functions (Modules) from

the remote systems.

If a function module is set as remote enabled which can be access from

the remote system via RFC.Eg: U can access the Remote enabled function modules in ur VB,Webdynpro,Java,Visual composer program.

A function module can be set as remote enabled by SE37->Go to ur FM->click the option Button "remote enabled".

But Normal function modules can not accessd from the remote system.

Good Example for RFC enabled function module is : BAPI(Business Application Programming Interface)

Note: All BAPIs are Remote enabled but not all remote enabled function modules are BAPI.

CALLING A FUNCTION MODULE:

1)In U ABAP Editor --> Click "Patter" ---> Selection Option Button "Call Function"