ABAP BDC RECORDING
7:32 AM Posted by Isha
Recording in BDC means that suppose you want to update some values in MM01 transaction and these values are in a flat file , so first start the recording from transaction sm35 an go new recording, here give the transaction name (e.g.-MM01) , and when the recording ends then go to the programme, it will give you the full recoding code , apply for these code in your original programme and then you will update the new values.
DATA TRANSFER METHODS
You can use the following methods to transfer data:
• Direct input: With direct input, the SAP function modules execute the consistency checks. However with batch input, these consistency checks are executed with the help of the screens. This means that direct input has considerable performance advantages.
• CALL TRANSACTION: Data consistency check with the help of screen logic.
• BATCH INPUT with batch input sessions : Data consistency check with the help of screen logic.
Batch Input
Batch input is a standard technique for transferring large sets of data into the R/3 System. Here the transaction flow is simulated and the data is transferred as if it were entered online. The advantage of this is that all relevant checks of the transaction are executed, thereby ensuring that the data is consistent.
The batch input process is divided into two phases:
1. The data transfer program creates a batch input session that contains all the relevant data.
2. The batch input session is processed and the data it contains is transferred into the R/3 System.
The majority of SAP standard data transfer programs use the batch input technique. The data transfer program creates a batch input session which is processed later. Batch input sessions can be processed in various ways:
• In the foreground
• In the background
• During processing, with error display
You should process BATCH INPUT sessions in the foreground or using the error display if you want to test the data transfer. If you want to execute the data transfer or test its performance, you should process the sessions in the background.
You can find detailed information on batch input in the Basis documentation BC - Basis Programming Interfaces under Transferring Data with Batch Input.
Difference between Batch Input and CALL TRANSACTION
If the direct input cannot be used for your task, this makes creating a data transfer program easier since the underlying transactions ensure that the data consistency checks are executed.
In the case of an error during the data transfer (if data records are inconsistent, for example), you can restart the transfer at the point in the program where the error occurred.
Batch input methods
With the batch input method, an ABAP program reads the external data that is to be entered in the R/3 System and stores the data in a "batch input session". The session records the actions that are required to transfer data into the system using normal SAP transactions.
When the program has generated the session, you can run the session to execute the SAP transactions in it. You can explicitly start and monitor a session with the batch input management function (by choosing System Services Batch input), or have the session run in the background processing system.
CALL TRANSACTION methods
In the second method, your program uses the ABAP statement CALL TRANSACTION USING to run an SAP transaction. External data does not have to be deposited in a session for later processing. Instead, the entire batch input process takes place inline in your program.
The information in Choosing Data Transfer Methods will help you decide which is the best data transfer method
The MODE Parameter
You can use the MODE parameter to specify whether data transfer processing should be displayed as it happens. You can choose between three modes:
A Display all. All screens and the data that goes in them appear when you run your program.
N No display. All screens are processed invisibly, regardless of whether there are errors or not. Control returns to your program as soon as transaction processing is finished.
E Display errors only. The transaction goes into display mode as soon as an error in one of the screens is detected. You can then correct the error.
The display modes are the same as those that are available for processing batch input sessions
The UPDATE Parameter
You use the UPDATE parameter to specify how updates produced by a transaction should be processed. You can select between these modes:
A Asynchronous updating. In this mode, the called transaction does not wait for any updates it produces to be completed. It simply passes the updates to the SAP update service. Asynchronous processing therefore usually results in faster execution of your data transfer program.
Asynchronous processing is NOT recommended for processing any larger amount of data. This is because the called transaction receives no completion message from the update module in asynchronous updating. The calling data transfer program, in turn, cannot determine whether a called transaction ended with a successful update of the database or not.
If you use asynchronous updating, then you will need to use the update management facility (Transaction SM12) to check whether updates have been terminated abnormally during session processing. Error analysis and recovery is less convenient than with synchronous updating.
S Synchronous updating. In this mode, the called transaction waits for any updates that it produces to be completed. Execution is slower than with asynchronous updating because called transactions wait for updating to be completed. However, the called transaction is able to return any update error message that occurs to your program. It is much easier for you to analyze and recover from errors.
L Local updating. If you update data locally, the update of the database will not be processed in a separate process, but in the process of the calling program. (See the ABAP keyword documentation on SET UPDATE TASK LOCAL for more information.)
The MESSAGES Parameter
The MESSAGES specification indicates that all system messages issued during a CALL TRANSACTION USING are written into the internal table . The internal table must have the structure BDCMSGCOLL .
This transaction allows a user to record keystrokes and other keyboard actions so that they may be incorporated into a BDC session. While any session may be recorded, it does not mean that the recording can be used to create a session. Within a recording individual screens may not be allowed.
Customized screens may present a problem. Only use the non-customized screens to record sessions.
In this example, the transaction MM is recorded.
Enter transaction SHDB, also called The Transaction Recorder:Recording Overview.
Click on the "New Recording button"
To start a new recording, enter a recording name (up to 10 letters) in the field labeled "Recording," and the Transaction Code MM01. Click either the "Start Recording" button or the green check mark at the bottom of the screen.
Recording the session:
Once the Start Recording button is pressed, the system displays the screens for the transaction code requested. Enter each field needed for the transaction, and proceed to the following screen. A "recording running" message may appear between screens. During a recorded session screen interaction time is extended.
Completing the transaction
End the transaction normally. When completed, the Transaction Recorder: Edit Recording screen is shown, Click the Save icon, which saves the recording. Green arrow back to the starting point (Transaction Recorder).
RELATED POSTS
SAP ABAP BAPI 1
SAP ABAP BAPI 2
SAP ABAP BAPI 3
SAP ABAP BAPI 4
RELATED POST
ALE IDOC'S COMPLETE SERIES
OOPS ABAP
ALE
IDOC'S
BADI
BAPI
Syntax Check
Interview Questions
ALV Reports with sample code
ABAP complete course
ABAP Dictionary
SAP Scripts
Script Controls
Smart Forms
Work Flow
Work Flow MM
Work Flow SD
Communication Interface
DATA TRANSFER METHODS
You can use the following methods to transfer data:
• Direct input: With direct input, the SAP function modules execute the consistency checks. However with batch input, these consistency checks are executed with the help of the screens. This means that direct input has considerable performance advantages.
• CALL TRANSACTION: Data consistency check with the help of screen logic.
• BATCH INPUT with batch input sessions : Data consistency check with the help of screen logic.
Batch Input
Batch input is a standard technique for transferring large sets of data into the R/3 System. Here the transaction flow is simulated and the data is transferred as if it were entered online. The advantage of this is that all relevant checks of the transaction are executed, thereby ensuring that the data is consistent.
The batch input process is divided into two phases:
1. The data transfer program creates a batch input session that contains all the relevant data.
2. The batch input session is processed and the data it contains is transferred into the R/3 System.
The majority of SAP standard data transfer programs use the batch input technique. The data transfer program creates a batch input session which is processed later. Batch input sessions can be processed in various ways:
• In the foreground
• In the background
• During processing, with error display
You should process BATCH INPUT sessions in the foreground or using the error display if you want to test the data transfer. If you want to execute the data transfer or test its performance, you should process the sessions in the background.
You can find detailed information on batch input in the Basis documentation BC - Basis Programming Interfaces under Transferring Data with Batch Input.
Difference between Batch Input and CALL TRANSACTION
If the direct input cannot be used for your task, this makes creating a data transfer program easier since the underlying transactions ensure that the data consistency checks are executed.
In the case of an error during the data transfer (if data records are inconsistent, for example), you can restart the transfer at the point in the program where the error occurred.
Batch input methods
With the batch input method, an ABAP program reads the external data that is to be entered in the R/3 System and stores the data in a "batch input session". The session records the actions that are required to transfer data into the system using normal SAP transactions.
When the program has generated the session, you can run the session to execute the SAP transactions in it. You can explicitly start and monitor a session with the batch input management function (by choosing System Services Batch input), or have the session run in the background processing system.
CALL TRANSACTION methods
In the second method, your program uses the ABAP statement CALL TRANSACTION USING to run an SAP transaction. External data does not have to be deposited in a session for later processing. Instead, the entire batch input process takes place inline in your program.
The information in Choosing Data Transfer Methods will help you decide which is the best data transfer method
The MODE Parameter
You can use the MODE parameter to specify whether data transfer processing should be displayed as it happens. You can choose between three modes:
A Display all. All screens and the data that goes in them appear when you run your program.
N No display. All screens are processed invisibly, regardless of whether there are errors or not. Control returns to your program as soon as transaction processing is finished.
E Display errors only. The transaction goes into display mode as soon as an error in one of the screens is detected. You can then correct the error.
The display modes are the same as those that are available for processing batch input sessions
The UPDATE Parameter
You use the UPDATE parameter to specify how updates produced by a transaction should be processed. You can select between these modes:
A Asynchronous updating. In this mode, the called transaction does not wait for any updates it produces to be completed. It simply passes the updates to the SAP update service. Asynchronous processing therefore usually results in faster execution of your data transfer program.
Asynchronous processing is NOT recommended for processing any larger amount of data. This is because the called transaction receives no completion message from the update module in asynchronous updating. The calling data transfer program, in turn, cannot determine whether a called transaction ended with a successful update of the database or not.
If you use asynchronous updating, then you will need to use the update management facility (Transaction SM12) to check whether updates have been terminated abnormally during session processing. Error analysis and recovery is less convenient than with synchronous updating.
S Synchronous updating. In this mode, the called transaction waits for any updates that it produces to be completed. Execution is slower than with asynchronous updating because called transactions wait for updating to be completed. However, the called transaction is able to return any update error message that occurs to your program. It is much easier for you to analyze and recover from errors.
L Local updating. If you update data locally, the update of the database will not be processed in a separate process, but in the process of the calling program. (See the ABAP keyword documentation on SET UPDATE TASK LOCAL for more information.)
The MESSAGES Parameter
The MESSAGES specification indicates that all system messages issued during a CALL TRANSACTION USING are written into the internal table
SAP ABAP BAPI 1
SAP ABAP BAPI 2
SAP ABAP BAPI 3
SAP ABAP BAPI 4
RELATED POST
ALE IDOC'S COMPLETE SERIES
ABAP TOPIC WISE COMPLETE COURSE
BDCOOPS ABAP
ALE
IDOC'S
BADI
BAPI
Syntax Check
Interview Questions
ALV Reports with sample code
ABAP complete course
ABAP Dictionary
SAP Scripts
Script Controls
Smart Forms
Work Flow
Work Flow MM
Work Flow SD
Communication Interface
