Cross Applications

1
Introduction

▪ SAP technical objects are divided in to 6 different areas(RICEFW).

▪ R - Reports , I - Interfaces , C - Conversion , E - Enhancements , F - Forms , W - Workflow

▪ SAP cross applications are the part of interfaces which helps to transfer the data

between the systems.

▪ With the help of cross applications, we can transfer the data from Non-SAP to SAP , SAP

to Non-SAP and SAP to SAP systems.

▪ The various cross applications are - BAPI, RFC ,IDOC’s( ALE & EDI) etc.
2
Requirement

▪ Customer will provide the employee data in the file.

▪ We will migrate the employee data in SAP system using BAPI with IDOC interface.

▪ The various steps involved in this requirement are as follows :

 Step1 : Creation of BAPI

 Step2 : Creation of IDOC interface for BAPI

 Step3 : Migrating the employee data using business object method(BAPI with IDOC

interface) of LSMW.
3
BAPI

▪ B - Business A - Application P - Programming I - Interface

▪ BAPI is a standard programming interface that enables the external access

to business process in the SAP system.

▪ An external system (may be as SAP system or any other system uses programming

language like JAVA or Visual Basic or C++ ) can make a call to BAPI.

▪ BAPI’s in the SAP systems are implemented as function modules.

▪ BAPI = function module + business object.

4
BAPI(Contd.)

▪ A BAPI is defined in the business object repository(BOR).

▪ The transaction code to display the BAPI’s is BAPI (BAPI explorer).

5
Prerequisites for BAPI

▪ The function module name must start with <namespace>BAPI_<business

object>_<method>.

▪ All parameters associated type must begin with <namespace>BAPI.

▪ All parameters must be pass by value.

▪ It must contain a parameter RETURN of type ' BAPIRET2'.

▪ Function module must be RFC-enabled.

▪ Function module must be released.

6
Creation of Business Object

▪ Transaction code for business object builder: SWO1

▪ We need to provide the below mentioned things while creating the business object.

 Super Type - To inherit the components of existing object type.

 Object Type - It is used for internal identification of the business object.

 Object Name - It is used for external identification of the business object. Using this

property external system can interact with SAP system.

 Name - It is a descriptive name of the business object.

7
Creation of Business Object(Contd.)

▪ Description - It is a brief description of the business object type.

▪ Program - Program that will contain the ABAP code of the business object.

▪ Application - The application component to which the business object belongs to

( * stands for cross application).

8
Status of Business Object/Business Object Components

▪ There are 4 status for business object/business object components.

1. Modeled

2. Implemented

3. Released

4. Obsolete

9
Modeled

▪ This status means the business object/business object components are defined.

1
0
Implemented

▪ This status means business object/business object components have got full

functionality implemented.

▪ They can be used for internal purpose (within SAP) and for testing purpose.

1
1
Released

▪ This status means business object/ business object components have got full

functionality and the interface is freeze.

▪ This will make an entry in the BAPI explorer and can be invoked from external

application as well (Non-SAP).

1
2
Obsolete

▪ This status means that business object/business object components can not be used.

1
3
Functions(Benefits) of Business Object

▪ At BO level, non-SAP systems can communicate with SAP system. This can be done using

BAPI’s.

▪ BO types acts as entry points to data and functions for an SAP System.

▪ BO's can be used in business workflows, ALE etc.

1
4
Tables Related to Business Object

▪ Table for business object repository(BOR) basic data : TOJTB

▪ Table for business object detailed information : SWOTLV

1
5
IDOC’s - Introduction

▪ The full form of IDOC is Intermediate Documents.

▪ IDOC is a data container (data file) which is exchanged between two systems or two

processes.

▪ Every IDOC has a unique number.

1
6
IDOC Processes

▪ There are 2 types of IDOC processes.

1. Inbound process

2. Outbound process

1
7
Inbound Process

▪ If the data is coming into SAP system, it is called as inbound process.

1
8
Outbound Process

▪ If the data is going out from the SAP system, it is called as outbound process.

1
9
IDOC Data Exchange Methods/Technologies

▪ There are 2 types of data exchange methods/technologies in IDOC.

1. ALE

2. EDI

2
0
ALE

▪ ALE is a proprietary SAP technology.

▪ The full form of ALE is Application Link Enabling.

▪ If the format of data is not changing between the systems, it is called as ALE.

▪ ALE is always from SAP-to-SAP system.

▪ For example - There is a purchase order in SAP system -1 and the same purchase order

data flows to other SAP system-2. It is called as ALE, as the format of data is not

changing.
2
1
ALE(Contd.)

▪ ALE is always with in the business.

2
2
EDI

▪ EDI is a much older term and has been used in existence much before SAP.

▪ The full form of EDI is Electronic Data Interchange.

▪ If the format of data is changing between the systems, it is called as EDI.

▪ EDI is between SAP to Non-SAP, Non-SAP to SAP and SAP-SAP.

▪ For example - There is a purchase order in System -1, when the purchase order data

flows to another system, it converted to sales order. It is called as EDI, as the format of

data is changing.
2
3
EDI(Contd.)

▪ EDI is across the business.

2
4
IDOC Architecture

▪ IDOC architecture has 3 parts

1. Control record

2. Data record

3. Status record

 Imp point : The transaction code to display the IDOC is WE02 or WE05.

2
5
Control Record

▪ It provides the control information such as IDOC type (basic type), message type, port,

partner number etc.

▪ It also provides the directions (inbound, outbound) of IDOC.

▪ The value 1 is for outbound IDOC and the value 2 is for inbound IDOC.

▪ It stores in table EDIDC.

2
6
Data Record

▪ It provides the whole data of the IDOC.

▪ The data is stored in the segments.

▪ It stores in table EDID4.

2
7
Status Record

▪ It provides the status of the IDOC (successful / error).

▪ The values 1-42 are for outbound IDOC status and 50-75 are for inbound IDOC status.

2
8
Message Type

▪ It specifies the meaning of the data.

▪ It tells for which purpose the IDOC is going to fire.

▪ Example - We are transferring employee data.

▪ The transaction code for the message type is WE81.

2
9
IDOC Type

▪ It is also called as Basic Type.

▪ It specifies the structure of the data which is to be exchanged.

▪ Example - While transferring employee data , empid empname are the examples of

IDOC type.

▪ The transaction code for the IDOC type is WE30.

3
0
Difference between IDOC Type and Message Type

▪ IDOC type specifies the structure of the data whereas message type specifies the

meaning of the data.

3
1
Segments

▪ Segments are the basic elements of an IDoc type.

▪ Data is stored in the segments.

▪ The transaction code for the segments is WE31.

3
2
IDOC(ALE) Interface for BAPI

▪ Transaction Code to create ALE interface for BAPI : BDBG

▪ Table to store the BAPI-ALE interface for inbound processing: TBDBE

3
3
IDOC Settings - Port

▪ Port defines the technical link between sender and receiver system.

▪ Ports in the SAP system acts as a communication channel to send IDOC’s.

▪ The transaction code to create a port is WE21.

▪ The most commonly types of ports are:

 TRFC port

 File port

3
4
TRFC Port

▪ TRFC stands for transactional port.

▪ Here we define the ports for RFC destinations created using SM59.

3
5
File Port

▪ While using file port we can specify the directory where the IDOC file should be placed.

▪ The other system or the middleware will pick up the file from here.

3
6
IDOC Settings - Partner Profile

▪ A partner is one whom we conduct business & exchange documents.

▪ In the partner profile of a partner , we maintain the parameters that are necessary for

exchanging the data.

▪ The transaction code to create a partner profile is WE20.

3
7
Logical System

▪ A logical system is used to identify an individual client in a system.

▪ A logical system is a unique ID within an SAP system that identifies a partner

communication system.

▪ Naming conventions for Logical system : TR2CLNT800( SystemidCLNTclientnumber)

▪ The transaction code for Logical system is BD54.

3
8
Process Code

▪ The process code contains the details of the function module that are used for IDOC

processing.

▪ There are 2 types of process codes.

1. Inbound process code

2. Outbound process code

3
9
Inbound Process Code

▪ It process the IDOC & send data to application.

▪ The transaction code for inbound process code is WE42.

4
0
Outbound Process Code

▪ It take data from the application & send data to IDOC.

▪ The transaction code for outbound process code is WE41.

4
1
Test Tool for IDOC(WE19)

▪ WE19 is the transaction code for the test tool for IDOC.

▪ This tool generates new IDOC number.

▪ We can process 1 IDOC at a time.

 Imp point : Do not use WE19 for reprocess purpose, It is only for testing and debugging

purposes.

4
2
Reprocessing of Error IDOC’S(BD87)

▪ BD87 is the transaction code to reprocess the error IDOC’s.

▪ After reprocess, it does not generate new IDOC number.

▪ We can process any number of error IDOC’s at a time.

4
3
Transaction Codes and Tables Related to BAPI

▪ Transaction code for business object builder - SWO1

▪ Transaction code for BAPI explorer - BAPI

▪ Table for business object repository(BOR) basic data - TOJTB

▪ Table for business object detailed information - SWOTLV

4
4
Transaction Codes and Tables Related to BAPI-IDOC Interface

▪ Transaction Code to generate ALE(IDOC) interface for BAPI - BDBG

▪ Table for BAPI-IDOC interface for inbound processing - TBDBE

4
5
Transaction Codes Related to IDOC’s

▪ Transaction code to develop IDOC types - WE30

▪ Transaction code to develop segments - WE31

▪ Transaction code for message types - WE81

▪ Transaction code for mapping of IDOC type & message type - WE82

▪ Transaction code for assignment of function module to message type & IDOC type -

WE57

▪ Transaction code for ports in IDOC processing - WE21

4
6
Transaction Codes Related to IDOC’s

▪ Transaction code for partner profile - WE20

▪ Transaction code for inbound process code - WE42

▪ Transaction code for outbound process code - WE41

▪ Transaction code for IDOC list - WE02 , WE05

▪ Transaction code of test tool for IDOC processing - WE19

▪ Transaction code to reprocess the error IDOC’s - BD87

4
7
Tables Related to IDOC’s

▪ Table to store IDOC control record - EDIDC

▪ Table to store IDOC data record - EDID4

▪ Table to store IDOC status record - EDIDS

4
8
Other Transaction Codes

▪ Transaction code for RFC connections - SM59

▪ Transaction code for logical systems - BD54

4
9
RFC - Introduction

▪ RFC stands for Remote Function Call.

▪ As the name itself is suggesting, with the help of RFC we can connect with the external

system, the external system can be SAP or Non-SAP system.

▪ In all SAP systems, CALL FUNCTION represents an integral part of ABAP language.

▪ The statement CALL FUNCTION executes a function module in the same system.

▪ RFC is an extension of CALL FUNCTION in a distributed environment.

▪ Existing function modules can be executed using an RFC from a remote system.
5
0
RFC - Introduction(Contd.)

▪ This is done by adding a DESTINATION clause to the CALL FUNCTION statement.

▪ Syntax : CALL FUNCTION ‘ZFM_ORDER’ DESTINATION ‘A4H’.

In the above syntax - CALL FUNCTION = keyword, ZFM_ORDER = name of the function

module, DESTINATION = keyword, A4H = name of the source system in which function

module is created.

5
1
Difference Between BAPI and RFC

▪ BAPI = RFC function module + business object. The external system connects with the

business object and that business object calls the RFC function module whereas in the

case of RFC, external system directly connects with the RFC Function Module.

▪ BAPI is based upon OOPS concepts whereas RFC does not follow OOPS concepts.

5
2
Pre-Requisites for RFC

▪ RFC function module is just like a function module created in the transaction SE37, with

some specific pre-requisites.

1. The processing type of the function module should be remote-enabled module.

2. All parameters must be pass by value.

5
3
Steps to Send Materials from one SAP Client to Another SAP Client

▪ Below are the steps to send materials from one SAP client to another SAP client using

ALE.

1. Create logical systems using transaction code SALE.

2. Assign logical system to the client using transaction code SALE.

3. Create and check the RFC connection using transaction code SM59.

4. Create a transactional RFC port using transaction code WE21.

5
4
Steps to Send Materials from one SAP Client to Another SAP Client

5. In the source client , create a partner profile for receiver client using transaction code

WE20.

6. In the receiver client , create a partner profile for source client using transaction code

WE20.

7. Create a distribution model using the transaction code BD64 - The purpose of

distribution model is to describes the ALE message flow between logical systems.

5
5
Steps to Send Materials from one SAP Client to Another SAP Client

8. Create materials using MM01 transaction code.

9. Send the materials through BD10 transaction code.

10. Check the generated IDOC’s using WE02/WE05 transaction code.

5
6
Program - RBDMIDOC

▪ The program RBDMIDOC is used to generate the IDOC’s for a message type using the

change pointers.

 Imp Point : In real projects, we schedule this program in the background which runs at

regular intervals.

5
7
Change Pointers Technique

▪ For the purpose of distributing data via ALE to other systems, the change pointers

technique is used.

▪ It’s purpose is used to distribute the data changes made in one SAP client to other SAP

clients.

▪ Change pointers log/history is stored into (BDCP, BDCPS) or BDCP2 tables.

▪ The change pointers technique is based on the change document technique.

▪ Change document technique is used to track the changes made to that document.
5
8
Change Pointers Technique(Contd.)

▪ Change document log/history is available in CDHDR(header table) & CDPOS(item table).

 Imp point : Change document technique is used to track the changes made to that

document whereas change pointer technique is used to distribute that changes to other

clients.

5
9
Configuration Steps for Change Pointers

▪ Below are the configuration steps for the change pointers.

1. Enable change pointers globally - Transaction code : BD61

2. Enable change pointers for a message type - Transaction code : BD50

3. Specify the fields for which change pointers are to be written - Transaction code : BD52

6
0
Configuration Steps for Change Pointers

1. Enable change pointers globally - Transaction code : BD61. This option enables the

change pointer process globally. Make sure that the flag is checked.

2. Enable change pointers for a message type - Transaction code : BD50. This setting is

required for activating change pointers for a specific message type. Make sure that the

active flag is checked for specific message type.

6
1
Configuration Steps for Change Pointers(Contd.)

3. Specify the fields for which change pointers are to be written - Transaction code : BD52.

SAP already provided a list of fields for which change pointers are written. If we are

satisfied with the standard set of fields, we can skip this step. If we want to add new

fields, we must add entries for the required fields. If we don’t want to generate the

Idoc’s for changes to a particular field, we can remove it from the list.

6
2
Thank You

6
3