Explore topic-wise InterviewSolutions in .

In contrast to normal subroutines FUNCTION modules have UNIQUELY defined interface. Declaring data as COMMON parts is not possible for function modules. Function modules are stored in a CENTRAL library.

In contrast to normal subroutines function modules have uniquely defined interface. Declaring data as common parts is not possible for function modules. Function modules are stored in a central library.

A function group is a COLLECTION of logically related modules that share global data with each other. All the modules in the group are included in the same main PROGRAM. When an ABAP/4 program contains a CALL FUNCTION STATEMENT, the system LOADS the entire function group in with the program CODE at runtime. Every function module belongs to a function group.

A function group is a collection of logically related modules that share global data with each other. All the modules in the group are included in the same main program. When an ABAP/4 program contains a CALL FUNCTION statement, the system loads the entire function group in with the program code at runtime. Every function module belongs to a function group.

During a call by REFERENCE damage or loss of data is not restricted to the subroutine, but will instantly LEAD to CHANGES to the original data OBJECTS.

During a call by reference damage or loss of data is not restricted to the subroutine, but will instantly lead to changes to the original data objects.

It is an SAP PROVIDED PROCEDURE for UPDATING a DATABASE.

It is an SAP provided procedure for updating a database.

The system PERFORMS the MODULE processing asynchronously. Instead of carrying out the call IMMEDIATELY, the system waits until the NEXT DATABASE update is triggered with the 'COMMIT WORK' command.

The system performs the module processing asynchronously. Instead of carrying out the call immediately, the system waits until the next database update is triggered with the 'COMMIT WORK' command.

• The lines of an internal table always have the same structure. By using extract datasets, you can handle groups of data with different structure and get statistical figures from the grouped data.
• You have to define the structure of the internal table at the BEGINNING. You need not define the structure of the extract dataset.
• In contrast to internal tables, the SYSTEM PARTLY compresses exact datasets when storing them. This reduces the STORAGE space required.
• Internal tables require special WORK area for interface whereas extract datasets do not need a special work area for interface.

• The lines of an internal table always have the same structure. By using extract datasets, you can handle groups of data with different structure and get statistical figures from the grouped data.
• You have to define the structure of the internal table at the beginning. You need not define the structure of the extract dataset.
• In contrast to internal tables, the system partly compresses exact datasets when storing them. This reduces the storage space required.
• Internal tables require special work area for interface whereas extract datasets do not need a special work area for interface.

YES. But it LEADS to UNNECESSARY DATA REDUNDANCY.

Yes. But it leads to unnecessary data redundancy.

The header field GROUP is a special field group for the sort CRITERIA. The system automatically PREFIXES any other field GROUPS with the header field group.

The header field group is a special field group for the sort criteria. The system automatically prefixes any other field groups with the header field group.

The RAISING EXCEPTION determines WHETHER the calling PROGRAM will handle the exception itself or leave the exception to the system.

The raising exception determines whether the calling program will handle the exception itself or leave the exception to the system.

NEW-PAGE PRINT ON.

NEW-PAGE PRINT ON.

YES. PARAMETERS <p>……..MATCHCODE OBJECT <obj>……

Yes. PARAMETERS <p>……..MATCHCODE OBJECT <obj>……

WRITE &LT;SYMBOL-name&GT;AS SYMBOL.
WRITE <ICON-name> AS ICON.

WRITE <symbol-name>AS SYMBOL.
WRITE <icon-name> AS ICON.

You can group any COMPLEX internal data OBJECTS of an ABAP/4 program together in data clusters and STORE them temporarily in ABAP/4 memory or for longer periods in databases. You can store data clusters in special databases of the ABAP/4 Dictionary. These databases are known as ABAP/4 cluster databases and have a predefined STRUCTURE. Storing a data cluster is specific to ABAP/4. Although you can also access cluster databases using SQL statements, only ABAP/4 statements are able to decode the structure of the stored data cluster.

You can group any complex internal data objects of an ABAP/4 program together in data clusters and store them temporarily in ABAP/4 memory or for longer periods in databases. You can store data clusters in special databases of the ABAP/4 Dictionary. These databases are known as ABAP/4 cluster databases and have a predefined structure. Storing a data cluster is specific to ABAP/4. Although you can also access cluster databases using SQL statements, only ABAP/4 statements are able to decode the structure of the stored data cluster.

UPDATE or MODIFY.

UPDATE or MODIFY.

UPLOAD and WS_UPLOAD.

UPLOAD and WS_UPLOAD.

If the HIDDEN information is not sufficient to uniquely identify the selected line, the COMMAND GET CURSOR is used. The GET CURSOR command returns the NAME of the field at the cursor position in a field specified after the ADDITION field, and the value of the selected field in a field specified after value.

If the hidden information is not sufficient to uniquely identify the selected line, the command GET CURSOR is used. The GET CURSOR command returns the name of the field at the cursor position in a field specified after the addition field, and the value of the selected field in a field specified after value.

PBO- PROCESS Before Output-It DETERMINES the flow logic before displaying the screen.
PAI-Process After Input-It determines the flowlogic after the display of the screen and after receiving inputs from the USER.

PBO- Process Before Output-It determines the flow logic before displaying the screen.
PAI-Process After Input-It determines the flowlogic after the display of the screen and after receiving inputs from the User.

Each dynpro refers to EXACTLY one ABAP/4 dialog program.Such a dialog program is ALSO called a module pool ,since it CONSISTS on INTERACTIVE modules.

Each dynpro refers to exactly one ABAP/4 dialog program.Such a dialog program is also called a module pool ,since it consists on interactive modules.

We cannot write field data to the screen using the WRITE statement.The SYSTEM instead transfers data by COMPARING screen fields names with ABAP/4 VARIABLE names.If both names are the same,it transfers screen fields VALUES to ABAP/4 programs fields and VICE Versa.This happens immediately after displaying the screen.

We cannot write field data to the screen using the WRITE statement.The system instead transfers data by comparing screen fields names with ABAP/4 variable names.If both names are the same,it transfers screen fields values to ABAP/4 programs fields and Vice Versa.This happens immediately after displaying the screen.

A transaction is a collection OS screens and ABAP/4 routines, controlled and executed by a DIALOG processor. The Dilaog processor processes screen after the screen, thereby triggering the appropriate ABAP/4 processing of each screen. For each screen, the system EXECUTES the flow logic that contains the corresponding ABAP/4 processing. The controls PASSES from screen flow logic to ABAP/4 code and back.

A transaction is a collection os screens and ABAP/4 routines, controlled and executed by a Dialog processor. The Dilaog processor processes screen after the screen, thereby triggering the appropriate ABAP/4 processing of each screen. For each screen, the system executes the flow logic that contains the corresponding ABAP/4 processing. The controls passes from screen flow logic to ABAP/4 code and back.

- When the User SELECTS a function in a transaction ,the system copies the function CODE into a specially designated work field called OK_CODE.This field is Global in ABAP/4 Module Pool.The OK_CODE can then be evaluated in the corresponding PAI module. The function code is ALWAYS PASSED in Exactly the same way , regardless of Whether it comes from a screen’s pushbutton,a menu option ,function key or other GUI element.

- When the User selects a function in a transaction ,the system copies the function code into a specially designated work field called OK_CODE.This field is Global in ABAP/4 Module Pool.The OK_CODE can then be evaluated in the corresponding PAI module. The function code is always passed in Exactly the same way , regardless of Whether it comes from a screen’s pushbutton,a menu option ,function key or other GUI element.

The SET SCREEN and LEAVE SCREEN statements controls screen FLOW.

The SET SCREEN and LEAVE SCREEN statements controls screen flow.

By SY-UCOMM VARIABLE.

By SY-UCOMM Variable.

The FIELD and CHAIN FLOW LOGIC STATEMENTS LET you Program Your own checks.FIELD and CHAIN tell the system Which fields you are checking and Whether the System should Perform Checks in the flow logic or call an ABAP/4 MODULE.

The FIELD and CHAIN flow logic statements let you Program Your own checks.FIELD and CHAIN tell the system Which fields you are checking and Whether the System should Perform Checks in the flow logic or call an ABAP/4 Module.

- ON INPUT
The ABAP/4 module is called only if a field contains the Value other than the INITIAL Value.This initial Value is determined by the filed’s Dta Type: blanks for character Fields ,Zeroes for numerics. If the USER changes the Fields Value back t o its initial value,ON INPUT does not TRIGGER a CALL.

- ON INPUT
The ABAP/4 module is called only if a field contains the Value other than the initial Value.This initial Value is determined by the filed’s Dta Type: blanks for character Fields ,Zeroes for numerics. If the user changes the Fields Value back t o its initial value,ON INPUT does not trigger a call.

- ON REQUEST: The ABAP/4 Module is called only if the user has entered the value in the field value since the last SCREEN display .The Value counts as changed Even if the User simply types in the value that was ALREADY there .In general ,the ON REQUEST condition is TRIGGERED through any FORM of” MANUAL INPUT’.

- ON REQUEST: The ABAP/4 Module is called only if the user has entered the value in the field value since the last screen display .The Value counts as changed Even if the User simply types in the value that was already there .In general ,the ON REQUEST condition is triggered through any Form of” MANUAL INPUT’.

ON *-INPUT
- The ABAP/4 MODULE is CALLED if the user has entered the "*" in the first character of the field, and the field has the attribute *-entry in the SCREEN Painter.You can use this option in Exceptionla cases where you want to check only FIELDS with certain Kinds of Input.

ON *-INPUT
- The ABAP/4 module is called if the user has entered the "*" in the first character of the field, and the field has the attribute *-entry in the screen Painter.You can use this option in Exceptionla cases where you want to check only fields with certain Kinds of Input.

To Use AT EXIT – COMMAND ,We must assign a FUNCTION Type "E" to the relevant function in the MENU PAINTER OR SCREEN Painter .

To Use AT EXIT – COMMAND ,We must assign a function Type "E" to the relevant function in the MENU Painter OR Screen Painter .

- There are 5 types of message types AVAILABLE.
- E: ERROR.
- W-WARNING.
- I –INFORMATION.
- A-ABNORMAL TERMINATION.
- S-SUCCESS.

- There are 5 types of message types available.
- E: ERROR.
- W-WARNING.
- I –INFORMATION.
- A-ABNORMAL TERMINATION.
- S-SUCCESS.

- With SET SCREEN the current screen simply specifies the next screen in the chain , control branches to this next screen as sonn as th e current screen has been processed .Return from next screen to current screen is not AUTOMATIC .It does not interrupt processing of the current screen.If we want to branch to the next screen without finishing the current one, use LEAVE SCREEN.

- With CALL SCREEN , the current (calling) chain is suspended , and a next screen (screen chain) is called .The called can then return to the suspended chain with the statement LEAVE SCREEN TO SCREEN 0 .Sometime we might want to let an user call a POP up screen from the main application screen to let him enter secondary information.After they have completed their enteries, the users should be able to close the popup and return DIRECTLY to the place where they LEFT off in the main screen.Here comes CALL SCREEN into picture .This statement lets us insert such a sequence intp the current one.

- With SET SCREEN the current screen simply specifies the next screen in the chain , control branches to this next screen as sonn as th e current screen has been processed .Return from next screen to current screen is not automatic .It does not interrupt processing of the current screen.If we want to branch to the next screen without finishing the current one, use LEAVE SCREEN.

- With CALL SCREEN , the current (calling) chain is suspended , and a next screen (screen chain) is called .The called can then return to the suspended chain with the statement LEAVE SCREEN TO SCREEN 0 .Sometime we might want to let an user call a pop up screen from the main application screen to let him enter secondary information.After they have completed their enteries, the users should be able to close the popup and return directly to the place where they left off in the main screen.Here comes CALL SCREEN into picture .This statement lets us insert such a sequence intp the current one.

Yes.

Yes.

CALL SCREEN &LT;screen number.>.
STARTING AT <start column><start line>.
ENDING AT <END column> <end line>.

CALL SCREEN <screen number.>.
STARTING AT <start column><start line>.
ENDING AT <end column> <end line>.

NUMBER of the CURRENT SCREEN.

Number of the current screen.

A DIALOG Module is a callable SEQUENCE of screens that does not BELONG to a particular transaction.Dialog modules have their module pools , and can be called by any transaction.

A dialog Module is a callable sequence of screens that does not belong to a particular transaction.Dialog modules have their module pools , and can be called by any transaction.

NINE.

NINE.

If we use SET SCREEN without LEAVE SCREEN, the program finishes PROCESSING for the current screen before branching to <scr no>. If we use LEAVE SCREEN without a SET SCREEN before it, the current screen PROCESS will be terminated and branch directly to the screen specified as the DEFAULT next-screen in the screen attributes.

If we use SET SCREEN without LEAVE SCREEN, the program finishes processing for the current screen before branching to <scr no>. If we use LEAVE SCREEN without a SET SCREEN before it, the current screen process will be terminated and branch directly to the screen specified as the default next-screen in the screen attributes.

In "calling mode", the special screen NUMBER 0 (LEAVE TO SCREEN 0) causes the SYSTEM to JUMP back to the previous call level. That is, if you have called a screen SEQUENCE with CALL SCREEN leaving to screen 0 terminates the sequence and returns to the calling screen. If you have not called a screen sequence, LEAVE TO SCREEN 0 terminates the transaction.

In "calling mode", the special screen number 0 (LEAVE TO SCREEN 0) causes the system to jump back to the previous call level. That is, if you have called a screen sequence with CALL SCREEN leaving to screen 0 terminates the sequence and returns to the calling screen. If you have not called a screen sequence, LEAVE TO SCREEN 0 terminates the transaction.

Suppressing of ENTIRE screens is possible with this COMMAND. This command ALLOWS us to perform screen processing "in the background". Suppresing screens is useful when we are branching to list-mode from a TRANSACTION dialog STEP.

Suppressing of entire screens is possible with this command. This command allows us to perform screen processing "in the background". Suppresing screens is useful when we are branching to list-mode from a transaction dialog step.

At runtime, attributes for each SCREEN field are stored in the memory table called 'SCREEN'. We need not declare this table in our program. The SYSTEM MAINTAINS the table for US internally and updates it with EVERY screen change.

At runtime, attributes for each screen field are stored in the memory table called 'SCREEN'. We need not declare this table in our program. The system maintains the table for us internally and updates it with every screen change.

If the same attribute NEED to be changed for SEVERAL fields at the same TIME these fields can be grouped together. We can specify up to four modification groups for each field.

If the same attribute need to be changed for several fields at the same time these fields can be grouped together. We can specify up to four modification groups for each field.

Input, OUTPUT, MANDATORY, Active, HIGHLIGHTED, Invisible.

Input, Output, Mandatory, Active, Highlighted, Invisible.

SCREEN group is a field in the Screen Attributes of a screen. Here we can define a string of up to four characters which is AVAILABLE at the screen RUNTIME in the SY-DNGR field. Rather than maintaining field SELECTION separately for each screen of a program, we can combine logically associated screens together in a screen group.

Screen group is a field in the Screen Attributes of a screen. Here we can define a string of up to four characters which is available at the screen runtime in the SY-DNGR field. Rather than maintaining field selection separately for each screen of a program, we can combine logically associated screens together in a screen group.

SUBSCREENS have several restrictions. They cannot:
• Set their own GUI status
• Have a named OK CODE
• Call another SCREEN
• CONTAIN an AT EXIT-COMMAND module
• Support positioning of the cursor.

Subscreens have several restrictions. They cannot:
• Set their own GUI status
• Have a named OK code
• Call another screen
• Contain an AT EXIT-COMMAND module
• Support positioning of the cursor.

ABAP/4 OFFERS two mechanisms for displaying and USING table DATA in a screen. These mechanisms are TABLE CONTROLS and STEP LOOPS.

ABAP/4 offers two mechanisms for displaying and using table data in a screen. These mechanisms are TABLE CONTROLS and STEP LOOPS.

TABLE CONTROLS are simply enhanced STEP LOOPS that display with the look and feel of a table widget in a desktop application. But from a programming standpoint, TABLE CONTROLS and STEP LOOPS are almost exactly the same. One MAJOR difference between STEP LOOPS and TABLE CONTROLS is in STEP LOOPS their table rows can span more than one time on the screen. By contrast the rows in a TABLE CONTROLS are ALWAYS single lines, but can be very long. (Table control rows are scrollable). The structure of table control is DIFFERENT from step loops. A step loop, as a screen object, is simply a series of FIELD rows that APPEAR as a repeating block. A table control, as a screen object consists of:

1. table fields (displayed in the screen).
2. a control structure that governs the table display and what the user can do with it.

TABLE CONTROLS are simply enhanced STEP LOOPS that display with the look and feel of a table widget in a desktop application. But from a programming standpoint, TABLE CONTROLS and STEP LOOPS are almost exactly the same. One major difference between STEP LOOPS and TABLE CONTROLS is in STEP LOOPS their table rows can span more than one time on the screen. By contrast the rows in a TABLE CONTROLS are always single lines, but can be very long. (Table control rows are scrollable). The structure of table control is different from step loops. A step loop, as a screen object, is simply a series of field rows that appear as a repeating block. A table control, as a screen object consists of:

FIELD, MODULE, SELECT, VALUES and CHAIN are the dynapro KEYWORDS.

FIELD, MODULE, SELECT, VALUES and CHAIN are the dynapro keywords.

We NEED to code a LOOP STATEMENT in both PBO and PAI events for each table in the screen. This is because the LOOP statement CAUSES the screen fields to be copied back and forth between the ABAP/4 program and the screen FIELD. For this reason, at least an empty LOOP….ENDLOOP must be there.

We need to code a LOOP statement in both PBO and PAI events for each table in the screen. This is because the LOOP statement causes the screen fields to be copied back and forth between the ABAP/4 program and the screen field. For this reason, at least an empty LOOP….ENDLOOP must be there.

Using the syntax CONTROLS <table CONTROL name&GT; type tableview using SCREEN <SCR no>.

Using the syntax controls <table control name> type tableview using screen <scr no>.

Step loops fall into TWO classes: STATIC and Dynamic. Static step loops have a fixed size that cannot be changed at RUNTIME. Dynamic step loops are VARIABLE in size. If the user re-sizes the window the system AUTOMATICALLY increases or decreases the number of step loop blocks displayed. In any given screen you can define any number of static step loops but only a single dynamic one.

Step loops fall into two classes: Static and Dynamic. Static step loops have a fixed size that cannot be changed at runtime. Dynamic step loops are variable in size. If the user re-sizes the window the system automatically increases or decreases the number of step loop blocks displayed. In any given screen you can define any number of static step loops but only a single dynamic one.

By SUBMITTING a SEPARATE REPORT.
By USING LEAVE to list-processing.

By submitting a separate report.
By using leave to list-processing.