INBOUND IDOC
1)Segment :: Create Segements Using WE31
2)IDoc Type :: Create IDoc Type and Assign Segment to IDoc Type Using WE30
3)Release :: Release Segements and IDoc Type using WE31 and WE30 Respectively
4)Message Type :: Create Message Type Using WE81
And Assign IDoc Type to the Message Type Using WE82
5)Function Modules :: Create Function Module Using SE37
6)Process Code :: Create Process Code Using WE42
7)Characteristics :: Maintain characteristics of Inbound Function Modules Using BD51
8)Relate FM,Msg Type :: Assign Function Module to Message type Using WE57
9)Partner Profile :: Create Partner Profile Using WE20
And Assing Message type under Inbound parameters
OUTBOUND IDOC
1)Segment :: Create Segements Using WE31
2)IDoc Type :: Create IDoc Type and Assign Segment to IDoc Type Using WE30
3)Release :: Release Segements and IDoc Type using WE31 and WE30 Respectively
4)Message Type :: Create Message Type Using WE81
And Assign IDoc Type to the Message Type Using WE82
5)Function Modules :: Create Function Module Using SE37
6)Relate FM,Msg Type :: Assign Function Module to Message type Using WE57
7)Partner Profile :: Create Partner Profile Using WE20
And Assing Message type under Outbound parameters
8)Port :: Create/Use Existing Port Using WE21
Friday, November 5, 2010
Friday, October 8, 2010
How to debug outbound Idoc/Function module
Debugging of Outbound IDoc :
Take an example of sale order using VA02.
Put the break points in IDoc function module,which you want to debug
Open a sale order and goto Extras->Output->Header->Edit using Menu option
Repeat the output by selecting an output type
Click on further data button
Select Send with periodically scheduled job
Go Back
Save the Order
Goto SE11 and open NAST table with application and output type
Pick the respective Object key
Open WE15 and provide Object key along with application and output type etc.
Execute it will goto debugging mode.
Wednesday, September 8, 2010
Friday, September 3, 2010
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.
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.
Thursday, September 2, 2010
SAP R/3 Architecture
SAP R/3 - Systems Applications and Products in 3 Tier Architecture.
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.
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.
Subscribe to:
Posts (Atom)