How to Debug the Outbound IDoc Programs/Function modules.

Take Sales order Outbound IDoc Process as an example.
Put the Break points in outbound programs, where ever you want.
Enter T Code VA02 for changing the order.

Provide the Order number and Press enter.

In Menu Path: Extras -> Output -> Header -> Edit.

Select the Output type and Click on Repeat output button.

Now Select the Output type again and click on further data button.

Select Send with periodically scheduled job.

Click on Back.

Now click on Save. An entry will be created in NAST table, once order is saved.

Go to SE11 and Check the entry in NAST table by providing Application and Date.

Copy the Object Key.


Now Go to WE15 to process Outbound IDoc.
Provide Application, Object Key and Output Type. And Execute.

ABAP Debugger will be on.

SAP SD Flow with TCodes and Tables

RFC Programming/Functionality in ABAP

RFC Programming in ABAP

A remote function call is a call to a function module running in a system different from the caller's.

In the SAP System, the ability to call remote functions is provided by the Remote Function Call interface system (RFC).

RFC allows for remote calls between two SAP Systems (R/3 or R/2), or between an SAP System and a non-SAP System.

RFC functions running in an SAP System must be actual function modules, and must be registered in the SAP System as "remote".

When both caller and called program are ABAP programs, the RFC interface provides both partners to the communication.

The caller may be any ABAP program, while the called program must be a function module registered as remote.

REMOTE FUNCTION CALL (RFC) is an extension of CALL FUNCTION in a distributed environment.
Existing function modules can be executed from within a remote system (R/2 or R/3) via an RFC call.
This is done by adding a DESTINATION clause to the CALL FUNCTION statement.

RFC frees the ABAP programmer from having to program his own communications routines.

Parameters declared as type REFERENCE cannot be used in remote function calls.

TYPES OF Remote Function Calls :

Synchronous Remote Function Call.
Asynchronous Remote Function Call.
Transactional Remote Function Call.
Queue Remote Function Call.
Web Remote Function Call(Not Covered)


Synchronous Remote Function Calls :

Synchronous remote function calls (RFCs) are those where the user have to wait for their completion before continuing the calling dialog.

In simple terms , “ calling program must wait for the return values to perform further processing”.

Asynchronous Remote Function Calls :
Asynchronous remote function calls (aRFCs) are those where the user does not have to wait for their completion before continuing the calling dialog.
There are three characteristics of asynchronous RFCs :
When the caller starts an asynchronous RFC, the called server must be available to accept the request.
The calling program can receive results from the asynchronous RFC.

In simple terms , “ calling program need not wait for the return values to perform further processing”.

You must not use IMPORTING when calling aRFCs.

Transactional Remote Function Calls :

From Release 3.0 onwards, data can be transferred between two R/3 Systems reliably and safely via transactional RFC (tRFC).

The called function module is executed exactly once in the RFC server system.
The remote system need not be available at the time when the RFC client program is executing a tRFC.

If a call is sent, and the receiving system is down, the call remains in the local queue until a later time.
The calling dialog program can proceed without waiting to see whether or not the remote call was successful.

If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch.

Transactional RFCs use the suffix IN BACKGROUND TASK.

Queue RFC :

qRFC With Send Queue
To guarantee an LUW sequence dictated by the application, the tRFC is serialized using queues.
It is therefore called queued RFC (qRFC). Due to the serialization, in R/3 a send queue for tRFC is created. This results in the general term qRFC with send queue.

ALE IDoc Creation steps with T Codes

INBOUND IDOC

Segment : Create Segements Using WE31
IDoc Type : Create IDoc Type and Assign Segment to IDoc Type Using WE30
Release : Release Segements and IDoc Type using WE31 and WE30 Respectively
Message Type : Create Message Type Using WE81
And Assign IDoc Type to the Message Type Using WE82
Function Modules : Create Function Module Using SE37
Process Code : Create Process Code Using WE42
Characteristics : Maintain characteristics of Inbound Function Modules Using BD51
Relate FM,Msg Type : Assign Function Module to Message type Using WE57
Partner Profile : Create Partner Profile Using WE20
And Assing Message type under Inbound parameters

OUTBOUND IDOC

Segment : Create Segements Using WE31
IDoc Type : Create IDoc Type and Assign Segment to IDoc Type Using WE30
Release : Release Segements and IDoc Type using WE31 and WE30 Respectively
Message Type : Create Message Type Using WE81
And Assign IDoc Type to the Message Type Using WE82
Function Modules : Create Function Module Using SE37
Relate FM,Msg Type : Assign Function Module to Message type Using WE57
Partner Profile : Create Partner Profile Using WE20
And Assing Message type under Outbound parameters
Port : Create/Use Existing Port Using WE21

SAP R/3 Architecture

SAP R/3 - Systems Applications and Products in 3 Tier Architecture.

Typical structure of an R/3 system is as below

Presentation Layer
Application Layer
Database Layer

Presentation Layer is nothing but the system/pc we/end user accesses to perform the activity

Application layer will receives the request from user(i.e, presentation layer) and performs the activity based on the request.

Database Layer is nothing but Database. when an activity is running in application layer and that particular activity needs some data than a request will come to Database layer,Database layer sends back the data.

Creating Custom BAPI - step by step

Step 1: Create Structure/Structures for parameters, which we need in SE11


Use Data elements while creating structure fields


Step 2 : Create Function Module using SE37


Select Radio Button “Remote-Enabled Module”


Provide Import Parameters as below and select Pass by Value.


Provide Tables for output and Return table to handle Errors


Write the code to retrieve the data.


Save Check and Activate the function module. And go back
In Menu, Go to Function Module -> Release -> Release


Step 3 : Create Object type for Function Module
Create Object type in SWO1


Provide Object name,Name,Description,Program and Application


Open Node of Method and Select Method.
Now in Menu, Goto Utilities -> API Methods -> Add Method.


Provide Function Module,Which was created in Step 2 and Hit enter.


Check on Next.


Check all the parameters and click on Next


Click on Save.


Now Click on Save and Select Object Type.
In Menu, Goto Edit -> Change Release Status -> Object Type -> To Modeled


Click on Save


In Menu, Goto Edit -> Change Release Status -> Object Type -> To Implemented


In Menu, Goto Edit -> Change Release Status -> Object Type -> To Released


Now Select Function Module in Method.
In Menu, Goto Edit -> Change Release Status -> Object Type Component -> To Modeled


In Menu, Goto Edit -> Change Release Status -> Object Type Component -> To Implemented


In Menu, Goto Edit -> Change Release Status -> Object Type Component -> To Released


Finally Click On Generate.


Step 4 : Check it in BAPI Repository