topic Re: Data Migration examples in Application Development and Automation Discussions

1.Ensure that whether u r going to do one time transfer or frequent data transfer.One time transfer includes transferring master data and frequent data transfer includes transactional data.

2.Analyse the legacy data and identify the source from where it is coming from.

3.Record the corresponding SAP Transaction to know about the details like screen sequence,screen program name,screen field name,mandatory fields etc.

4.Generate the program based on the recording.

5.Read the data from your legacy system.Depends on whether the data is in presentation/application server you could use either GUI_UPLOAD/OPEN DATASET variants.

5.Convert the data into SAP format.

6.Replace the values from your recording with the value converted in SAP Format.

7.Finally you could do the transfer using either Session/Call transaction techniques.

8.You could also use LSMW for master data transfer as it is not suited for frequent data transfers.

Example using BAPI:

Below is an example of SO change using BAPI

initialize

clear: zBAPISDH1,

zBAPISDH1x.

refresh: zBAPIRET2,

zBAPISDITM,

zBAPISDITMx.

set header parameters for sales order update

move '911' to zBAPISDH1-ORD_REASON.

move 'X' to zBAPISDH1x-ORD_REASON.

move 'U' to zBAPISDH1x-UPDATEFLAG.

set item parameters for sales order update

select posnr

into vbap-posnr

from vbap

where vbeln eq itab_ord-vbeln.

clear: zBAPISDITM,

zBAPISDITMx.

move vbap-posnr to zBAPISDITM-ITM_NUMBER.

move '96' to zBAPISDITM-REASON_REJ.

append zBAPISDITM.

move vbap-posnr to zBAPISDITMx-ITM_NUMBER.

move 'X' to zBAPISDITMx-REASON_REJ.

move 'U' to zBAPISDITMx-UPDATEFLAG.

append zBAPISDITMx.

endselect.

update sales order

CALL FUNCTION 'BAPI_SALESORDER_CHANGE'

EXPORTING

SALESDOCUMENT = itab_ord-vbeln

ORDER_HEADER_IN = zBAPISDH1

ORDER_HEADER_INX = zBAPISDH1X

SIMULATION = p_test

TABLES

RETURN = zBAPIRET2

ORDER_ITEM_IN = zBAPISDITM

ORDER_ITEM_INX = zBAPISDITMX.

commit changes

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.

Reward points if found helpful…

Cheers,

Chandra Sekhar.

Re: Data Migration examples

Former Member — Sat, 15 Dec 2007 11:07:47 GMT

Hi Gow.

Difference Between Batch Input and Call Transaction in BDC

What is the difference between batch input and call transaction in BDC?

Session method.

1) synchronous processing.

2) can tranfer large amount of data.

3) processing is slower.

4) error log is created

5) data is not updated until session is processed.

Call transaction.

1) asynchronous processing

2) can transfer small amount of data

3) processing is faster.

4) errors need to be handled explicitly

5) data is updated automatically

Batch Data Communication (BDC) is the oldest batch interfacing technique that SAP provided since the early versions of R/3. BDC is not a typical integration tool, in the sense that, it can be only be used for uploading data into R/3 and so it is

not bi-directional.

BDC works on the principle of simulating user input for transactional screen, via an ABAP program.

Typically the input comes in the form of a flat file. The ABAP program reads this file and formats the input data screen by screen into an internal table (BDCDATA). The transaction is then started using this internal table as the input and executed in the background.

In ‘Call Transaction’, the transactions are triggered at the time of processing itself and so the ABAP program must do the error handling. It can also be used for real-time interfaces and custom error handling & logging features. Whereas in

Batch Input Sessions, the ABAP program creates a session with all the transactional data, and this session can be viewed, scheduled and processed (using Transaction SM35) at a later time. The latter technique has a built-in error processing mechanism too.

Batch Input (BI) programs still use the classical BDC approach but doesn’t require an ABAP program to be written to format the BDCDATA. The user has to format the data using predefined structures and store it in a flat file. The BI program then reads this and invokes the transaction mentioned in the header record of the file.

Direct Input (DI) programs work exactly similar to BI programs. But the only difference is, instead of processing screens they validate fields and directly load the data into tables using standard function modules. For this reason, DI programs are much faster (RMDATIND - Material Master DI program works at least 5 times faster) than the BDC counterpart and so ideally suited for loading large volume data. DI programs are not available for all application areas.

Differences between bdc session method and call transaction method.

The most important aspects of the batch session interface are: - Asynchronous processing - Transfers data for multiple transactions - Synchronous database update During processing, no transaction is started until the previous transaction has been written to the database. - A batch input processing log is generated for each session - Sessions cannot be generated in parallel

The most important aspects of the CALL TRANSACTION USING interface are: - Synchronous processing - Transfers data for a single transaction - Synchronous and asynchronous database updating both possible The program specifies which kind of updating is desired. - Separate LUW for the transaction The system performs a database commit immediately before and after the CALL TRANSACTION USING statement. - No batch input processing log is generated.

Explain in detail with example what is batch input session?

Batch Input Session:

- It is a sequence of transactions, which is generated when user run a particular program.

- It contains the accounting documents that are to be created. The SAP system stores these transactions until you decide to process them online.

- It does not update transaction figures until the session has been processed. Using this technique, you can transfer large amounts of data to the SAP system in a short time.

Three processing modes of executing Batch Input Session :-

(1) Run Visibly : You can correct faulty transactions online & work step-by-step through the transactions not yet executed.

(2) Display Errors only : You can correct faulty transactions online. Transactions not yet executed, but without error, run in the background.

(3) Run in Background : Recommended by SAP.

Kindly Reward Points If You Found The Reply Usefull,

Cheers,

Chaitanya.