http://help.sap.com/abapdocu_70/en/ABAPLOAD-OF-PROGRAM.htm http://help.sap.com/abapdocu_70/en/ABENABAP_SUBMIT_REPORT.

htm

LOAD-OF-PROGRAM

Short Reference Syntax LOAD-OF-PROGRAM. Effect This event keyword defines an event block whose event is triggered by the ABAP-runtime environment when an executable program, a module pool, a function group or a sub-routine pool is loaded in theinternal session. When a program is called using SUBMIT or using a transaction code, then - at every call - a new internal session is opened and the event block is executed once at every call. You can initialize global data objects of the program here. The event block must be executed completely; otherwise, a runtime error will occur.Therefore, no statements are allowed to be executed that leave the event block without returning. At the first call of an external Procedure (sub-program or function module), the framework program of the called procedure is loaded into the internal session of the caller, thus triggering the event LOAD-OF-PROGRAM. The event block is executed before the called procedure. At any further call of a procedure of the same framework program by a caller of the same internal session, the event LOAD-OF-PROGRAM is triggered no longer. Note The event LOAD-Of-PROGRAM should mainly be used to initialize global data when calling external procedures or Transactions. If you call executable programs with SUBMIT, we recommend that you use the eventINITIALIZATION, as the Starting values for parameter and selection criteria are set after LOAD-OFPROGRAM (see program flow after SUBMIT).

Flow of an Executable Program The SUBMIT statement loads the called program in a separate internal session and starts a series of processes in the ABAP runtime environment that trigger events and actions in the called program in the following order: 1. Program constructor event LOAD-OF-PROGRAM

2.

The start values defined using the DEFAULT addition in the statements PARAMETERS and SELECTOPTIONS are passed to the relevant data objects. The start values of all other data objects are set before LOAD-OF-PROGRAM. Reporting event INITIALIZATION The selection screen specified in selscreen_options is called if it contains at least one input field or button. Complete selection screen processing is performed. Before the first event of the selection screen processing, AT SELECTION-SCREEN OUTPUT, the values specified in selscreen_options are passed. Reporting event START-OF-SELECTION Different GET events, if the called program is linked with a logical database. Reporting event END-OF-SELECTION The basic list is called. If the basic list is empty, the program is exited.. If the basic list is a print list, it is sent to the SAP spool system and the program is exited. If EXPORTING LIST TO MEMORY is specified in list_options, the basic list is stored in the ABAP Memory and the program is exited. Otherwise, the basic list is a screen list and is displayed on the screen. User actions on a displayed screen list trigger list events. The program is exited when the user exits the list display. If no selection screen is displayed in step 4, because processing is performed in the background or not at all, the program flow is complete. If a selection screen id displayed in step 4, the runtime environment calls the called program again after the basic list has been exited. During this new call, the runtime environment supplies the parameters, the selection criteria, and the free selections of the selection screen between the events INITIALIZATION and AT SELECTION-SCREEN OUTPUT with the previous input values. The program call is not complete until the user exits the selection screen processing by choosing Back, Exit, or Cancel.

3. 4.

5. 6. 7. 8.

9.

The called program can be exited in any of these steps by using the LEAVE PROGRAM statement and during list processing by using LEAVE LIST-PROCESSING. Notes When the SUBMIT statement is executed, it is implicitly followed by an authorization check for the authorization group specified in the program attributes. If the called program is linked with a logical database, the system calls the relevant subroutines of the database program for the steps listed above.

Difference between CALL TRANSACTION and SESSION Method

by Vikram Chellappa Call Transaction method Classical or session method

In this method, the ABAP/4 program uses the call transaction <T-code > using <bdc_tab> mode <mode> update <update > method.

In this method, ABAP/4 program read the external data that is to be entered to the SAP system and stores the data in the batch input session. When the prgm has finished creating the session, we can run the session thro the TC SM35. This method involves FM like BDC_OPEN,BDC_INSERT,BDC_CLOSE

In Call Transaction, the transactions are triggered at the time of processing itself and so the ABAP program must do the error handling.

Synchronous Processing

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. Asynchronous Processing

We can update the database both synchronously and asynchronously. We can specify the mode in the program.

Synchronous Database update. During processing, no transaction is started until the previous transaction has been written to the database. Detailed Log will be generated for all the sessions While executing it wont start from the first. It will start from the place where it ends with error.

No batch input processing log

While execution it starts from the first.

Faster than session method

Not as fast as call transaction method

What the difference between BDC and BAPI? What the exact situation where we can use BDC and BAPI?
BDC is the good old method of moving legacy data to SAP.

BAPI is the new enhanced Application Interface through which data can be uploaded into SAP System.

BDC is transaction oriented. Meaning, the data is uploaded into SAP through standard transactions. All checks, validations,exits that are applicable to the transaction are active while loading data into SAP.

Simply saying, BDC is continuous running of transaction repeatedly without human intervention, data being picked from text file for each run. It is just a bundling of multiple executions of the same transaction and execute at once like a macro.

Whereas BAPI is an interfacing method, through which SAP data can be processed from within SAP or from other non-SAP applications. BAPI can be termed as SAP transaction without dialog. All the screens of particular transaction is converted in the form of a Code Module. We can establish on-line interface with SAP data from non-SAP applications through BAPI's if they are enabled for Remote Access.

Generally BDC is preferred if the data from the legacy system is moved to SAP single time. For example, at the time of Go-Live the data required for SAP is either downloaded from other software or manually prepared in excel sheets and uploaded into SAP at once. After that data or SAP has nothing to do with other software. BAPI's are preferred, if data exchange is online or continuous between SAP transactions or SAP and non-SAP applications. BAPI's are preferred in view of performance also. Data loading through BAPI's are more robust and faster comparatively, if they are called correctly.