Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Recording the bdc

Former Member
0 Kudos

What does it mean?

After recording the bdc what comes next?

Thanks.

5 REPLIES 5

amit_khare
Active Contributor
0 Kudos

After Recording the BDC convert it inot program remove unwanted fields and Pass your Values to Require Fields.

Then Do CALL TRNASACTION.

Regards,

Amit

Reward all helpful replies.

Former Member
0 Kudos

hi,

Recording means whatever u do for a transaction its recorded.

Goto SHDB.

there give the transaction code .

for example MM01 for material master.

Then click the button Start Recording.

U should enter all the mandatory fields and save it.

Recording is saved and u can generate a report from that recording.

It is done for the conversions.

Conversion-to upload data from non-sap to sap system.

Former Member
0 Kudos

Hi,

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 recotding code , apply for these code in your original programme and then you will update the new values.

For more information go through the following l-----

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.

Data Transfer Overview

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 <MESSTAB> . The internal table must have the structure BDCMSGCOLL .

You can record the messages issued by Transaction TFCA in table MESSTAB with the following coding:

(This example uses a flight connection that does not exist to trigger an error in the transaction.)

DATA: BEGIN OF BDCDATA OCCURS 100.

INCLUDE STRUCTURE BDCDATA.

DATA: END OF BDCDATA.

DATA: BEGIN OF MESSTAB OCCURS 10.

INCLUDE STRUCTURE BDCMSGCOLL.

DATA: END OF MESSTAB.

BDCDATA-PROGRAM = 'SAPMTFCA'.

BDCDATA-DYNPRO = '0100'.

BDCDATA-DYNBEGIN = 'X'.

APPEND BDCDATA.

CLEAR BDCDATA.

BDCDATA-FNAM = 'SFLIGHT-CARRID'.

BDCDATA-FVAL = 'XX'.

APPEND BDCDATA.

BDCDATA-FNAM = 'SFLIGHT-CONNID'.

BDCDATA-FVAL = '0400'.

APPEND BDCDATA.

CALL TRANSACTION 'TFCA' USING BDCDATA MODE 'N'

MESSAGES INTO MESSTAB.

LOOP AT MESSTAB.

WRITE: / MESSTAB-TCODE,

MESSTAB-DYNAME,

MESSTAB-DYNUMB,

MESSTAB-MSGTYP,

MESSTAB-MSGSPRA,

MESSTAB-MSGID,

MESSTAB-MSGNR.

ENDLOOP.

The following figures show the return codes from CALL TRANSACTION USING and the system fields that contain message information from the called transaction. As the return code chart shows, return codes above 1000 are reserved for data transfer. If you use the MESSAGES INTO <table> option, then you do not need to query the system fields shown below; their contents are automatically written into the message table. You can loop over the message table to write out any messages that were entered into it.

***do rewards if usefull

Regards,

vijay

Former Member
0 Kudos

After the first data entry, I can change this data when I call the bdc with the data coming from an internal table....Right?

Thanks in advance.

Deniz.

Former Member
0 Kudos

you can also generate the program from your recording.

goto sm35

select the recording and click on program creation.

This will create the program for you with your recording.

Reward points if helpful