1. ABAP keywords/Statements.

2. System Fields.
3. String Functions.
4. Selection Screen elements.
5. Events in Selection Screen.
6. Field Symbols
7. Exception Handling.
ABAP statements / keywords:
1. Data: used for declaring variables.

Syntax:

data [:] <variable name> <type/like> <data type> [value <initial value>] [decimals <no.of decimals>]....

[ ] --> optional (may / may not be used)

< > --> mandatory / obligatory

Eg: data x type i.

data x type i value 10.
data abc type c.

We use : (colon : or chain operator) as part of ABAP statements whenever we perform multiple operations using
single keyword.
ABAP statements / keywords:
2. Parameters: generates selection screen for reading user input.

Syntax:

parameters [:] <variable name> <type/like> <data type> [default <default value>] [obligatory]
Parameter variable names should not exceed 8 characters and should not contain special characters.

Default is the option/addition used as part of parameters statement to provide default values for selection screen
fields.

Obligatory is the option used as part of parameters statement to make a selection screen field as mandatory.

By default, numeric data types (integer(i), packed(p), float(f)) are right-justified and
character data types (character( c ), date (d), time (t) are left-justified).

Note: By default, selection-screen number is always 1000.

ABAP statements / keywords:
3. Write: generates List processing screen (output screen) for displaying the result

Syntax:
write [:] <variable> ...........

4. Constants: used for declaring fixed value variables. It must be initialized at the time of declaration itself.
Syntax: constant [:] <variable> type <datatype> value <fixed value>.

Integers cannot store decimal values, if any decimal value is stored in integer variable; it will round off to nearest
integer. To store the decimal values, we can use packed data type and use the addition decimal to specify the no.
of decimal positions.
ABAP statements / keywords:
Numeric Values:

• By default, Integers cannot store decimal values. If any Decimal value is assigned to integer variable in single
quotes, then the value will be rounded off to the nearest integer and stored in the integer variable.
• To store decimal values, we can use P (Packed) data type and while declaring packed variables, we need to
use decimal addition to specify number of decimal places.

Character Fields:

• A variable declared as C (character) can store only single character by default, to store more number of
characters declare the variable as array of characters or as a string data type.
• Data abc(20) type c.
• Data abc type string.
ABAP System Fields:
These are provided by SAP itself and they start with SY-….. The Values for these System fields
are assigned by SAP itself.

SY-DATUM  Current application server date

SY-UZEIT  Current Application server time
SY-REPID  Current Program name
SY-UNAME  Login user name
SY-DYNNR  Current screen no.
SY-SUBRC  This field stores the return code of the last executed ABAP statement.
SY-MANDT  This field stores the client number of the current client.
SY-DBCNT  This field stores the number of records that were processed by the last database operation.
String Functions:
1. Strlen  Returns Length of string
2. Translate  Converts a given string to upper case/lower case
3. Concatenate  Combines multiple strings into single string
4. Split  Splits the given string into multiple substrings based on the delimiter
5. Condense  Removes the blank spaces of a string
6. Replace  Replaces the source pattern of a string with the given target pattern
7. Overlay  Replaces the blank spaces of the source string with the corresponding positioned character in the
target string
8. Shift  shifts the contents of the string to the specified direction and no.of places
9. Unpack  It prefixes the character field containing numeric values with the appropriate no. of zero’s depending
on the field width.
10. Pack  It removes the leading zero’s from the character field containing numeric values
Selection Screen Elements:
Selection-screen is used for reading the user input. As part of selection-screen we can design
following selection screen elements.

• Labels(comment)
• Input fields – using parameters keyword
• Push buttons
• Checkboxes
• Radio buttons
• Blocks
• Tabbed blocks
• List box(drop down)
Selection Screen Elements:
Syntax for labels(comment):

Selection-screen comment <start position>(<width>) <label variable>.

Syntax for pushbuttons:

Selection-screen pushbutton <start position> <width> <button variable> user-command <function code>.
Selection Screen Elements:
Syntax for selection-screen Blocks:

Selection-screen begin of block <block name> [with frame title <title variable>.
Selection-screen elements.
Selection-screen end of block<block name>.

Syntax for Selection screen Checkboxes:

Parameters <Checkbox name> as checkbox [user-command <function code>].

Note: In case of checkboxes on selection-screen, we can select any no. of checkboxes.

A checkbox can contain either X(or) SPACE ‘ ‘ as values. X means checkbox selected & space means Unselected.

By Default, None of the checkboxes will be selected.

Selection Screen Elements:
Syntax for Selection Screen Radio buttons:

Parameters <radio button name> radio button group <group name> [user-command <function_code>].

Eg: Parameters p_r1 radio button group grp1.

Note: In a group of radio buttons, only one radio button can be selected.

A radio button can contain either X(or) SPACE ‘ ‘ as values.

X means Radio Button selected & space means Unselected.

By Default, First radio button in the group will be selected.

Events in Selection Screen :
As part of ABAP programming language, there are many events provided by SAP which are triggered at
different places. These events can be handled to provide dynamic features to the applications;
these events are raised by SAP itself.
As part of selection-screen also, the following are the events:-

1. Initialization.
2. At selection-screen output.
3. At selection-screen on <field>.
4. At selection-screen.
5. AT SELECTION-SCREEN ON EXIT
6. At selection-screen on value-request.
7. At selection-screen on help-request.
8. At selection-screen on radio button group
Events in Selection Screen :
Initialization:

This is the first event triggered/raised whenever a selection-screen is displayed. This event is triggered only once in
the life time of a selection-screen.

This event can be handled to initialize the selection-screen fields.

At selection-screen output:

This event is triggered in the following two cases:

Case 1: Whenever the selection screen is displayed for the first time (triggers after the initialization event)

Case 2: It is also triggered after the at selection-screen event.

This event can be handled to refresh the selection-screen elements dynamically. i.e screen refreshing logic should
be implemented as part of this event.
Events in Selection Screen :
At selection-screen on radio button group:

This event is triggered whenever the user selects a radio button in the radio button group of a selection screen. In
this case, the function code of the radio button group is captured in the system field SY-UCOMM and the radio
button value is set to X.

At selection-screen:

This event is triggered whenever the user selects/deselects a checkbox of a selection screen. In this case, the
function code of the selected / deselected checkbox is captured in the system field SY-UCOMM and the value of
the checkbox is set to X (if selected) otherwise space (if deselected).

This event is also triggered when the user performs the following actions on the selection screen field.

a. Clicking a pushbutton.
b. Pressing enter key in the input field.
c. Selecting a value in the drop down.
d. On selection / deselection of a checkbox
Events in Selection Screen :
At selection-screen on field:

• This event is triggered whenever the user press enter key in the input field.
• This event can be handled to validate the field.

AT SELECTION-SCREEN ON EXIT:

• This event is triggered when the user exits the selection screen.
• It is used to perform final validations on the input parameters before they are used in the program.
Events in Selection Screen :
AT SELECTION-SCREEN ON VALUE-REQUEST:

• This event is triggered when the user clicks on the value help button next to a field on the selection screen. Or
This event is triggered when the user presses F4 Key in a selection screen input field.
• It is used to display a dialog box or a list of values for the user to select from. we can call the function module
F4IF_INT_TABLE_VALUE_REQUEST to populate custom F4 values.

AT SELECTION-SCREEN ON HELP-REQUEST:

• This event is triggered when the user clicks on the help button next to a field on the selection screen. Or This
event is triggered when the user press F1 key on a selection screen field.
• It is used to display help text or documentation related to the field.
Field Symbol :
Field-symbols are a special data structure used for holding any kind of data.

i.e it is capable of storing any kind of data.

Field-symbol variable must be enclosed between < and >.

We use the keyword ASSIGN to assign a variable value to the field-symbol.

Once a variable is assigned to the field-symbol, there will be a pointer link between the variable and field-symbol,
so any changes made to the data of the variable will automatically reflect the value of field-symbol and vice versa.
Exception Handling :
1. An exception is a runtime error which is raised during the program execution.
2. If the exception is not handled, the program execution will be terminated.
3. Exception handling is a process of handling the Runtime Errors and continue the program execution without
termination.
4. The exceptions which are raised by SAP are called as Standard Exceptions.
5. These standard exceptions are raised from standard exception classes which start with Naming convention
CX___.
6. We can handle these exceptions by using TRY and CATCH blocks.
7. Inside the TRY Block we need to keep those statements where the possible exceptions might occur.
8. The CATCH block is placed immediately after the Try Block; it is responsible for handling the exceptions by
providing appropriate exception handling statements which can be system defined exception message / user-
defined exception message.
9. CX_ROOT is common for any exceptions i.e it is super class(parent class) for all exception classes.
10. As part of the catch block we need to provide the exception class name which is responsible for raising the
exception.
11. If we are not sure about the exception class, we can give the exception class name as CX_ROOT.
12. CX_ROOT is super class for all the exception classes.
Interview / Assessment Booster

1. Structure
2. Internal Table
Structure :
• It is user defined data type which is a collection of different types of fields.
• In structures the memory allocation is continuous. All the fields are stored one after the other.
• The size of the structure is equal to sum of the sizes occupied by structure fields.
• We can access the structure fields by using structure name.
• We use structures whenever we need to capture interrelated information in the form of a record.
• By default, structure fields are initialized to respective default values based on the data types.
• At any point of time a structure can store only single record.

SYNTAX:

DATA: BEGIN OF <STRUCTURE NAME>,

FIELD 1,
FIELD 2,
------------,
FIELD N,
END OF <STRUCTURE NAME>.
Copy Data Across Structures :
We can copy the data of one structure to another structure by using assignment operator (=), move and move-
corresponding statements.
In case of assignment (=) and move statement, it only checks for corresponding data types of the fields and not for
names and the no of fields. If any one of the corresponding field data type is not matching it leads to syntax error.

Next is Move-Corresponding –

It is used to copy the data between dis-similar structures.

It is recommended not to use the move-corresponding statement because of the following 2 reasons.

1. It decreases the performance, because each field of the source structure is compared with all the fields of the
target structure which is time consuming and thereby decreases the performance.

2. It may lead to run-time error i.e. While copying the data between two fields it only checks for matching field’s
names but not for data types. If data types are not type compatible it leads to run-time error.
Nested Structures :
Declaring a structure inside another structure.

Syntax:
Data : begin of <structure name1>, outer structure
Field1,
Field2,--------,
Begin of <structurename2>, inner structure
Field3,
Field4,
--- ---
End of <structurename2>, Including Structures inside other structure
End of <structurename1>.
Note: We can include one structure inside another structure
Accessing outer structure fields by using include structure (or) include type statement. The
<outer structure> - <field name> included structure can be local structure (available in same
Accessing inner structure fields object) or a global structure defined in the database.
<outer structure> - <inner structure> - <field name>
Standard way of declaring structure:
Syntax:
Types: begin of <type name>,
Field 1,
Field 2,
--- --- --
Field n,
End of <type name>.

Note: Types declaration doesn't allocate any memory; it only provides the template of the fields (field names and
their data types). Types keyword is used for creating user-defined data type.

Based on Types declaration, we can create n no. of instances (structures/work areas/ Internal Tables)

Syntax:
Data <structure name> type <type name>.
Data <ITAB> type table of <typesname>.
Data <wa> type <typename>
Internal Table:
• It is a temporary table created in application server.

• The lifetime and scope of the internal table is within the program execution where it is created. i.e Once the
Program execution is completed, the memory allocated for the internal table will be destroyed.

• Internal table can be created either with header or without header.

• A header of an internal table is like a work area (structure) which can be used to process the internal table.

• Work area can store only single record.

• The body of the internal table can store multiple records.

• We generally use internal tables to store the data retrieved from database tables, process the data and then
displaying the formatted(processed) data / update it back to database.
Internal Table:
Data : begin of <internal table> occurs <n>,
Field1,
Field2,
- - - --,
Field k,
End of <internal table>.

<n>-> ranges from 0,1,2,- -- --- ---

0 -> 8kb,
1 ->16kb,
2-> 24kb,----…multiples of 8

Note: In the above syntax, the occurs <n> will specify the initial amount of memory that needs to be allocated for
the internal table. If the initial memory is utilized, the memory automatically gets increased to the amount of initial
size.
ABAP Statement used with Internal Table:
Append :
• This statement copies the data from work area to the end of the internal table.

Loop:
• This statement is used for processing the internal table. Its copies each record from body to header. The number
of times the loop execution depends upon the loop condition and internal table data.

SORT:
• Before processing the internal table based on a condition, it is always recommended to sort the internal table
based on the field on which the condition is specified.
• If the sort field is not specified, by default it will be sorted on first character field of the internal table. If no
character fields are available in the internal table, then sorting will be done on first field of the internal table.
• If the sorting order is not specified, by default sort is in ascending order.
• The index of the internal table starts from 1.
• Sy-tabix is the system field which holds the index position of the internal table.
• Sy-index is the system field which stores the iteration value for the looping statements like while end-while and
do enddo.
ABAP Statement used with Internal Table:
Describe :
• This statement counts the no of records of the internal table and stores the count value in the system field
sy-tfill.
• If we use the lines addition as part of describe statement, the count value is stored inside the program variable
specified as part of lines addition.
• Syntax: Describe table <internal table> [ lines <variable> ].

Refresh:
• It will delete all the records; it is always used only on internal table.

Clear:
• It will delete all records, use [ ] (for internal tables with header). Clear can be used on normal variables or work
areas also.

Free:
• It will delete all the records;
• it is always used only on internal table.
• The difference between refresh and free is refresh clears the data but doesn’t de-allocate the memory , whereas
free statement clears the internal table and gets the internal table to initial state.
ABAP Statement used with Internal Table:
Delete:
• Deletes the records of the internal table based on a condition

Delete adjacent duplicates:

• Deletes adjacent duplicate records from internal table based on the comparing field.
• The pre-requisite for using this is the data in the internal table should be sorted based on the comparing field
(field specified in delete adjacent duplicates statement).
ABAP Statement used with Internal Table:
Read statement:

• It is used for reading specific record from the internal table and it always reads single record.
• If the read is successful the system field Sy-subrc is set to 0. Other wise 4.
• Read statement can be used either based on the index or based on a condition.
• Note: If the read is successful, the content of the record read is copied to work area specified in read statement.
• Before/while using Read statement, it is recommended to perform the following to improve the performance:
A) Sort the internal table based on search field.
B) Use the transporting addition as part of read statement to transport only specific fields from body to
work area; otherwise all fields are transported from body to work area.
C) Use the addition binary search in the read statement to minimize the search, before that, sort the
internal table based on search field; otherwise using binary search doesn’t have any effect.
• Use the addition transporting no fields as part of read statement when we need to check only the existence of
the record but not interested in the content of the record. In this, it is better not to specify any work area as part
of read statement as we are not transporting any data from body to work area, otherwise it leads to warning.
• It is always recommended to CLEAR the variable values before using them, otherwise if the variable is used as
it is, it refers to previous value (last value stored in the variable) which leads to data inconsistency. Here a
variable can be an individual variable or work area.
ABAP Statement used with Internal Table:
Modify statement:

• This statement is used for updating the internal table as well as database table. In case of modifying the internal
tables we need to modify referring to work area.

• As part of using MODIFY statement it is always recommended to use transporting option so that only the fields
specified in the transporting addition/option will be compared between work area and corresponding record in
the internal table body. If the transporting option is not specified, all the fields will be compared between work
area and body which decreases performance.

• Using the modify statement inside a loop will decrease the performance.

• To overcome this, it is recommended to use the following:

A) Field symbol work area instead of normal work area so that any changes made to the data of the field-
symbol work area will automatically update the corresponding row in the internal table (field-symbol work
area will act as pointer). i.e explicitly we need not use the modify statement.
B) Use modify statement outside loop using where clause referring to work area.
TYPES OF INTERNAL TABLE :
Standard Internal tables:

1. Key specification is optional.

2. Supports only non-unique key specification.

3. Sort without the sorting field will sort the data on key specification field (if declared) otherwise it sorts on first
character field of the internal table (if available) otherwise first field of the internal table.

4. Append and Insert statements are supported, Append statement always adds data to the end of the internal
table and insert can be used to add the data either at the end or in a specific index position of a internal table.

5. Supports indexed search, linear search (default), binary search.

TYPES OF INTERNAL TABLE :
Sorted internal tables:

1. Key Specification is Mandatory.

2. Supports both non-unique and unique key specifications.

3. Append and Insert statements are supported, but in case of Append, we need to ensure the sorting sequence
based on key specification field and also provide unique values for the unique key field, otherwise it leads to
runtime error. Because of this reason, it is recommended to use insert statement on sorted internal tables.

4. If the sorted internal table is declared using unique key specification and if we try to insert any duplicate entries
for the unique key field using insert statement, it ignores the duplicate entry and considers only the first entry which
is inserted.

5. Sort statement is not supported

6. Supports indexed, linear and binary search for searching a record using read statement
TYPES OF INTERNAL TABLE :
Hashed internal table:

1. Key specification is mandatory.

2. Supports only unique key specification.
3. Doesn’t support explicit or implicit index operations.
4. Implicit  Append statement not supported.
5. Implicit  Read with Binary search not supported.
6. Explicit  insert with index not supported.
7. Explicit  Read with index not supported.
8. Small tables  Standard internal tables.
9. Huge tables  Hashed internal table.
10. In case of standard internal tables, time consumed for searching a record depends on the no. of records/size of
internal table.
11. In case of hashed internal tables, irrespective of no. of records/size of internal table, time consumed for
searching a record is constant.
TYPES OF INTERNAL TABLE :
Standard Internal Table Sorted Internal Table Hashed Internal Table

1. Key specification is option. 1. Key specification is mandatory. 1. Key specification is mandatory.

2. It supports only non-unique key 2. It supports both Unique & non- 2. It supports only unique key
specification. unique key specification. specification.

3. Explicit Sorting is supported. 3. Explicit Sorting is not supported. 3. Explicit Sorting is supported.

4. It supports Indexed, Linear & 4. It supports Indexed, Linear & 4. It supports only Linear Search.
Binary Search. Binary Search.

5. Append & Insert statements are 5. Insert is supported, Append is 5. Only Insert statement without
supported. supported only when sorting index position is supported.
sequence is ensured otherwise
leads to run-time error.
Interview / Assessment Booster

Debugging
Debugging :
• It is the process of checking the flow of program execution step by step.

• To take the program to Debugging mode we need to set Break points in the program.

• A breakpoint is a signal to the system which stops the program execution whenever it is encountered.

• We can set the breakpoints in two ways:

1. Manually by clicking set breakpoint option on application toolbar.

2. By using keyword Breakpoint.
Note  We can set the break-points only in active mode of a program.

• It is recommended not to set the break-points by using “break-point” keyword. Because there is a possibility that
developer might forgot to remove the break-point keyword before transporting the object to next configured
client. If it is transported as it is, the program execution will be halted and the control will be taken to debugging
mode which is an escalation in quality/production system.
Debugging :
Navigations in debugging mode:

F5 (Single step): It executes single step at a time.

F6 (Execute): It is similar to F5 but when F6 is pressed at the time of calling the blocks (subroutine, function
module, method); the entire block will be executed as a single step without the control going to block definition.

F7 (Return): When F7 is pressed inside a block definition the control comes out of the current block by executing
the remaining steps of the block as a single step.

F8 (run to): Whenever F8 is pressed, the control jumps to the next breakpoint if available, otherwise it executes
the remaining steps of the program as a single step.

Note: We cannot debug the variable declarations; we can debug only the executable statements.
Interview / Assessment Booster

MODULARIZATION TECHNIQUES :
1. Sub-Routine
2. Include Programs
3. Function Module
MODULARIZATION TECHNIQUES :
Modularization is the process of breaking the program into multiple blocks.
A block is a set/collection of statements which is defined only once and can be called / accessed any no. of times.

Advantages of Modularization:
• Increases reusability.
• Efficient control on the flow of program execution.
• Maintenance cost is decreased.

Following are the Modularization techniques:

• Subroutines
• Include programs
• Function modules
MODULARIZATION TECHNIQUES :
Subroutines:

It is a block of statements, which is defined only once and can be called any number of times.
Subroutine can be created either with parameters or without parameters.
A subroutine is associated with 2 sections.
• Defining the subroutine
• Calling the subroutine

Subroutine must be defined at the end of the program. Whenever a subroutine is called the control jumps to
subroutine definition.

There are two types of subroutines.

• Internal subroutine.
• External subroutine.
MODULARIZATION TECHNIQUES :
Internal subroutine:

It is defined as well as called from the same program.

Syntax for defining internal/external subroutine:

Form <subroutine> [ parameters list]

statements.
Endform.

Syntax for calling internal subroutine:

perform <subroutine> [parameters list]

MODULARIZATION TECHNIQUES :
External subroutine:
They are defined in external programs and called from other programs.
The external program can be another executable program or a subroutine pool.

Subroutine pool:
It is a repository object which is a collection of one or more external subroutines.

Syntax for calling external subroutines:

Syntax 1
Perform <subroutine> in program <external program> [parameters list].

Syntax 2
Perform <subroutine> (<external program>) [parameters list].

Note: External program can be either another executable program or subroutine pool.
MODULARIZATION TECHNIQUES :
Subroutines with parameters( for data exchange and manipulation)

We can define subroutines with parameters. For this we use the following keywords.
1. Using
2. Changing
3. Tables

The parameters specified as part of subroutine definition are called as formal parameters and the parameters
specified at the time of calling the subroutine are called as actual parameters.
MODULARIZATION TECHNIQUES :
INCLUDE PROGRAMS:
• It is a reusable repository object, which can be used for declaring global variables, subroutines, module
definitions and class definitions.
• To use the components of include program inside other repository objects, we must include the include program
by using INCLUDE keyword.

Syntax:
Include <include name>.
• It is recommended to include the include program at the beginning of the repository object.
• If the include program contains any block definitions (subroutine or module definitions or class definitions) and if
the include program is included at the beginning of the executable program, it leads to syntax error statement is
not accessible.
• To avoid this, explicitly we need to handle the event start-of-selection after include statement to indicate the
starting point of program execution.

• Start-of-selection event should be handled after the include statement.

• Start-of-selection event indicates starting point of program execution.
MODULARIZATION TECHNIQUES :
Function modules:
• It is a set of statements which are defined only once and can be called any no. of times. We can create custom
function modules by using function builder tool (SE37).

• There are many standard function modules provided by SAP itself. These function modules can be
called/accessed in different programs by passing values to the appropriate parameters.

• Function modules (custom/standard) are stored inside function group.

• Function group is a container of function modules.

• Table for function module-> TFDIR (accessed from SE11)

• Table for repository objects (executable, include, sub routine pool)  TADIR

• Table for SAP Tables  DD02L

MODULARIZATION TECHNIQUES :
Function group:

Before creating custom function module, we need to create or consider a function group which already exists.
Function group can be created either by se80 (object navigator) / se37.

In SE37, choose the menu, go to function groups, create group.

Whenever a function group is created, SAP creates two include programs.

A. Include ending with TOP:

This is called as top include program, which can be used for declaring global variables, subroutine, module
definitions and class definitions.
The components of the top include program can be accessed by all the function modules of that particular function
group.

B. Include ending with UXX

It is reserved for SAP internal use. As part of this include, SAP generates sub includes (i.e), whenever a new
function module is created, a sub include will be generated on behalf of that function module.
MODULARIZATION TECHNIQUES :
Syntax for defining function module:

Function <function name>.

Statements.
Endfunction.

Syntax for calling normal function module:

Call function <function name> <parameter list>.

Before calling any function module, we must check the signature of the function module to understand the
parameter types, return values, default values, pass by value or pass by reference, optional and mandatory
parameters.
MODULARIZATION TECHNIQUES :
As part of function modules we have 4 types of parameters:
1. Import 2. Export 3. Tables 4. Changing.

Import parameters:
Are the parameters which are received by the function module.

Export parameters:
Are the parameters which are returned by the function module. Export parameters are always optional.

Changing parameters:
Acts as both import and export, we go for changing parameters when we need to use same variable for passing the
value as well as receiving the return value.

Tables:
Are used for dealing with internal tables as parameters to function modules , these internal tables must refer to
dictionary structures created in SE11.
Interview / Assessment Booster

Database Programming
Database Programming :
To interact with the SAP Database from ABAP applications, we use Open SQL (Standard query language)
statements.

Procedure for interacting with databases from ABAP Programs:

1. Analyze the db table and the required fields (field name, data types, sequence) which needs to be retrieved.

2. Declare the corresponding declarations (structure / internal table/ individual fields).

structure -> for holding single record

Internal table -> for holding multiple records
Fields --> for holding individual fields.

3. Retrieve the data from the database tables and store the same in the required target variables.

4. Process the target variables (structure / internal table / fields) accordingly.

Database Programming- Select Statement :
Select single Statement 
• It is an open sql statement used for retrieving single record from the database table.
• Whenever we use select single, it is recommended to use where clause in the select query comparing with
primary key field to ensure appropriate record is retrieved (if available).

Select statement 

• It is a open SQL statement used for retrieving multiple records from the database.
• It is a looping statement, where in, for each select statement execution, it retrieves single record, and the no. of
times the select query execution depends on the no. of records satisfying the condition.
• If there are more select queries, it increases network traffic and thereby decreases performance.
• Because of this reason, it is recommended to minimize the usage of select..endselect and instead use SELECT
INTO TABLE statement and retrieve the required no. of records using one select statement execution and store
the retrieved data into an internal table.
Database Programming- Select Options:
It generates a selection-screen for reading ranges of input values. It is an internal table created in the run time by
SAP based on the select-option field. It contains following structure:

a) Sign  Possible values are I (Inclusive) / E (exclusive). Default value is I.

• I  considers values from lower limit to upper limit
• E  considers values before lower limit and after upper limit

b) Option  Possible values are BT (between), <, >,<=,>=. Default value is BT.

c) Low  holds lower limit of the range.

d) High  holds upper limit of the range.

Syntax for declaring select-option:

Select-options <variable> for <target field>.

Database Programming- Control Break Events :
These events are used only in loop- endloop.

At first: -
This event is triggered when we are processing the 1st row of the internal table. This event can be handled to
provide heading for the report before displaying the data.
Syntax:
At first.
Statements.
Endat.

At new:-
This event is triggered at the beginning of first row combination whenever a unique value is encountered for the
specified field. This event can be handled to generate sub heading at the beginning of every unique value.
Syntax:
At new <field name>.
Statements.
Endat.
Database Programming- Control Break Events :
At end of:
This event is triggered at the end of the last row combination of every unique value for the specified field. This
event can be handled to generate subtotals at the end of every unique value.

Syntax:
At end of <field name>.
Statements.
Endat.

At last:
This event is triggered at the end of the last row of the internal table. This event can be handled to generate footer
for the report like grand total.

Syntax:
At last .
Statement.
Endat.
Database Programming- Control Break Events :
On change of:

It is similar to AT NEW event, but on change of event can be used in any of the looping statements like while –
endwhile. do enddo, select – endselect, loop-endloop whereas AT NEW can be used only inside loop-endloop.
Database Programming- Interactive Classical Reports :
This is generated based on the user interaction in the runtime.

In classical interactive reporting: we can generate up to 21 lists. The first list is called as basic list and the
remaining 20 are called as secondary list.

SY-LSIND is the system field which stores the index OF NEXT LIST (secondary list). For the basic list, index is
zero and the secondary lists indexes ranges from 1 to 20.

Events in Interactive Classical Reports 

• At-Line Selection.
• Top-of-Page
• Top-of-Page during Line-Selection.
• End-of-Page.
Database Programming- Interactive Classical Reports :
1. At line-selection: This event is triggered when the user double clicks on a list value or a single click on a
hotspot list value. In this case, the line content where the user has done the interaction is captured in the system
field SY-LISEL and the line number is captured in SY-LINNO.

2. Top-of-page: This event is triggered in the basic list and it can be handled to generate the heading for the basic
list.

3. Top-of-page during line-selection: This event is triggered in the secondary lists and it can be handled to
generate the heading for secondary list.

4. End-of-page: This event might be triggered in every list whenever the end of page is reached. This event can be
handled to generate the footer for the list pages.

Note:-
• End-of-page event is triggered only when the end of page is reached, for this, we need to control the number of
lines per page. This is done by using line-count option as part of report statement.
• If the no. of lines reserved for the page is consumed by TOP-OF-PAGE event or TOP-OF-PAGE DURING LINE-
SELECTION event itself, it leads to runtime error list page overflow as the content cannot be fitted on the page.
Interview / Assessment Booster

Dictionary Objects
Dictionary Objects:
Dictionary objects (SE11)

1. Tables
2. Views
3. Data elements
4. Domains
5. Type Groups
6. Search Helps
7. Table Types
8. Lock objects
9. Structures

DB Table can be used to store the data permanently.

Data can be categorized into 2 types. master data & Transaction data.
Dictionary Objects:
Master data:
The data which doesn’t change frequently is known as master data.
Example:- Empno, ename, customer no, customer name ,bank account no, bank account holder name, material
data, vendor data.

Transaction data:
Day to day business data is called transaction data.
Example:-Emp attendance details, emp salaries, customer orders, bank transactions.
Dictionary Objects:
Primary key:
A field declared as primary key can’t accept the duplicate values.
In SAP, every table must contain minimum 1 key field and max. 16 primary fields. Primary key fields must be at the
beginning of the table.
Combination of primary key fields is called as composite key.

Based on the client concept, the database tables are classified into two types.
i. Client dependent tables. - MANDT
ii. Client independent tables. - not having MANDT
Dictionary Objects:
Client dependent tables:
The tables which contains MANDT as first field is called client dependent.
MANDT field will hold the client no.
The records in these tables are specific to the client i.e. the record inserted in one client will not
available in other client.
Eg: KNA1, MARA, LFA1, VBAK, VBAP, EKKO, EKPO, VBRK, VBRP.

Client independent tables:

This table doesn’t contain MANDT field.
The records in this tables are not specific to any client’s i.e. they are available across the
Client’s.
Eg: TFDIR, TADIR
Dictionary Objects – DB Table:
Table creation:

A table is dictionary object which is a collection of rows (records) and columns (fields)
Tables are used for storing the data permanently.

In ABAP a table field can be created in two ways:-

i. By using direct data types.
ii. By using data elements and domains (recommended).

Procedure for creating custom database tables:

i. Analyze the fields and the corresponding data types.
ii. Create and activate the table.
iii. Generate table maintenance.
iv. Declare and define events (if required) at the table maintenance level.
v. Create the t-code for the table maintenance.
Dictionary Objects – DB Table:
Minimum settings required for creating custom database tables:

Delivery and maintenance settings:

1. Delivery class.
2. Data browser / table view maintenance.

Delivery class:
It is used for controlling the transporting of table data.
The possible values are A or C.

A -> application table used for storing master and transaction data.
Generally it is recommended to create the client dependent table as application table.
C -> customizing table used for storing customers specific data.

Data browser / table view maintenance:

It can contain the following 3 possible values.
Dictionary Objects – DB Table:
In dialog box:
1. Display / Maintenance allowed with restriction.
Note: In this we can only view the data but we can’t perform the operations like insertion, deletion and modification.
2. Display Maintenance allowed.
It supports all the operations i.e we can view, insert , delete and modify.
3. Display maintenance not allowed.
It doesn’t support any of the operations.

Technical settings:
1. Data class.
2. Size category
Data class:
It specifies the schema (partition) in which the table has to be stored. As an ABAP Consultant we
will use only Master Schema (APPL0) and Transaction schema (APPL1).
Dictionary Objects – DB Table:
Size category:
It specifies the initial amount of memory that needs to be allocated for the database table.
When the initial memory is utilized, the memory gets extended automatically to the amount of initial size.
In size category the range of number of data records depends upon structure of the table.

Enhancement category:
It specifies the type of enhancement that can be made to the table.
Enhancement is a process of adding the additional fields in the standard tables.
Dictionary Objects – Database Table:
Limitations of table fields creation using direct data types:

• Always the character field values are captured in upper case.

• We cannot impose validations on table data.
• It doesn’t support reusability
• Cannot maintain field labels.

Table creation using data elements and domains:

Data element: is a reusable dictionary object which provides description for the field. I.e. the description (labels)
maintained at data element level will automatically appear on the screen wherever the data element is referred. It
can be created by referring to a direct data type / referring to a domain. We can also associate a search help (f4
help) as part of data element.
Domain: is a reusable dictionary object which stores technical properties of the field like data type, size, fixed
values, value table….
Note:
If it is client dependent table we have to give minimum two primary key fields otherwise if only mandt is primary key
field then we can maintain maximum of single record.
Table maintenance:
Table maintenance:
• After creating every database table, ABAP consultant must generate Table Maintenance.
• The table maintenance allows the end user to maintain the table for performing the operations like insertion,
deletion, Modification and view the data (display). CRUD
• For generating table maintenance we require function group.
• A function group is an object which stores the objects related to table maintenance.
• Dependent objects (screens, subroutines, FMs) related to table maintenance are stored inside function group.
For creating Function group, we use SE80.
As part of generating table maintenance, we need to specify maintenance type which is of two types.
Maintenance type is of two types:-
i. One step:
• In one step only one screen is generated called as overview screen in which all the CRUD (create, read,
update and delete) operations are performed.
ii. Two step:
• In two step, Two screens will be generated, overview screen and single screen.
• In overview screen we can only view the data, delete the data and modify the data.
• In single screen we can insert the data.
Dictionary Objects – Structures :
Creating Dictionary structures (Global structures): A structure is a collection of different types of fields
(se11  choose data type radio button, provide name of structure, Create  choose structure radio button and
create the required fields).

Once a dictionary structure is created, we can include the dictionary structure in other dictionary structures /
database tables by using .include keyword.

We can also include dictionary structures inside local structures of repository objects using the statements include
structure <structure name> or include type <structure name>
Dictionary Objects – Type Group :
Type groups:

• It is a collection of global types and constants.

• All the components in the type group must prefix with type group name followed by _.

• Inside the type group we can use only types and constant keywords.

• To use the components of the type group inside the repository objects, We must declare the type group by
using the keyword “type-pools" .

• Standard type-groups: CNTL, CNDP, SLIS, ICON, VRM…..

Dictionary Objects – Index:
Indexes:
• Indexing is a process of arranging the data in an order.
• Indexes are always created on top of database tables.
• There are two types of indexes:-
1. Primary index 2. Secondary index.

Primary index:
• Primary index is created by sap itself on top of primary key field.
• As a developer we can create only a secondary index and it can be created on non primary key fields.
Secondary indexes are of two types:
1. Unique. 2. Non-unique.
Unique Secondary Index:
• Whenever a unique secondary index is created on a field we can’t maintain duplicate values for that field.
• Whenever a unique secondary index is created on client dependent tables, client field (MANDT) should be part
of indexed fields.
Non-Unique Secondary Index:
• Whenever a non-unique secondary index is created on a field, it is possible to maintain duplicate values for that
field.
Dictionary Objects – Views:
Views:

• A view is a reusable dictionary object which doesn’t exist physically i.e. it is virtual table (IMAGINARY TABLE).
The data in the view will be populated only in the runtime.
• A view doesn’t hold any data by default. Views are used for hiding the original table names, hiding field names,
restricting the access to table data, to read data from one or more tables.
• Views are created on top of database tables.

They are 4 types of views.

i. Database view
ii. Projection view
iii. Maintenance view
iv. Help view
Dictionary Objects – Views:
Database view:
• It can be created either on single table or multiple tables And supports both Projection and Selection.

• Projection is a process of selecting only required fields and selection is a process of imposing conditions on
accessing the table data.

• A database view created on single table can be Read only (or) Read and Change. I.e. the changes made to the
data at the view level will automatically reflect the corresponding base table and vice versa.

• A database view created on multiple tables is always Read only.

• We cannot generate table maintenance for DB views.

• Whenever we create any view based on multiple tables, we must provide the join conditions by comparing with
logically related fields, otherwise it will lead to Cartesian product (No. of entries of one table * No of resultant
values of other table)

• Whenever we create database view on multiple tables with join conditions, it constructs the resultant values
based on inner join.
Dictionary Objects – Views:
Projection view:

• It is always created on single table.

• It supports only projection but not selection.

• We go for projection view, whenever we need to share complete data of the base table but with limited fields.

• Maintenance status can be Read (or) Read and Change.

• For both database and projection views we can’t generate Table Maintenance.
Dictionary Objects – Views:
Maintenance view:

This is always created on single table, based on the foreign key table selected, SAP proposes join condition.

We can generate table maintenance for maintenance view

Its support both selection and projection.

View cluster: - is a collection of views which are grouped together and it simplifies the maintenance of complex
cross-client data (across the tables)
Dictionary Objects – Foreign Key Relationship:
Foreign key relationship between tables:
• We create foreign key relationship between two tables to maintain data consistency. i.e the data of one table is
based on data of other table.
• In Foreign Key relationship, two tables are involved. A) Check table b) Foreign key table
• Check table: is a parent table where we maintain the key data.
• To create a foreign key relationship between two tables, the two tables must contain at least one field which is
having common domain and in one of the table the common field should be a primary key field and this table is
considered as check table as it maintains unique values for that common field.

• On the other table common field, we create foreign key which is called as Foreign Key Table.

• Once a foreign key relationship is created, it maintains referential integrity.

• According to this, in the foreign key table we can enter only those values for the common field which needs to be
available in check table common field.

• We need to insert a child row (record in the foreign key table) only when there is a corresponding record in
parent record (records in parent table->check table).
Dictionary Objects – Currency and Quantity Fields:
Working with Currency and Quantity Fields:

Whenever a table field or structure field contains CURR (currency) or QUAN (quantity) fields, we must specify
reference table and reference field.

The reference table can be same table (or) external table and reference field can be same table field (or) external
table field.
The reference data type for (CURR) currency is CUKY and reference data type for (QUAN) quantity is UNIT.

TCURC  Table for Currency Codes

TOO6  Table for units of measurement

Dictionary Objects – Table Type:
Table types: is the reusable dictionary object.

Table types are the internal tables created at database level.

A Table type can refer to a direct data type / line type (structure)/ reference type (class or interface)
Dictionary Objects – Lock Objects:
Lock Objects 

• They are used for performing row-level locking of the table data.

• By Default, Object level locking (Repository / Dictionary objects) is taken care by SAP itself. i.e only one user
can edit an object at any point of time, other users can only read the object.

• Lock Objects names must start with EZ (or) EY and locking is done based on primary key field/s.

• Whenever a Lock object is created, SAP creates 2 Function modules.

a) ENQUEUE_<LOCK OBJECT NAME>  used for locking the row.

b) DEQUEUE_<LOCK OBJECT NAME>  used for releasing the lock.

Dictionary Objects – Lock Objects:
Types of Lock Modes:

Exclusive / Write Lock  In this, only one user can read or edit the locked record. If other users request for the
Exclusive lock, his request will be rejected but the request is stored in the queue. Once the first user releases the
exclusive lock, the exclusive lock access is given to other user in the queue.

Shared / Read Lock: In this, multiple users can read the locked record and if a user modifies the locked record,
the modified data is not accessible to other users.

Exclusive but not cumulative: It is similar to Exclusive lock, but other users request is not stored in the queue,
but instead the others users have to send the fresh request.
Dictionary Objects – Search Helps :
SEARCH HELPS:

• It is a reusable dictionary object used for providing list of values as input help to the user.
• It is triggered when the user presses F4 key in the Input Field.

Once a Search help is created, we can associate the search help at 3 different levels:

1. Data element level.

2. Selection-Screen input field level.
3. Module Pool (Dialog screen) input field level.

There are 2 types of Search helps:

1. Elementary Search Help  provides single input path for list of values.

2. Collective Search Help  collection of elementary search helps  provides multiple input paths for list of
values.
Interview / Assessment Booster

Transport Request
Transport Management :
Every object that an ABAP consultant develops must be transported (moved) from development client to quality
client and then to production client.

For this, we need to store the object inside a transportable package, so that the object is assigned to Transport
request / Change Request.

A Transport request is a collection of one or more tasks. Every task can be associated with one or more objects.

• Every user should create their own task/s under main request for storing their respective objects.

• For Creating/Managing transport requests/tasks, we use Transport Organizer tool (SE09 / SE10).

There are two types of transport requests:

• Workbench Request Captures the changes made to repository objects (executable programs, include
programs / subroutine pool…. / dictionary objects (tables, search helps)

• Customizing Request Captures configuration changes / data related changes.

Transport Management :
Status of the tasks:

Unclassified: The task which is not associated with any objects.

Development/Correction: It is a task which is under development i.e it contains at least one object.

• Once the development is done i.e once all the objects assigned to us are finished with the development, we
need to release our task and send the screenshot of the same to the owner of the request.

• A Task can be released only when all the objects inside that task are in active state.

• Once all the tasks are released, the owner of the request will release the main request which indicates that the
request is ready for transportation.
Transport Management :
Copying Task from one request to other Request:

• For this, create another request with a task and ensure at least one object is stored in this new task (atleast
dummy object) or change the status of the new task from unclassified to development/correction MANUALLY.

• Now, In SE09, double click on the source task , copy the objects from source task and paste the same in the
target task. Once copied, delete the objects from the source task and then delete the source task.

Version Management:

• It is a process of comparing multiple versions of the objects to identify the similarities and differences so that at
any point of time, we can retrieve back the older versions.

• Whenever we retrieve the older version, the current version will be overwritten with the new version and gets
stored in the new request. The version comparisons can be between the same client or across the clients.
Interview / Assessment Booster

Module Pool Programming

MPP :
PURPOSE:

• Design new SAP Transactions which are specific to customers.

• Enhancing Existing SAP transactions (used along with enhancements)
• cross-apps  Dialog Programming  Screen painter tool (SE51).

Screen painter tool Contains 4 sections

1. Attributes  Description, Type of screen (Normal , Subscreen, Dialog box)

2. Layout  Design the Transaction with different elements
3. Flowlogic  Implement the events in the corresponding module definitions
4. Element List  SAP internal use contains elements information placed on the screen layout.

Note  A Module pool program cannot be executed directly; it needs to be associated with a transaction code.
MPP :
Procedure for developing Module pool Programs:

• Create a module pool program in object navigator (SE80) (with top include recommended).

• Create the initial screen using screen painter tool and provide the description and choose the type of screen in
Attributes tab.

• Design the screen layout with different elements (textfields, i/o fields, Check Box, radio Buttons, table
Control….) and also set the appropriate properties for each of the elements.

• Implement the events in the flowlogic by defining the corresponding modules.

• Repeat the steps 2,3,4 for each of the screens.

• Create the t-code for the module pool program by associating with the initial screen of the transaction.
MPP :
Events in Dialog programming: 1. PBO 2. PAI 3. POV 4. POH.

PBO (Process before output):

This event functionality is similar to At Selection-screen output event in case of selection screen. This event is
triggered in the following cases:

a) Whenever the screen is displayed for the first time.

b) After PAI event.

This event can be handled for the following cases:

1. To initialize the screen elements with the default values.

2. To Refresh the screen appearance after the user interaction in the runtime.
MPP :
PAI (Process after Input): This event functionality is similar to At selection-screen event in case of selection-
screen. This event is triggered in the following cases:

a) When the user presses enter key in the input field.

b) When the user selects/deselects a checkbox or when the user selects a radio button.

c) When the user selects a value in the dropdown list box.

d) When the user scrolls in the table control.

e) When the user clicks on the pushbutton.

This event can be handled to provide an action whenever a user performs an action in/on a screen element in the
runtime.
MPP :
POV (Process on value-request): This event functionality is similar to At selection screen on value-request event
in case of selection-screen. This event is triggered in the following case:

a) When the user presses f4 key in the input field.

This event can be handled to provide custom F4 values whenever a user presses F4 key in the screen input field.

POH (Process on help-request): This event functionality is similar to At selection-screen on help-request event in
case of selection-screen. This event is triggered in the following case:

a) When the user presses f1 key in/on the screen element. This event can be handled to provide custom F1 help
whenever a user presses F1 key in/on the screen element.

Note: Whenever we need to refer to the screen element inside the program, we need to declare a variable with the
same name and type as that of screen element.
MPP :
Module Pool Screen Elements 

TABSTRIP CONTROL:

• A tabstrip control is a collection of TAB Buttons. Each Tab button should be associated with a subscreen.
• A subscreen cannot be placed directly on top of normal screen;
• it should be placed on top of a subscreen area.
• We can use same / different subscreen areas for each tab.

A Subscreen area is a collection of subscreens.

Note: Whenever a normal screen/subscreen layout contains tabstrip control, it should be declared explicitly by
using controls keyword., otherwise it leads to runtime error control not found.

The datatype for tabstrip control is tabstrip.

MPP :
Syntax for Declaring Tabstrip control:

Controls <tabstrip name> type tabstrip.

Note:
• By Default, The first tab will be active in the Tabstrip control.
• We can use the property ACTIVETAB of tabstrip control to activate a specific tab button in tabstrip control.
• Each Tab should be associated with a subscreen. Since Subscreen cannot be placed on top of normal screen,
we need to place subscreen area in each tab and then in the runtime, the subscreen will sit on TOP OF
subscreen area.
• We can use same/different subscreen areas FOR each tab. The no. of calls to CALL SUBSCREEN statement
depends on the no. of subscreen areas.
• Subscreens should be called from the flowlogic section.

Syntax for calling subscreens:

Call subscreen <subscreen area> including <subscreen program name> <subscreen no>.
MPP :
TABLE CONTROL: It is used for displaying the data in the form of rows and columns.

Note:
• Whenever a screen / subscreen contains table control component and when we do syntax check, it gives error
as loop endloop is required in both PBO and PAI.
• In order to avoid this error in the design time, initially provide loop and endloop in both PBO and PAI events.
• Whenever a screen/subscreen layout contains table control, it should be declared explicitly by using controls
keyword.
• The data type for table control is table view. If it not declared, it leads to runtime error control not found.

Syntax for declaring Table control:

Controls <table control name> type tableview using screen <screen no>.

By default, Table control vertical scrolling property is disabled. To enable it, we need to set the LINES property of
table control.
Interview / Assessment Booster

BDC – Batch Data Communication

BDC :
BDC (Batch Data communication): used for migrating data from legacy system to SAP System. Legacy system
can be a text/excel file. Legacy system file can be on a local system (Presentation server) or can be on a server
(Application server).

BDC Techniques:

1. Direct Input method

2. Batch Input method
a) Call Transaction method
b) Session method.
BDC :
Procedure for using BDC techniques.

a) Identify the format (type) of the data.

b) Identify the base table/s in SAP.

c) Identify the no. of fields per record.

d) Identify the sequence, delimiter and corresponding fields in SAP.

e) Identify the BDC technique which needs to be used for data transfer.
i) Direct input method.
ii) Batch input method (Call transaction or Session method).
BDC :
Working with Files on Presentation Server (Local System):

To Read (Upload) data from Local text file to internal table, we can use the following F.M.s
a) GUI_UPLOAD (Recommended)
b) WS_UPLOAD (Deprecated)
c) UPLOAD (Deprecated)

To Write (Download) data from internal table to Local text file, we can use the following F.M.s
a) GUI_DOWNLOAD (Recommended)
b) WS_DOWNLOAD (Deprecated)
c) DOWNLOAD (Deprecated)

To Read data from Local excel file to internal table, we can use the following F.M's
1. ALSM_EXCEL_TO_INTERNAL_TABLE (or)
2. TEXT_CONVERT_XLS_TO_SAP
BDC :
Working with Files on Application server:

Syntax for opening Application Server File:

open dataset <path> for <file opening mode> in <text mode> / <binary mode> encoding default [message <msg
variable>].

Note: If the file is successfully opened, sy-subrc is set to 0 otherwise 4.

File opening modes:

1. input --> for reading.

2. output --> for writing.
3. appending --> for appending data to end of file.
4. update --> for read / write.
BDC :
Note:
1. In 'text' mode, we can perform read/write line by line, In 'binary' mode, we can perform read/write character by
character (byte by byte).

2. If the file is not opened, the operating system message is captured in message VARIABLE specified as part of
Open dataset statement.

3. If an existing file is opened in Output mode, it deletes the previous contents of the file and places the file pointer
at the beginning of the file for writing new content.

4. If a non-existing file is tried to open in Output mode, it creates the file and places the file pointer at the beginning
of the file for writing the content.

5. If an existing file is opened in Appending mode, it places the file pointer at the end of the file for appending new
content.

6. If a non-existing file is tried to open in Appending mode, it creates the file and places the file pointer at the
beginning of the file for writing new content.
BDC :
Syntax for Reading a line from Application Server File:
read dataset <path> into <target variable>.
Note: If the line is successfully read, sy-subrc is set to 0 otherwise 4.

Syntax for Writing a line to Application Server File:

Transfer <variable> to <path>.
Note: Transfer can transfer only string content.

Syntax for Closing a Application Server File:

Close dataset <path>.

Syntax for Deleting a Application Server File:

Delete dataset <path>.

Syntax to Get the position of the file pointer in Application Server File:
Get dataset <path> position <integer variable>.

Syntax to Set the file pointer at desired position in Application Server File:
Set dataset <path> position <integer variable>.
BDC :
BDCDATA Structure:

It is a dictionary structure provided by SAP based on which we need to create an internal table. As part of this
BDCDATA internal table, we need to map the internal table data which is read from legacy system and also it holds
the Module pool program information (Transaction information- Module pool program name, Module pool Screen
No, Screen Field names).

Processing Modes:

3 types of processing modes:

1. A (Display All) Foreground (default)  All Records are displayed and error records are validated after the
user interaction on the screen.

2. E (Display Errors)  All Records are displayed and error records are validated as when they are displayed on
the screen (explicit user interaction not required).

3. N (Background, No Display)
BDC :
Update Modes:

3 types of update modes:

1. A (Asynchronous) (default)  Doesn’t wait for any updates.

2. S (Synchronous)  waits for update and then processes next record.

3. L (Local Update)  uses same process to update the data.

Note: Performance wise Asynchronous update mode is faster than Synchronous update mode as Asynchronous
update mode doesn’t wait for any updates.
BDC :
BDCMSGCOLL Structure:

It is a dictionary structure provided by SAP based on which we need to create an internal table.
As part of this BDCMSGCOLL internal table, SAP collects the messages that are populated during data migration,
based on this internal table we can generate the log related to data migration using Call Transaction method.
BDC :
Data transfer using Session method:

As part of this, we use 3 F.Ms

1. BDC_OPEN_GROUP: To create and Open the session object. Important parameters for this are

a) Client  client no where the session object needs to be created.

b) Group  session object name.

c) Hold date  holds the date till which the session object needs to be locked.

d) Keep  if set to X, the session object will be retained after processing for later analysis.

e) Uname  holds the user name who is authorized to process the session object.
BDC :
2. BDC_INSERT: To Map the BDCDATA internal table data to Session Object.

Important parameters for this are

a) Tcode  holds the t-code of the module pool transaction through which the data is migrated.

b) Dynprotab  holds the BDCDATA internal table.

3. BDC_CLOSE_GROUP: To close the session Object.

Note:
• Once a session object is created, we can process the session object using SM35.
• Once Session object is processed, a log will be generated automatically which we can analyze.
BDC :
Procedure for Recording the Transactions for Migrating data from Legacy Systems to SAP:

1. Analyze the legacy system file for understanding type of data, no. of fields, delimiter, and technical field
names/table names in SAP.

2. By using SHDB T-code, Record the appropriate transaction by providing the sample data for the fields available
in the legacy system file.

3. Once the recording is completed, System displays the recorded details mapped with BDCDATA. In this screen,
make a note of the field names for which the sample data is provided. The purpose is we will get an idea
where we need to the changes in the recorded generated program.

4. In the recorded generated program, make the necessary changes to read the data from our legacy system and
replace the recorded field values with the legacy system data.
BDC :
5. After editing the program, execute the program and choose either session technique or call transaction
technique.

6. In case of session technique, provide the session name and select the check box keep session so that we can
analyze the processed session objects at later point of time.

7. For processing session objects, go to t-code SM35 and process it in foreground / background. In both the cases,
a log will be generated for analyzing the processed session object.

8. In order to process the session objects without using SM35 , collect the QUEUE id of the session object from
SM35 and execute the standard program RSBDCBTC which processes the session object in the background.

9. We can also use the standard program RSBDCSUB which takes a specific session object as input / we can also
provide the date range.
BDC :
BDC using Table control:

• In BDC using Table control, the field names of the table control depends on the row id of the table control. i.e the
field names are suffixed with the corresponding row id.

• So, when we migrate the data to SAP Screen containing table control, the field names of the table control should
be dynamically generated based on the row id of the table control.
Interview / Assessment Booster

Scripts, Smart Forms, Adobe Forms

Scripts :
Scripts (SE71)

- It is a word processing tool used for designing the business documents.

- As part of every business there are different documents exchanged on a daily basis.

- Some of the business documents are enquiry, quotation, purchase order, sales order, invoice, shipping, delivery
etc..

- By using SAP Scripts we can design new documents and modify the documents provided by SAP.

- Form Painter is Tool used for designing the templates.

- Once the template is designed we require a driver program or a print program to invoke/call the SAP Script.

- This print program is usually an executable program, as part of this we use the following function modules.
a. Open_form. b. Write _form. c. Close_from. d. Start_form e. End_form
Scripts :
Open_form:

Is used for opening the form, it contains the following parameters.

a. Form : it holds the name of the form.

b. Language: it holds the language key in which the form NEEDS to be opened.

Write_form:

It is used for passing the data and invoking the windows in the form .

a. Element: it holds the name of the element.

b. Window : it holds the window name.

Scripts :
Close_form:

It is used for closing the form.

Notes:

• If the F.M close_form is not called, form will be displayed and closed automatically. i.e no preview will be
available.

• Sap script is language dependent and client dependent.

• By default the text in the script windows will be displayed twice.

• To eliminate this repetition we need to define text elements .

• The number of calls to the function module write_form depends upon number of elements, number of windows
in the form.
Scripts :
Types of symbols in SAP Scripts
As part of repository objects we use system fields which represent some values.
As part of scripts we can use 4 types of symbols.
1. System symbols. 2. Standard symbols. 3. Program symbols. 4. Text symbols.

• System symbols  These symbols and values exist in the table TTXSY.

• Standard symbols  These symbols and values exist in the table TTDTG.

• Program Symbols are used for passing parameters to SAP scripts from driver program. The program
symbol names in the layout and in the driver program must be same.
Note: System symbols, Standard symbols, Program symbols are enclosed between &<symbol name>&.

• Text symbols These are the variables defined as part of layout and they are also represented by control
commands.

To Display images in SAP Scripts, we need to first upload the .bmp images using SE78 and then in order to display
the image in the layout we need to create either Graphic object on the layout or use the BITMAP control command
in the window to include the bitmap image (insert menu  graphics).
Scripts :
Script Language Translation:

SE76 is the t-code used for translating scripts in to different languages. As part of this translation, we can translate

a) Descriptions
b) Titles
c) Text in the windows

Note: Once the script is translated into different languages, as part of driver program, we need to provide the
system field sy-langu as part of language parameter in open_form F.M..

Depending on the logon language, the appropriate language form is displayed. If the form is not maintained in that
language, then parent language form will be displayed.
Smart Forms :
SMARTFORMS

Every Business contains Business Documents like Enquiry, Quotation, Purchase Order, Sales Order, Invoice,
Delivery Schedule....

To Design these Business Documents Templates, We use word processing tools like SAP Scripts, Smartforms,
ADOBE Forms.

• SAP Scripts  Form Painter tool (T-code 'SE71')

• SMARTFORMS  Smartforms tool (T-code 'SMARTFORMS')

• ADOBE Forms  Form Builder tool (T-code 'SFP')

Smart Forms :
SMARTFORMS:

SMARTFORMS  used for Designing layouts (templates) of Business Documents.

a) Design layout  SMARTFORMS tool (T-code 'SMARTFORMS')

 Activate smartform  Generates F.M dynamically

 F.M will act as driver program/print program  directly executed for testing

(or) b) Executable program  Call smartform F.M

T-code for SMARTFORMS is SMARTFORMS.

Smart Forms :
1. General Settings

a) Form Attributes  Provide Description and it contains administration information (username, date, time,
package....)

b) Form Interface  In this, we declare the parameters which needs to be passed to the smartform while calling it
(import, export, tables...)

c) Global definitions  In this, we declare the global variables (individual variables, work area, internal table,
types declaration...), provide select statements.
Smart Forms :

2. Pages and Windows  In this, we design the pages layout and windows.

Note:

• As part of driver program, it is recommended not to directly call the smartform F.M as this F.M name depends on
the client numbering formats of each client, so when we transport the smartform to quality/production clients and
when we activate the smartform there, it generates new F.M whose name depends on the numbering sequence
of that particular client.

• So it is recommended to get the smartform F.M name dynamically and it is done by calling the std.F.M
SSF_FUNCTION_MODULE_NAME' which takes smartform name as input and returns the associated
smartform F.M name which is specific to that particular client.
Adobe Forms :

It is used for designing the template of Business Documents. Tool used is Form Builder (SFP Tcode).

Software Requirements: (Apart from SAP Software).

1. ADOBE Life Cycle Designer

2. ADS (ADOBE Document Services)

Adobe forms  (supports both static and interactive forms)

Procedure:
1. Create ADOBE Interface  SFP T-code
a) Declare parameters
b) Declare global variables
c) Select statements for data retrieval

2. Create Adobe form (SFP T-code)  Based on adobe interface

Adobe Forms :
2. Create Adobe form (SFP T-code)  Based on adobe interface.

a) Map the parameters and variable Declarations, adobe system fields from adobe interface context to adobe
form context

b) Design the layout for the adobe form based on the adobe form context

c) Activate  generates FM  execute and test.

Calling the adobe forms externally from driver program.

Executable program  call Adobe Form F.M which will act as driver for calling the adobe form.

Procedure:
1. Start the job by calling the F.M FP_JOB_OPEN.
2. Get the adobe form FM dynamically by calling the F.M FP_FUNCTION_MODULE_NAME.
3. Call the adobe form FM.
4. Close the job by calling the F.M FP_JOB_CLOSE.