Learn SAP Program: SAP

Aim: How to handle application server data.

Note 1: If defined structure element and its types all are in char (C), then we can use
ex:
OPEN DATASET l_fname FOR INPUT IN TEXT MODE ENCODING DEFAULT.

Upload data into txt file

REPORT  ZSAMPLE_AL11.
"D:\usr\sap\DEV\DVEBMGS00\data upload file location in SAP

TYPES : BEGIN OF ST_DEMO, "structure in data type C
        REG_NO TYPE C,
        NAME(20) TYPE C,
        ADDR(20) TYPE C,
        END OF ST_DEMO.

DATA : WA_DEMO TYPE ST_DEMO,
IT_DEMO TYPE TABLE OF ST_DEMO,
L_FNAME TYPE STRING .

PARAMETERS: P_FNAME(128) TYPE C DEFAULT '\usr\sap\DEV\SYS\src\ZSAMPLE.TXT' OBLIGATORY.

L_FNAME = P_FNAME.

WA_DEMO-REG_NO = '100003'.
WA_DEMO-NAME = 'ANAND'.
WA_DEMO-ADDR = 'NAGARKOVIL'.
APPEND WA_DEMO TO IT_DEMO.

WA_DEMO-REG_NO = '100005'.
WA_DEMO-NAME = 'VIKRAM'.
WA_DEMO-ADDR = 'CHENNAI'.
APPEND WA_DEMO TO IT_DEMO.

*CONCATENATE l_fname sy-datum sy-UZEIT INTO l_fname SEPARATED BY '_' . "optinal one if you want used it, or else leave it

OPEN DATASET L_FNAME FOR OUTPUT IN TEXT MODE ENCODING DEFAULT.
IF SY-SUBRC = 0.
LOOP AT IT_DEMO INTO WA_DEMO.
TRANSFER WA_DEMO TO L_FNAME.
ENDLOOP.
ENDIF.

_________________________________________________________________________________

Download data form txt file to internal table

REPORT  ZSAMPLE1_AL11.
"D:\usr\sap\DEV\DVEBMGS00\data downloaded file location in SAP

TYPES : BEGIN OF ST_DEMO, "structure in data type C
        REG_NO TYPE C,
        NAME(20) TYPE C,
        ADDR(20) TYPE C,
        END OF ST_DEMO.

DATA : WA_DEMO TYPE ST_DEMO,
IT_DEMO TYPE TABLE OF ST_DEMO,
L_FNAME TYPE STRING .

PARAMETERS: P_FNAME(128) TYPE C DEFAULT '\usr\sap\DEV\SYS\src\ZSAMPLE.TXT' OBLIGATORY.

L_FNAME = P_FNAME.

OPEN DATASET l_fname FOR INPUT IN TEXT MODE ENCODING DEFAULT.
if sy-subrc = 0.
DO.
READ DATASET l_fname INTO WA_DEMO.
IF sy-subrc = 0.
APPEND WA_DEMO TO IT_DEMO.
ELSE.
EXIT.
ENDIF.
ENDDO.
ENDIF.

_________________________________________________________________________________

Delete txt file from application server

REPORT  ZSAMPLE2_AL11.
"D:\usr\sap\DEV\DVEBMGS00\data deleted file location in SAP

DATA : L_FNAME TYPE STRING .

PARAMETERS: P_FNAME(128) TYPE C DEFAULT '\usr\sap\DEV\SYS\src\ZSAMPLE.TXT' OBLIGATORY.

L_FNAME = P_FNAME.

DELETE DATASET l_fname.

_________________________________________________________________________________

Note 2: The defined structure element in multiple types , then we can use
ex:

OPEN DATASET l_fname FOR INPUT IN BINARY MODE ENCODING DEFAULT.

Upload data into txt file

REPORT  ZSAMPLE_AL11.
"D:\usr\sap\DEV\DVEBMGS00\data upload file location in SAP

TYPES : BEGIN OF ST_DEMO, "structure in data type with 'C' and 'num'
        REG_NO TYPE num4,
        NAME(20) TYPE C,
        ADDR(20) TYPE C,
        END OF ST_DEMO.

DATA : WA_DEMO TYPE ST_DEMO,
IT_DEMO TYPE TABLE OF ST_DEMO,
L_FNAME TYPE STRING .

PARAMETERS: P_FNAME(128) TYPE C DEFAULT '\usr\sap\DEV\SYS\src\ZSAMPLE.TXT' OBLIGATORY.

L_FNAME = P_FNAME.

WA_DEMO-REG_NO = '100003'.
WA_DEMO-NAME = 'ANAND'.
WA_DEMO-ADDR = 'NAGARKOVIL'.
APPEND WA_DEMO TO IT_DEMO.

WA_DEMO-REG_NO = '100005'.
WA_DEMO-NAME = 'VIKRAM'.
WA_DEMO-ADDR = 'CHENNAI'.
APPEND WA_DEMO TO IT_DEMO.

*CONCATENATE l_fname sy-datum sy-UZEIT INTO l_fname SEPARATED BY '_' . "optinal one if you want used it, or else leave it

OPEN DATASET L_FNAME FOR OUTPUT IN BINARY MODE. "major change between is marked in RED color
IF SY-SUBRC = 0.
LOOP AT IT_DEMO INTO WA_DEMO.
TRANSFER WA_DEMO TO L_FNAME.
ENDLOOP.
ENDIF.

ABAP processing logic is responsible for processing data in R/3 application programs. ABAP was designed specifically for dialog-oriented database applications. The following sections deal with how an ABAP program is structured and executed.

Program Structure

ABAP programs are responsible for data processing within the individual dialog steps of an application program. This means that the program cannot be constructed as a single sequential unit, but must be divided into sections that can be assigned to the individual dialog steps. To meet this requirement, ABAP programs have a modular structure. Each module is called a processing block. A processing block consists of a set of ABAP statements. When you run a program, you effectively call a series of processing blocks. They cannot be nested.

The following diagram shows the structure of an ABAP program:

Each ABAP program consists of the following two parts:

Declaration Part for Global Data, Classes and Selection Screens

The first part of an ABAP program is the declaration part for global data, classes, and selection screens. This consists of:

All declaration statements for global data. Global data is visible in all internal processing blocks. You define it using declarative statements that appear before the first processing block, in dialog modules, or in event blocks. You cannot declare local data in dialog modules or event blocks.
All selection screen definitions.
All local class definitions (CLASS DEFINITION statement). Local classes are part of ABAP Objects, the object-oriented extension of ABAP.

Declaration statements which occur in procedures (methods, subroutines, function modules) form the declaration part for local data in those processing blocks. This data is only visible within the procedure in which it is declared.

Container for Processing Blocks

The second part of an ABAP program contains all of the processing blocks for the program. The following types of processing blocks are allowed:

Dialog modules (no local data area)
Event blocks (no local data area)
Procedures (methods, subroutines and function modules with their own local data area).

Whereas dialog modules and procedures are enclosed in the ABAP keywords which define them, event blocks are introduced with event keywords and concluded implicitly by the beginning of the next processing block.

All ABAP statements (except declarative statements in the declaration part of the program) are part of a processing block. Non-declarative ABAP statements, which occur between the declaration of global data and a processing block are automatically assigned to the START-OF-SELECTION processing block.

Calling Processing Blocks

You can call processing blocks either from outside the ABAP program or using ABAP commands which are themselves part of a processing block. Dialog modules and event blocks are called from outside the ABAP program. Procedures are called using ABAP statements in ABAP programs.

Calling event blocks is different from calling other processing blocks for the following reasons:

An event block call is triggered by an event. User actions on selection screens and lists, and the runtime environment trigger events that can be processed in ABAP programs. You only have to define event blocks for the events to which you want the program to react (whereas a subroutine call, for example, must have a corresponding subroutine). This ensures that while an ABAP program may react to a particular event, it is not forced to do so.

Program Types and Execution

When you run an ABAP program, you call its processing blocks. ABAP programs are controlled from outside the program itself by the processors in the current work process. For the purposes of program flow, we can summarize the screen processor and ABAP processor into the ABAP runtime environment. The runtime environment controls screens and ABAP processing blocks. It contains a range of special control patterns that call screens and processing blocks in certain orders. These sections are also called processors. When you run an ABAP program, the control passes between various processors.

In the R/3 System, there are various types of ABAP program. The program type determines the basic technical attributes of the program, and you must set it when you create it. The main difference between the different program types is the way in which the runtime environment calls its processing blocks.

When you run an application program, you must call at least the first processing block from outside the program, that is, from the runtime environment. This processing block can then either call further processing blocks or return control to the runtime environment. When you start an ABAP program, the runtime environment starts a processor (dependent on the program type), which calls the first ABAP processing block. An ABAP program can be started either by the user or by the system (for example, in background processing), or through an external interface (for example, Remote Function Call).

There are two ways of allowing users to execute programs - either by entering the program name or by entering a transaction code. You can assign a transaction code to any program. Users can then start that program by entering the code in the command field. Transaction codes are also usually linked to a menu path within the R/3 System.

The following program types are relevant to application programming:

Type 1

Type 1 programs have the important characteristic that they do not have to be controlled using user-defined screens. Instead, they are controlled by the runtime environment, which calls a series of processing blocks (and selection screens and lists where necessary) in a fixed sequence. User actions on screens can then trigger further processing blocks.

You can start a type 1 program and the corresponding processor in the runtime environment using the SUBMIT statement in another ABAP program. There are also various ways of starting a type1 program by entering its program name. This is why we refer to type 1 programs as executable programs.

When you run a type 1 program, a series of processors run in a particular order in the runtime environment. The process flow allows the user to enter selection parameters on a selection screen. The data is them selected from the database and processed. Finally, an output list is displayed. At no stage does the programmer have to define his or her own screens. The runtime environment also allows you to work with a logical database. A logical database is a special ABAP program which combines the contents of certain database tables. The flow of a type 1 program is oriented towards reporting, whose main tasks are to read data from the database, process it, and display the results. This is why executable programs (type 1) in the R/3 System are often referred to as reports, and why running an executable program is often called reporting.

Since it is not compulsory to define event blocks, you can yourself determine the events to which your ABAP program should react. Furthermore, you can call your own screens or processing blocks at any time, leaving the prescribed program flow. You can use this, for example, to present data in a table on a dialog screen instead of in a list. The simplest executable program (report) contains only one processing block (START-OF-SELECTION).

Executable programs do not require any user dialog. You can fill the selection screen using a variant and output data directly to the spool system instead of to a list. This makes executable programs (reports) the means of background processing in the R/3 System.

You can also assign a transaction code to an executable program. Users can then start it using the transaction code and not the program name. The reporting-oriented runtime environment is also called when you run a report using a transaction code. This kind of transaction is called a report transaction.

It is appropriate to use executable programs (reports) when the flow of your program corresponds either wholly or in part to the pre-defined flow of the runtime environment. Until Release 4.5A, the only way to use a logical database was to use an executable program. However, from Release 4.5A, it is also possible to call logical databases on their own.

Type M

The most important technical attribute of a type M program is that it can only be controlled using screen flow logic. You must start them using a transaction code, whcih is linked to the program and one of its screens (initial screen). Another feature of these programs is that you must define your own screens in the Screen Painter (although the intial screen can be a selection screen).

When you start a program using a transaction code, the runtime environment starts a processor that calls the initial screen. This then calls a dialog module in the corresponding ABAP program. The remainder of the program flow can take any form. For example, the dialog module can:

return control to the screen, after which, the processing passes to a subsequent screen. Each screen has a following screen, set either statically or dynamically.
call other sequences of screens, selection screens or lists, from which further processing blocks in the ABAP program are started.
call other processing blocks itself, either internally or externally.
call other application programs using CALL TRANSACTION (type M program) or SUBMIT (type 1 program).

ABAP programs with type M contain the dialog modules belonging to the various screens. They are therefore known as module pools. It is appropriate to use module pools when you write dialog-oriented programs using a large number of screens whose flow logic largely determines the program flow.

Type F

Type F programs are containers for function modules, and cannot be started using a transaction code or by entering their name directly. Function modules are special procedures that you can call from other ABAP programs.

Type F programs are known as function groups. Function modules may only be programmed in function groups. The Function Builder is a tool in the ABAP Workbench that you can use to create function groups and function modules. Apart from function modules, function groups can contain global data declarations and subroutines. These are visible to all function modules in the group. They can also contain event blocks for screens in function modules.

Type K

You cannot start type K programs using a transaction code or by entering the program name. They are containers for global classes in ABAP Objects . Type K programs are known as class definitions. The Class Builderis a tool in the ABAP Workbench that you can use to create class definitions.

Type J

You cannot start type J programs using a transaction code or by entering the program name. They are containers for global interface in ABAP Objects . Type J programs are known as interface definitions. Like class definitions, you create interface definitions in the Class Builder.

Type S

You cannot start a type S program using a transaction code or by entering the program name. Instead, they are containers for subroutines, which you can call externally from other ABAP programs. Type S programs are known as subroutine pools. They cannot contain screens.

Type I

Type I programs - called includes - are a means of dividing up program code into smaller, more manageable units. You can insert the coding of an include program at any point in another ABAP program using the INCLUDE statement. There is no technical relationship between include programs and processing blocks. Includes are more suitable for logical programming units, such as data declarations, or sets of similar processing blocks. The ABAP Workbench has a mechanism for automatically dividing up module pools and function groups into include programs.

Learn SAP Program

Modify SAP InfoSet Query Report

SAP Standard table relationship

Application server data handling (download, upload, delete)

SAP Keyboard Shortcuts

Structure of ABAP Programs