Scenario: Step-by-step creation of a BAPI to retrieve fields from table T001.
Procedure: Go to transaction SE11 and create a structure as shown or as per your requirement.
Give the name in the Data type field and click on create.
In the pop-up that comes up, select the radio button “structure”.
In the components tab of the structure, give the different fields and their corresponding field types and press enter to check the compatibility and creativeness.
Do not forget to save it in a package. You can even save it as a local object. For my example, I save it in a package.
Check the structure (ctrl + F2) and activate (ctrl + F3) the structure.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Now we are done with the creation of a Structure.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Go to transaction SE37 where you create function modules. Click on create after you enter the name of the Function module.
A screen as shown above would pop-up where you mention the function group to save the function module and also provide some short text describing your function module.
In the next pop-up that follows, click on continue as shown above.
The function module screen would look like the one above.
Go to the Attributes tab and select the radio button reading “remote-enabled module”.
Come back to the imports tab and provide the import parameters as shown or as per your requirement.
Now in the Export tab, provide the export parameters as shown or as per your requirement.
In the tables tab, provide the information as shown or as per your requirement.
The next screen you visit is the source code. It would look like this.
In the source code tab, write the following code in order to pick the data based on the input you provide.
Now, save and check the code and activate the function module.
After successful activation, go to the attributes tab. Go to Function moduleReleaseRelease.
+++++++++++++++++++++++++++++++++++++++++++++++
Now we are done with the creation of a Function Module.
+++++++++++++++++++++++++++++++++++++++++++++++
Go to transaction SWO1 and enter the name of the BAPI you would like to create or as shown in the screen and click the create button.
Give the name of the BAPI as above and click on create.
Give the above-mentioned details and click on the continue icon.
Save in a package.
The resulting screen is as follows.
Now click on the methods to drop down and see what methods are provided by default.
There would be two methods, showing in red color which comes by default while creating the BAPI.
Click or select the method as shown above and go to the path “UtilitiesAPI methodsAdd methods”.
On the screen that follows, provide the function module name and click on the continue icon.
In the ultimate pop-up, click the next step icon. We observe that the information is predefined in the fields.
This is the next screen where you would just click on the “next” icon.
Click on Yes. You can see an information message reading “ZBAPIFMT001” inserted.
Now save after you add the method. Select & Double click on the API method.
Go to Tab: ABAP Check 'API Function'.
The above screen is displayed. Go to the ABAP tab as shown below.
Select the Radio button reading “API Function” as already said above.
click on the continue icon to proceed further.
Now select the Object “ZBAPI_T001” as shown below.
Go to : EditChange Release StatusObject type To Modeled.
The above shown screen will be displayed. Click on yes.
The message shows, ‘The object type status set to modeled’. (Or already modeled) Go to: EditChange Release StatusObject type To Implemented.
You can see a message reading “Object type status set to implemented”
Now, go to: EditChange Release StatusObjectTo Released.
There would be two pop ups coming up. Click on continue on the Pop Ups.
Keep the cursor on the 'Method'.
Go to: EditChange Release StatusObject type componentTO Modeled.
You can see the message reading “status for method ‘zbapifmt001’ set to modeled”.
Now, go to: EditChange Release StatusObject type component TO Implemented
You can see the message reading “status for method ‘zbapifmt001’ set to implemented”.
Now go to: EditChange Release Status Object type component To Released
You can see the message reading “status for method ‘zbapifmt001’ set to Released”.
Click on Generate Button. (The red ball kind of button is the Generate button)
After clicking on the generate button, you can see the message reading “Object type 'ZBAPI_T001' generated successfully”.
Now go to BAPI Tcode (BOR) there we can find the BAPI (our BAPI) The BAPI browser would look like the screen below.
You can click on the Alphabetical tab so that you can browse the BAPI’s in an alphabetical order. Find your BAPI as shown.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Now we are done with the creation of a BAPI.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Test Your BAPI.
Enter the name of your BAPI in the transaction SWO1 and click on ‘Test’.
The above screen is displayed. Click on the Execute icon against the BAPI as shown.
The above screen is displayed where you would require entering the data against the empty input fields.
We have entered some data in the Field.
After entering the data, click on the execute icon as shown below.
The following screen is displayed which has some values as is indicated by the ITEMTAB.
Click on the Edit table icon as shown below.
The results as per our input are as shown below.
By this, we would get it confirmed that our BAPI is working properly.
We can even check it by passing different values again. Come back to the input and execution screen.
After executing the BAPI based on the input provided, we get the following screen.
Hit on the execute icon.
In the above shown screen, hit on the edit table icon.
The above is the output we get from the input we provided.
We are now done with the creation and successful execution of a BAPI.
ALE (Application Link and Enabling) & IDOC(Intermediate Documents)
What is ALE?
ALE (Application Link and Enabling) is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems.
ALE is the set of tools, programs, and data definitions that Provides the mechanism for distributing SAP functionality and data across multiple systems. ALE enables the construction and operation of distributed applications.
ALE Overview
From a System Infrastructure view, an SAP system consists of three layers:
The Database Layer stores and retrieves all data. The database contains all of the data related to the SAP system, including the ABAP programs, the Configuration data, the master data, and the transaction data.
Application layer: This layer provides ALE with an interface to R/3 to originate or receive messages containing data to or from external (or other R/3) systems and executes the SAP programs and processes requests from users.
The Presentation Layer contains the SAP Graphical User Interface (GUI), and handles all user input and output.
Together, the three layers make up the three-tiered client-server architecture of SAP.
We can distribute the three layers over any number of physical computers. However, there may only be one database server.
From a Database or Configuration view, the SAP system consists of:
Client-Independent data, such as ABAP programs, client-independent tables, etc.
One or more Clients. Each client contains its own client-dependent configuration (Company hierarchy, process configurations, etc.), master data (customer,
Material, vendor, etc.), and transaction data.
The Basic Ideas of ALE
ALE is a technology introduced by SAP with its 3.0 release. Its purpose was to overcome the limitations of a single SAP system. A single SAP system that runs on top of one database often does not fulfill the needs of larger corporations, either from a business or a technical perspective.
ALE allows the implementation of loosely coupled SAP systems; each of the SAP systems has its own database and is essentially independent from the other systems. ALE allows us to distribute data between different systems and different business processes.
The distribution of data happens at the application server level (Hence, Application Link Enabling).
SAP supports a number of distribution scenarios, which define how different SAP systems can interact. The scenarios define what messages are sent back and forth between the systems (for example, Contract information needs to be exchanged between systems that run central purchasing and systems that run decentral purchasing).
The “data container” that carries the message is the Intermediate Document, or IDoc.
SAP delivers over 100 IDoc types to support its distribution scenarios; along with the IDocs come the associated programs to generate (on the outbound side) or to process (on the inbound side) IDocs.
Part of ALE is a communication infrastructure; specifically ALE uses the “transactional RFC” technology to ensure the transaction consistency across system boundaries. ALE also ties into SAP workflow to handle errors in the data transfer process.
ALE scenarios fall into three categories: master data, transactional data, and control data distribution. Although the underlying principles are the same for the different categories, there are differences in their functions and configurations. SAP delivers over 200 ALE scenarios; and by extension there are approximately 200 application areas that can leverage ALE technology for data distribution or communication. A subset of these scenarios is supported by R/3 for Electronic Data Interchange (EDI).
There are several advantages to using ALE technology:
ALE Building Blocks and Concepts
The following building blocks are fundamental to ALE functionality:
Logical System: A Logical System (LS) is the representation of an R/3 or external system in SAP R/3 for the distribution of data to and from the R/3 System. Every R/3 client used for ALE or EDI has to have a base LS associated with the client. This LS becomes the “sender” for outbound messages and a “receiver” for inbound messages. In addition to the base LS, a second LS should be created within that R/3 system for each R/3 or external system used for ALE interfaces. In an inbound ALE interface, this second LS represents the sender (another R/3 or external system) with respect to the base LS (receiver). In an outbound ALE interface, this second LS is the receiver on behalf of the R/3 or external system with respect to the base LS (sender).
Message type: A message type represents the application message exchanged between R/3 systems and R/3 and an external system. A message type characterizes the data sent across systems and relates to the structure of the data called an IDOC type (see below).
For example, MATMAS is a message type for Material Master, and INVOIC is a message type for an Invoice (Billing Document). ALE supports over 200 message types in R/3 and about 200 application areas.
IDOC type and IDOC: An Intermediate Document (IDOC) type represents the structure of the data associated with a message type (DEBMAS02 for message type DEBMAS — Customer Master, and WMMBID02 for message type WMMBXY— Goods Movements), while an IDOC is an object containing the data of a particular message type. IDOCs are data containers with intelligence built in. Each IDOC contains one and only one business object. For example, an IDOC of type SHPMNT01, message type SHPMNT, will contain data only of one Shipment Document. Generally, the architecture of an IDOC is independent of the message type by virtue of ALE’s ability to redefine it for any message type.
Customer Distribution Model: In an R/3 system, the Customer Distribution Model is a tool that stores information about the flow of messages across various systems. The Customer Distribution Model uses an SAP-delivered Distribution Reference Model as its basis (the Customer Distribution Model can have distribution scenarios other than ones
stored in the Distribution Reference Model.) The Customer Distribution Model stores data that dictates which messages (message types) flow to which Logical Systems. Many messages can flow to one Logical System, and one message can flow to several systems.
With the use of filter objects and listings (which I’ll describe shortly), it is also possible to specify in a model the criteria for filtering information for a specific system. A Customer Distribution Model can be created in an R/3 system with that client’s base Logical System as the “sender” Logical System.
ALE provides powerful capabilities to capture changes occurring to master data and to distribute them via the IDOC interface. This feature can be used to keep two or more systems synchronized with respect to master data.
Ports: A port is a logical representation of a communication channel in SAP, with the data communicated being IDOCs. There are four types of ports that can be defined in R/3: tRFC, File, R/2, and Internet. ALE can use all port types to distribute IDOCs, while EDI typically uses a file-based port. tRFC and File ports can link to RFC destinations connected to R/3-to-R/3 or TCP/IP. By linking ports to RFC destinations, the port can also trigger scripts to invoke EDI subsystems, IDOC mapping software, and FTP.
You can maintain ports by executing transaction WE21 or WEDI, or selecting IDOC ->
Port Definition. RFC destinations can be maintained using transaction SM59.
Partner profile: A partner profile is an identifier for a system used for communicating messages. There are four types of partner profiles: KU for Customer, LI for Vendor, B for Bank, and LS for Logical System. KU, LI, and B are used for EDI partners, while LS is used for ALE communications. Every partner profile used for ALE must be based on an existing LS.
A partner profile brings together several ALE and EDI elements to define the parameters of communication between two or more systems. Other than general information, you have to maintain inbound parameters, outbound parameters, and message control. The main parameters are message types, IDOC types, process codes, partner functions, application identifiers, message functions, output types, and ports. Other parameters also determine the mode of processing and error handling.
A partner profile plays a major role and can be viewed as a gateway for ALE and EDI communications. It routes the specified messages through defined IDOC types to a given port after invoking the appropriate function modules for outbound processing. It receives IDOCs of a specific type, and it identifies modules to post data to the application databases in the case of inbound interfaces.
RFC Destination:Used to define the characteristics of communication links to a remote system on which a functions needs to be executed.
Process: The processes in the application layer and the ALE layer are completed on both the inbound and outbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface.
The process can be divided into the following sub-processes:
1. Outbound Processing 2. Inbound Processing
Why use ALE?
ALE provides for the integration of distributed applications, but why would we distribute applications in the first place? There are several technical and business reasons:
System Performance: The transaction load is too heavy for a single SAP system.
High Availability Requirements: The company cannot afford downtime due to backups, maintenance, upgrades, etc.
SAP Release Coordination: Different units of the organization may require different releases of the SAP software.
Very Large Database: Companies with very large databases may need to distribute the data across multiple SAP systems.
Business Structure: Business units may require independence and autonomy for day-to-day operations, and yet still need to share some data and functionality with other units in the enterprise.
Interfacing with non-SAP systems: The company may wish to maintain certain applications on non-SAP systems, while at the same time integrate these applications and their data with the SAP system.
Keep development system data in sync with production data: An
organization may wish to keep the data on a development system the same as on a production system.
Maintain configuration and master data across clients: Organizations using multiple clients may wish to maintain certain data on a client-independent basis.
What can we distribute with ALE?
We can distribute all types of data with ALE:
Control or Customizing Data: Control data includes all configuration objects that define how the SAP system is organized. This includes the enterprise structure configurations, global settings, etc.
Master Data: Master data objects that can ALE can distribute include:
Material Master
Customer Master
Vendor Master
Cost Centers
Activity Types
G/L Accounts
Characteristics/Classes/Classifications and many others
Transaction Data: Transaction data is data related to specific business transactions or processes (e.g. sales orders, credit memos, invoices).
SAP delivers several hundred predefined distribution scenarios. If a standard solution is not provided, then we can develop a custom scenario to distribute any data required by the business. The number of supported business scenarios increases with each SAP release.
Example distribution scenario: Sales and Distribution
The sales system provides only the logistics data that the warehouse requires to fill an order. Summary information is reported into the central sales information system. All of the data sent references a single order document.
The Intermediate Document (IDoc)
The Intermediate Document, or IDoc, is the main component of all interface functionality in SAP. Each interface message type has an associated IDoc type. The IDoc, in turn, defines the structure and formatting of the data contained within the message type.
IDocs provide support for customized development:
API for development
Easy to use and apply
Real-time or asynchronous interface connection
Independent of external system data requirements
Independent of type of external system
The data interface standard is standardized according to the following key rules:
The documentation of the interface is published.
SAP takes responsibility for compatibility of the interface standard for its own applications.
Field lengths and types are defined according to the data element definitions of the EDIFACT EDI standard and SAP’s data repository.
Codes for coded fields are taken from international standards where the standard applies.
IDoc Structure
An IDoc consists of three record types:
Control Record: Contains the data that uniquely identifies the IDoc.
Data Records: Contain the application data related to the message type. An IDoc may have multiple data records, called segments. A data segment is made up of a
key section and a data section. The key section uniquely identifies its respective data segment.
Status Records: Contain the information relative to the various statuses that the IDoc encounters, such as IDoc created, document posted, etc.The IDoc is data
The Control Record stores the characteristics of the IDoc. Some of the more important fields are: number. This ID number is assigned by SAP for all IDocs.
The IDoc Data Records
The Data Records contain the actual application data. Some of the more important fields are:
IDoc ID Number (DOCNUM)
Segment Name (SEGNAM)
IDoc Data (SDATA) (structure differs with each IDoc type)
The Data Records are stored in table EDID4 (EDID2 in prior versions), keyed by IDoc number and segment number. The table structure is 71 bytes of administration data (IDoc number, segment identifier, etc.) Followed by 1000 bytes of free-form application data.
Each segment type uses a different format for the 1000 bytes of
Each segment type uses a different format for the 1000 bytes of