different types of function module

[Former Member]

hi,

When we create a function module : in one of the tabs we can find

1 general function module

2. remote function module

3. update function module.

What is meant by update function module and remote function module. can anyone explain me with an example and when shd we opt for 2 and 3.

thanxs

hari

[former_member196280]

Remote function module is used for remote function call,(specifics on writing function modules that can be called remotely) Ex: RFC

Update Function module.

To be able to call a function module in an update work process, you must flag it in the Function Builder. When you create the function module, set the Process Type attribute to one of the following values:

Update with immediate start

Set this option for high priority ("V1") functions that run in a shared (SAP LUW). These functions can be restarted by the update task in case of errors.

Update w. imm. start, no restart

Set this option for high priority ("V1") functions that run in a shared (SAP LUW). These functions may not be restarted by the update task.

Update with delayed start

Set this option for low priority ("V2") functions that run in their own update transactions. These functions can be restarted by the update task in case of errors.

Regards,

SaiRam

[Former Member]

hi,

Check this link:

http://help.sap.com/saphelp_erp2004/helpdata/en/9f/db988735c111d1829f0000e829fbfe/content.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/ef/d94b78ebf811d295b100a0c94260a5/frameset.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/43/41341147041806e10000000a1553f6/frameset.htm

[Former Member]

General function module means : this FM can be used in current system only..

Remote Enable Function Module can be called from external SAP system also..

FMs In Update Task .. are called in asynchronous manner..

it means.. when they are called their action is not completed at that time but when next SAP LUW occurs.. i.e during COMMIT WORK...

Reward if useful

Regards

Prax

[Former Member]

Hi,

<b>1. general function module</b>

Created as a normal function module intially. For this we select this button.

<b>2. remote function module</b>

This is used to call the FM remotely.

RFC (Remote Function Call) is similar to the general SAP fun module: except that in the attributes you click the radio button: RFC enabled;

and you will be passing an Import parameter DESTINATION to it.

Other code and usage will be similar to any fun module;

Have a look at any fun module in SE37 to understand better about the different components of Fun modules;

Refer this link:

http://help.sap.com/saphelp_nw04/helpdata/en/22/042518488911d189490000e829fbbd/frameset.htm

check out the following link it might help you

http://help.sap.com/printdocu/core/Print46c/de/data/pdf/BCFESDE2/BCFESDE2.pdf

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|EXCEPTIONS} exc1 exc2 ...]

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"

--> Write the Corresponding FM name --> Hit Enter

2)The appropriate import ,export Parameters will be displayed in ur editor

3)Pass the Values Here.

<b>3. update function module.</b>

Calling a FM in Update Task is one of the bundling techniques used in ABAP to avail functionality provided by SAP Update System. Here all database updates are processed at the end of the SAP LUW in contrast to normal FM call where the database updates are done and commited at the time of call (Database LUW). It is necessary to bundle all your database updates in an SAP LUW e.g. all database updates in a transaction (like VA01) should be bundled. Almost all standard SAP transactions use bundling techniques.

This technique separates the dialog process and update process. The dialog part of the transaction can span more than one screen(one dialog step) and can be processsed by more than one dialog work process. A work process is released when the dialog step changes (screen changes) and the work process sends a database commit (called Implicit Database LUW). So with each screen change there is a database commit and database remains in consistent state.

Now when using bundling technique, when a COMMIT WORK is encountered, system ends the dialog process with a dialog work porcess and starts the update process using an update work process.

The dialog step containing the COMMIT WORK is considerd as the last dialog step of the transaction and all the update function modules are processed now in the last dialog step by the update work process though they were called earlier during the earlier dialog steps.

It is necessary to create update FMs to take advantage of this technique. The update FM is created FM by setting the Update moduleradiobutton in the Attributes tab in SE37.

In a normal FM call, if there are database updates (UPDATE, INSERT, MODIFY, DELETE) than database is commited after the FM processing is over as the FM starts its own Database LUW and ends it too.

Also check these links.

http://www.geocities.com/victorav15/sapr3/abapfun.html

Check this link:

http://help.sap.com/saphelp_erp2004/helpdata/en/9f/db988735c111d1829f0000e829fbfe/content.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/ef/d94b78ebf811d295b100a0c94260a5/frameset.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/43/41341147041806e10000000a1553f6/frameset.htm

Check this link:

http://help.sap.com/saphelp_erp2004/helpdata/en/9f/db988735c111d1829f0000e829fbfe/content.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/ef/d94b78ebf811d295b100a0c94260a5/frameset.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/43/41341147041806e10000000a1553f6/frameset.htm

See the following links:

http://help.sap.com/saphelp_erp2005vp/helpdata/en/9f/db970e35c111d1829f0000e829fbfe/frameset.htm

http://help.sap.com/saphelp_erp2005vp/helpdata/en/9f/db970e35c111d1829f0000e829fbfe/frameset.htm

http://help.sap.com/saphelp_erp2005vp/helpdata/en/9f/db970e35c111d1829f0000e829fbfe/frameset.htm

http://help.sap.com/saphelp_erp2005vp/helpdata/en/9f/db970e35c111d1829f0000e829fbfe/frameset.htm

http://help.sap.com/saphelp_erp2005vp/helpdata/en/9f/db970e35c111d1829f0000e829fbfe/frameset.htm

http://help.sap.com/saphelp_nw04/helpdata/en/26/64f623fa8911d386e70000e82011b8/content.htm

Regards,

Priyanka.

[Former Member]

Function Modules:

Function modules allow you to encapsulate and reuse global functions in the R/3 System.

They are stored in a central library. The R/3 System contains a wide range of predefined

function modules that you can call from any ABAP program.

Unlike subroutines, you do not define function modules in the source code of your program.

Instead, you use the Function Builder. The actual ABAP interface definition remains hidden

from the programmer. You can define the input parameters of a function module as optional.

You can also assign default values to them. Function modules also support exception handling.

This allows you to catch certain errors while the function module is running. You can test

function modules without having to include them in a program using the Function Builder.

Function Groups:

Function groups are containers for function modules. You cannot execute a function group.

When you call a function module, the system loads the whole of its function group into the

internal session of the calling program.

Calling Function Modules in ABAP:

To call a function module, use the CALL FUNCTION statement:

CALL FUNCTION <module>

[EXPORTING f1 = a 1.... f n = a n]

[IMPORTING f1 = a 1.... f n = a n]

[CHANGING f1 = a 1.... f n = a n]

[TABLES f1 = a 1.... f n = a n]

[EXCEPTIONS e1 = r 1.... e n = r n [ERROR_MESSAGE = r E]

[OTHERS = ro]].

You can specify the name of the function module <module> either as a literal or a variable.

Each interface parameter <fi> is explicitly assigned to an actual parameter <a i>. You can

assign a return value <r i> to each exception <e i>. The assignment always takes the form

<interface parameter> = <actual parameter>. The equals sign is not an assignment operator

in this context.

• After EXPORTING, you must supply all non-optional import parameters with values

appropriate to their type. You can supply values to optional import parameters if you

wish.

sgummaluri@gmail.com

34

• After IMPORTING, you can receive the export parameters from the function module by

assigning them to variables of the appropriate type.

• After CHANGING or TABLES, you must supply values to all of the non-optional

changing or tables parameters. When the function module has finished running, the

changed values are passed back to the actual parameters. You can supply values to

optional changing or tables parameters if you wish.

You can use the EXCEPTIONS option to handle the exceptions of the function module. If an

exception <e i > is raised while the function module is running, the system terminates the

function module and does not pass any values from the function module to the program,

except those that were passed by reference. If <e i > is specified in the EXCEPTION option,

the calling program handles the exception by assigning <r i > to SY-SUBRC. <r i > must be a

numeric literal.

If you specify of ERROR_MESSAGE in the exception list you can influence the message

handling of function modules. Normally, you should only call messages in function modules

using the MESSAGE ... RAISING statement. With ERROR_MESSAGE you can force the system

to treat messages that are called without the RAISING option in a function module as follows

for various FM's

http://www.erpgenie.com/abap/functions.htm

Calling Function Modules

http://help.sap.com/saphelp_46c/helpdata/en/9f/db98ef35c111d1829f0000e829fbfe/content.htm

remote enabled fm's are BAPI's

refer

Introduction to BAPIs:

Definition

The SAP Business Objects held in the Business Object Repository (BOR) encapsulate their data

and processes. External access to the data and processes is only possible by means of specific

methods - BAPIs (Business Application Program Interfaces).

A BAPI is defined as a method of a SAP Business Object.

For example, the functionality that is implemented with the SAP Business Object type

"Material" includes a check for the material’s availability. Thus, the Business Object type

"Material" offers a BAPI called "Material.CheckAvailability".

Use

To use a BAPI method, an application program only needs to know how to call the method;

that is, it needs to know the method’s interface definition. Therefore, when including a BAPI

invocation in your application program, you only need to supply the appropriate interface

information.

A BAPI interface is defined by:

• Import parameters, which contain data to be transferred from the calling program to

the BAPI

• Export parameters, which contain data to be transferred from the BAPI back to the

calling program

• Import/export (table) parameters for both importing and exporting data

Structure

The BAPIs in the R/3 System are currently implemented as function modules, all of which are

held in the Function Builder. Each function module underlying a BAPI:

• Supports the Remote Function Call (RFC) protocol

• Has been assigned as a method to an SAP Business Object in the BOR

• Is processed without returning any screen dialogs to the calling application

Integration

The architecture enables SAP to change the details of a BAPI’s implementation without

affecting external applications, which are using the BAPI.

Advantages of Using BAPIs

BAPIs are standardized methods of SAP Business Objects that enable customers and third

parties to integrate their software components with the R/3 System and the Business

Framework.

Business Standard

SAP Business Objects and their BAPIs provide a business content standard, rather than a

technical interoperability standard; that is, they enable the integration of R/3 and other

software components on a business level, not on a technical level.

sgummaluri@gmail.com

97

Standards Conformance

BAPIs are being developed as part of the SAP joint initiative with customers, partners, and

leading standards organizations. BAPIs are becoming a communication standard between

business systems.

You can access SAP Business Objects and their BAPIs by using object-oriented interfacing

technologies such as Microsoft’s COM/DCOM (Component Object Model/Distributed Component

Object Model).

The SAP Business Objects already comply with the Open Applications Group (OAG)

specifications, and, in conjunction with ObjectBridge from VisualEdge, conform to the Object

Management Group’s CORBA (Common Object Request Broker Architecture) guidelines.

Stability and Downward Compatibility

Once a BAPI is implemented and released by SAP, its interface definition and parameters

remain stable in the long term, thus ensuring that your application program remains

unaffected by any changes to the underlying R/3 software and data.

SAP can make any necessary extensions to the BAPIs, for example, additional optional

parameters, without destabilizing the operation of existing applications and, at the same time,

can offer the enhanced functionality to new applications.

Object Orientation

As methods of the SAP Business Objects, BAPIs provide access to R/3 data and processes

following an object-oriented programming model. BAPIs can be called using object-oriented

interfacing technologies, such as COM/DCOM, thus enabling software components from SAP

and third parties to interact freely.

Openness

You can access BAPIs from all development platforms that support the SAP Remote Function

Call (RFC) protocol.

BAPI Definition

A Business Application Programming Interface (BAPI) is a precisely defined interface providing

access to processes and data in business application systems such as R/3. BAPIs are defined

as API methods of SAP Business Objects. These business objects and their BAPIs are described

and stored in the Business Object Repository (BOR).

A BAPI is implemented, however, as a function module, that is stored and described in the

Function Builder.

BAPIs can be called within the R/3 System from external application systems and other

programs. BAPIs are the communication standard for business applications. BAPI interface

technology forms the basis for the following developments:

• R/3 satellite systems

• Isolating components within the R/3 System in the context of Business Framework

• Distributed R/3 scenarios using Application Link Enabling (ALE)

• Connecting R/3 Systems to the Internet using Internet Application Components (IACs)

• Visual Basic programs as front-end to R/3 Systems

• Workflow applications that extend beyond system boundaries

• Customers’ and partners’ own developments

• Connections to non-SAP software

• Connections to legacy systems

sgummaluri@gmail.com

98

Standardized BAPIs

Some BAPIs and methods provide basic functions and can be used for most SAP Business

Objects. Such BAPIs are known as "standardized" BAPIs.

Using the descriptions below as a guide, verify whether you can implement the BAPI as a

standardized BAPI.

Features

BAPIs for Reading Data

The following BAPIs provide you with read-only access to data in the associated business

object:

• GetList

With this BAPI you can select a range of object key values, for example, company

codes and material numbers. To specify appropriate selection requirements the calling

program must pass the relevant parameters to the interface. The key values selected

by the BAPI GetList are returned to the calling program in a table, together with other

useful information, for example, short texts. The key values can then be passed on to

another BAPI for further processing, for example, the BAPI GetDetail, as listed below.

• GetDetail

The BAPI GetDetail uses a key to retrieve details about an instance(s specific

occurrence) of a business object and returns this data to the calling program.

• GetStatus

The BAPI GetStatus is used to query the status of an SAP Business Object, for

example, to display the processing status of a sales order. This BAPI is used only for

displaying the status of an object and does not retrieve full details like the BAPI

GetDetail.

• ExistenceCheck

The BAPI ExistenceCheck checks, whether an entry exists for an SAP Business Object,

for example, whether the customer master has been created. You should implement

this method as a workflow method and not as a BAPI (RFC capable function module).

The method CompanyCode.ExistenceCheck of the business object CompanyCode

(BUS0002) is an example of this. This workflow method is indirectly invoked when the

calling program instantiates an object, for example, by using

GetSAPObject("CompanyCode") from within Visual Basic.

BAPIs for Creating or Changing Data

The following BAPIs can create, change or delete instances of a business object: If required,

you can implement these BAPIs so that, several instances of a business object can be created,

deleted or modified simultaneously in the same call. In such cases "multiple" is added to the

method name, for example ChangeMultiple.

BAPIs that can create, change or delete instances are:

• Create or CreateFromData

The BAPI Create or CreateFromData creates an instance of an SAP Business Object,

for example, a sales order. Create is the preferred name for this BAPI. Use the name

CreateFromData only when a workflow method called Create already exists for the

business object in question.

sgummaluri@gmail.com

99

• Change

The BAPI Change changes an existing instance of a SAP Business Object, for example,

a sales order.

• Delete

The BAPI Delete deletes an instance of a SAP Business Object, for example, sales

order.

BAPIs for Replicating Business Object Instances

The BAPIs below can be implemented as methods of business objects that can be replicated.

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

The method below must be implemented for each business object to be replicated.

• Replicate

The BAPI Replicate is called in the system, which contains the originals of the business

object instances to be replicated. It is used to:

• Identify the business objects to be replicated and to organize the required data.

• Call the clone methods described below in the receiving system

Moreover, at least one of the clone methods below must be implemented for each business

object to be replicated.

• Clone

The BAPI Clone is used by a system to replicate one business object on another

system or to modify one business object that has already been cloned.

• CloneMultiple

The BAPI CloneMultiple is used by a system to replicate several business objects on

another system or to modify several business objects that have already been cloned.

Defining and Implementing the BAPI

Purpose

Various components of the ABAP Workbench are used when you define and implement a BAPI.

A BAPI is an API method of a business object and is defined as such in the Business Object

Repository (BOR). However, a BAPI is implemented as an RFC capable function module, which

is maintained in the Function Builder. The definitions and descriptions of the data structures

used by the BAPI are stored in the ABAP Dictionary.

For function modules that implement BAPIs, certain standards and rules must be adhered to

over and above the standard programming rules for function modules. For example, COMMIT

WORK commands must not be used in the function modules that a BAPI is based on.

The following sections guide you through the steps involved in developing a BAPI. The sections

contain information about the guidelines and conventions that you should adhere to when

defining and implementing a BAPI. When implementing BAPIs follow the requirements below

to ensure you achieve consistent behavior and representation of BAPIs as object oriented

methods of SAP Business Objects.

sgummaluri@gmail.com

100

BAPI Programming

BAPI Definition

A Business Application Programming Interface (BAPI) is a precisely defined interface providing

access to processes and data in business application systems such as R/3.

BAPIs are defined as API methods of SAP Objects. These objects and their BAPIs are described

and stored in the BOR (BOR).

Use

BAPIs can be called within the R/3 System from external application systems and other

programs. A BAPI call can either be made as an object oriented method call or as a remote

function call (RFC).

BAPIs are a global communication standard for business applications.

Examples of what BAPIs can be used for include:

• R/3 satellite systems

• Distributed R/3 scenarios using Application Link Enabling (ALE)

• Connecting R/3 Systems to the Internet using Internet application components (IACs)

• Visual Basic programs as front-end to R/3 Systems

• Workflow applications that extend beyond system boundaries

• Customers’ and partners’ own developments

• Connections to non-SAP software

• Connections to legacy systems

BOR Definition

The Business Object Repository (BOR) is the object-oriented repository in the R/3 System. It

contains, among other objects, SAP Business Objects and their methods. In the BOR a

Business Application Programming Interface (BAPI) is defined as an API method of an SAP

Business Object. Thus defined, the BAPIs become standard with full stability guarantees as

regards their content and interface.

Use

With regard to SAP Business Objects and their BAPIs, the BOR has the following functions:

• Provides an object-oriented view of R/3 System data and processes.

R/3 application functions are accessed using methods (BAPIs) of SAP Business

Objects. Implementation information is encapsulated; only the interface functionality

of the method is visible to the user.

• Arranges the various interfaces in accordance with the component hierarchy, enabling

functions to be searched and retrieved quickly and simply.

• Manages BAPIs in release updates.

BAPI interface enhancements made by adding parameters are recorded in the BOR.

Previous interface versions can thus be reconstructed at any time. When a BAPI is

created the release version of the new BAPI is recorded in the BOR. The same applies

when any interface parameter is created.

The version control of the function module that a BAPI is based on is managed in the

Function Builder.

• Ensures interface stability.

Any interface changes that are carried out in the BOR, are automatically checked for

syntax compatibility against the associated development objects in the ABAP

Dictionary.

sgummaluri@gmail.com

101

Integration

You should only define a BAPI as a SAP Business Object method in the BOR if the function

module that the BAPI is based on has been fully implemented. Full access to the BOR is

restricted to the persons responsible for the objects involved and for quality control.

BOR-BAPI Wizard

The BOR-BAPI Wizard assists with creating new BAPI methods in the BOR. It takes you

through the creation process step by step.

Transaction Model for Developing BAPIs Purpose

The transaction model in which BAPIs are used determines how you have to program BAPIs.

The transaction model described here has been used to develop BAPIs for R/3 Releases 3.1

and 4.0A.

Logical Unit of Work (LUW) and Statelessness

Within the context of this transaction model a transaction represents one processing step or

one logical unit of work (LUW). When a transaction is called, database operations are either

fully executed or not at all. The whole transaction must be programmed to be stateless.

This transaction model requires that:

• No data is imported that may indirectly affect the result. If a transaction is called more

than once, each call must have the same result. For BAPIs this means, for example,

that Set or Get parameters cannot be used. However, you can keep Customizing data

in a global memory, as this data remains unchanged even if transaction calls are

repeated.

• There must be no functional dependencies between two transactions.

• Either all relevant data has to be changed in the database or none at all.

Determining the SAP Business Object and Its Key Fields

You have to identify the relevant SAP Business Object in the Business Object Repository (BOR)

and determine whether the key fields of the Business Object are relevant for your BAPI.

A key is defined in the BOR for most SAP Business Objects. This key can consist of several key

fields. The content of these key fields uniquely identifies one individual instance of an SAP

Business Object.

You can differentiate between instance-dependent and instance-independent BAPI methods.

Unlike instance-independent methods, instance-dependent methods relate to one instance

(one specific occurrence) of an SAP Business Object type, for example to one specific sales

order.

In the case of instance-dependent BAPIs, the key fields of the corresponding SAP Business

Object must be used as parameters in the function module the BAPI is based on so that the

associated object instance can be identified. The names of the key fields in the SAP Business

Object and the corresponding parameters in the BAPI function module must be the same,

because the name links the key fields to the parameters.

All the key fields defined in the BOR for the SAP Business Object in question must be used as

the parameters in the function module.

Example

SAP Business Object Creditor has a key field named CreditorId.

This key field must be defined as a parameter with the name CREDITORID in the function

modules of the instant-dependent BAPIs for this Business Object.

sgummaluri@gmail.com

102

To display the Business Object and its key fields follow the steps below:

1. Select Tools -> ABAP Workbench -> Overview -> Business Object Browser . The

business objects are displayed in the order of the R/3 application hierarchy.

2. Select the required SAP Business Object in the application hierarchy and double click it

to open it.

3. To display the Business Object’s key fields, expand the node Key fields.

Defining the Interface Structure of the BAPI

In this step you are going to define the BAPI interface, that is, the individual import, export

and table parameters required for calling the BAPI.

Caution

You cannot use Changing and Exception parameters in a function module which implements a

BAPI.

Process Flow

To define the interface parameters, proceed as follows:

1. Check whether the key fields of the SAP Business Object are required in the interface. The

key fields of the SAP Business Object are some of the most important BAPI parameters.

If a key value is to be passed to the BAPI by the calling program, the key field must be set as

an import parameter in the function module of the BAPI. That way a specific instance of the

Business Object is identified.

For example, this could be a customer number (CustomerNo) in the BAPIs Customer.GetDetail

and Customer.CheckPassword, or the number of a sales document in the BAPI

SalesOrder.GetStatus.

For BAPIs that generate instances, for example, the BAPIs Create or CreateFromData, the key

field of the Business Object should be set as an export parameter in the BAPI function module.

These BAPIs return one key value, for example, an order number in the BAPI

SalesOrder.CreateFromData.

For BAPIs that are class methods a key field is neither set as an import nor as an export

parameter in the BAPI function module. Class methods are instance-independent and are

called without the use of key values. Usually they return a table with a selection of key values.

2. Specify what other data is relevant as import, export or table parameters for the BAPI.

Every BAPI must have an Export parameter return that reports messages back to the calling

program.

Example

The BAPI to be developed is to read data from the SAP Business Object Creditor. To read

creditor details, the calling program has to pass the ID of the creditor and the company code.

The creditor data returned is to include general details, specific details and bank details.

To map these requirements onto the BAPI interface, the following parameters must be set in

the function module which the BAPI is based on:

• The key field CreditorID of the SAP Business Object as an import parameter

• An import parameter for the company code

• A Return parameter that reports messages back to the calling program

• A parameter for general details of the creditor

• A parameter for specific details of the creditor

• A parameter for bank details of the creditor

for BAPI list

refer www.sapbapi.com

for FM's refer www.se37.com

regards

srinivas

<b>*reward for useful answers*</b>

[Former Member]

Hi,

goto following link

http://www.sapmaterial.com/RFCmaterial.html

Reward points if helpful.

Regards.

Srikanta Gope

[sridevi_p]

Hi,

Remote function module is to used when the FM is invoked from another system/client using RFC

Reagrds,

Sridevi

<i><b>Assign points if useful</b></i>