TRANSACTIONS
GENERAL INTRODUCTION TO TRANSACTION
Transaction,
in R/3 system is an operation that lets the user make necessary changes to the
database. The entire R/3 system is nothing but set of business transaction. The
data transfer from old system to SAP R/3 database, or modifying data, or
deleting data, which is not required, is done through transaction.
For SAP
system, Transaction is nothing but sequence of steps called as dialog steps and
for user it is sequence of screens that appears one after the other depending
upon the option he selects. The special transaction monitor called the SAP
dispatcher handles the sequence of steps that takes place in any transaction.
The main task of transaction is to update database table. The database table is
not updated until a transaction is completed. All changes can be rolled back if
the transaction has not finished.
The
transaction contains two steps which are as following:
·
Interactive phase: In this step, user
enters the data, which needs to be inserted or deleted or modified on to the
screen. There can be single screen or multiple screens depending upon the
transaction. So this step can consist of single step or multiple steps. In this phase you prepare database record.
·
Update phase: This phase processes the
database record and updates the database table. Actual updating of database
table takes place in this phase.
All the
transactions are associated with transaction code. And all these codes are
stored in a table TSTC.
Logical Unit of Work (LUW)
·
Database transaction known as LUW. It can be defined as a period in which
operation requested must be performed as a unit, i.e. all or nothing
operation. At the end of LUW, either of
the database changes are committed or rolled back.
·
Update transaction or SAP LUW. One SAP LUW can have several databases LUW.
So a set of a database is either committed or rolled back. The special ABAP/4
command COMMIT WORK, marks the end of a SAP LUW.
·
ABAP/4 transaction. Is made up of a set of
related task combined under one transaction code. ABAP/4 transactions are for
programming environment, in which ABAP/4 transaction functions like one
complete object containing screens, menus and transaction codes.
R/3 system has
provided in built locking mechanism, which defines the Logical Unit of Work.
Also user can set his own locking mechanism. The LUW starts when a lock entry
in the system table is created, and it ends when the lock is released.
To provide the
user the facility to communicate with the table in order to modify or delete or
insert data, R/3 has provided tool called SCREEN PAINTER. This tool allows you
to design screen, process screen through program and update the database
table. SAP has provided one and only one
way to update the database table, i.e. transaction. Though you can update database table by using
open SQL statement through program, SAP usually doesn’t recommend this kind of
updating. Many standard transactions are
available to update standard table but if the need arises, the developer should
be able to develop new transaction, which allows the updating of database
tables. This can be achieved by using various components of screen painter.
Following are
the few concepts and steps for creating entire new transaction.
Dynpro
concept
Dynpro, as figure indicates
consist of screen and flow logic and places exactly one call to module pool
program. A transaction consists of many screens and for each screen flow logic
is attached. When the transaction is executed, the screen places a call to flow
logic and flow logic in turn places a call to module pool program.
·
A module program is usual ABAP/4 program that
consist of modules and data declaration.
·
ABAP/4 is an event driven language. In module
pool program too, events get triggered and these events are handled in flow
logic. Flow logic editor is subset of ABAP/4 editor. The system automatically
displays the two important events for the flow logic.
·
Screen is the important component of dynpro and
can be created, designed by screen painter.
Screen Painter
A screen painter can be started
by
Development workbench à
Screen painter
Or
SE51 transaction code.
Using Screen painter
The process of creating a dynpro
includes the creation and definition of all the needed screen components.
The steps involved in creating
the dynpro are as follows:
·
Create screen and attributes by using screen
attribute screen.
·
Select and place the needed fields within the
screen by using dict/program fields.
·
Establish the field attributes to which the
screen belongs by using field list.
·
Define the flow logic respect to the transaction
to which it belongs by using flow logic.
Creating a new Screen
Steps involved are as follows:
·
Enter the name of program and number of the
screen
·
Click on Create
·
On “screen attribute” screen enter short
description
·
Enter screen type. Normally, you select NORMAL option for usual R/3 screen. Other options
available are SUBSCREEN & MODAL DIALOG BOX. Modal dialog box is used to
establish independent and interactive dialog box while subscreen is screen
within screen.
·
Next attribute to be passed is NEXT SCREEN. Here
you need to specify the next screen number, which must be processed after the
current one.
Designing of Screen
Screen can be designed by using
FULL SCREEN EDITOR. You can go to full screen editor.
From screen attribute screen
By pressing full screen editor
pushbutton
Or
From initial screen of screen
painter.
There are two modes available
with full screen editor.
·
Graphical mode. The graphical mode works
similarly to typical window application.
·
Alphanumeric mode (rarely used).
Elements of screen
·
Text – Standard text or field labels.
·
Entry -
display field.
·
Radiobutton – All radiobutton must be associated
with one group.
·
Checkbox – Normally used for YES/NO operations.
·
Pushbutton – Used for activating particular
function.
·
Boxes – grouping together many screen elements.
·
Subscreens – This is a screen area in which you
can display another screen.
·
Table controls – This area of screen is similar
to table but should be treated as a loop.
·
Status - Display output fields containing icon.
All these elements are on the
control bar of full screen editor and can be placed on the screen work area by
clicking and placing them wherever needed.
Selecting Screen fields
Screen field can be either
dictionary objects or program fields. Steps involved in the placing of fields
on the screen are as follows:
Click the pushbutton Dict/program
fields on the full screen editor
Or
Goto à
dict/prog fields.
·
Enter table name.
·
Click Get from dictionary.
·
Select fields.
·
Click copy pushbutton.
·
Position the cursor where you want those fields
to be placed.
To adjust various screen
elements, you can use drag and drop facility for screen elements.
Attributes of Screen Elements
The entire element of a screen
has some attributes, which determines their behavior.
·
General – These attributes are directly managed by
the screen painter like name of the element, or text of element or column width
and various things associated with the screen.
·
Dictionary – These attributes are applicable to
fields, which are from dictionary. Various components of dictionary can be attached
to this element like search help, foreign key.
·
Program.
·
Display – Behavior of the element with respect
to their display feature.
Attribute dialog box can be
displayed by
·
Clicking on the Attribute push button on the application tool bar.
·
Double clicking on the element.
Field List
This list
displays a list of all screen elements together with their screen
attributes. One important element of
Field list is OKCODE. Any pushbutton is associated with function code as in
menu item in menu painter. When the user clicks the pushbutton this code is
stored in OKCODE. This OKCODE is created by system without a name and is not
visible on the screen. In ABAP/4 this field is work field and is nothing but an
area wherein system stores the variable and is the last field of the field list
and is invisible, hence user needs to give the name OKCODE. It is not mandatory
to give the name OKCODE; developer can give any name to this field.
Screen Flow Logic
You can go to
this screen either by
Initial screen
of screen painter à
Flow logic
Or
From Screen
attribute screen à Flow logic
When
transaction is executed, the screen is displayed, user enters few fields,
selects few functions. Later the screen is processed and processing of screen
is done by flow logic. The events that
are associated with screen are as follows:
·
Process before Output (PBO)
·
Process after input (PAI)
·
Process on value request (POV)
·
Process on help request (POH)
The system
automatically displays two very important events or modules in flow logic i.e.
PAI and PBO
PBO event
This event is
triggered before the screen is displayed. The processing of screen before the
display of screen is done in this event. For example, filling in default values
in the screen fields.
PAI event
This event is
responsible for processing of screen after the user enters the data and clicks
the pushbutton. The processing of screen can include displaying another screen,
or just displaying list or quitting the transaction itself and many more
things. Usually it is displaying another screen. These operations can be
carried out in the PAI event. OKCODE plays an important role in this operation.
POV event
Process on
value request is triggered when the user clicks F4 key. You can handle this
event when the user presses F4 key by writing code for the same in module pool
program. Normally when the user presses F4, list of possible values is
displayed. The standard list produced by
system is adequate for applications you develop yourself. However, you can also have the option of
setting up your own documentation and lists of possible values that are more
detailed.
POH event
Normally when
the user places the cursor on the field and presses F1 function key, the system
displays its own Help for that particular field. You can add your own
functionality to the Help button by writing code for the same in the POH event.
Module Pool Programming
This component
though is not attached to the screen painter, plays important role in
transaction. Normally, for reports, on line executable programs are written but
for transaction, Module Pool Programs are written. The module pool program
contains only modules to handle various events associated with screen and data
declaration statements.
System divides
the module pool program into several include program. These are global field,
PBO modules, and PAI modules. It is entirely user’s decision whether to use
these modules or write directly into main program.
Creation of Module Pool Program
You can create
module pool program either through
Object browser
System
automatically creates the module pool program and for these program which are
created through object browser, system creates the include modules.
Or
ABAP/4 editor
It is similar
to normal program creation. Type of program should be given ‘M’ and is not
created by system.
Communication between Dynpro and Module Program
For each
screen, the system executes the flow logic, which contains corresponding
events. The control is passed to Module Pool Program. Module Pool Program
handles the code for these events and again passes back control to the flow
logic and finally to screen. Unlike on line program, in this case, the control
remains with flow logic. The switching of control between flow logic and module
pool program and back is common process when user executes transaction.
Creation of a Complete Transaction
Steps involved to create a complete transaction
·
Create module pool program.
·
From screen painter create screens.
·
Write flow logic for each screen.
·
Write code for all the events in module pool
program.
·
Check for any error in screen and flow logic.
·
Generate each and every component of screen i.e.
flow logic and screen.
·
Single screen can be tested using Screen
Painter.
·
Create transaction code through object browser.
·
Generate the transaction code.
·
User can execute the transaction by entering the
transaction code in the command field.
Handling Function Code
The function
code or OKCODE is the last field of Field list. Function code can be handled as
follows:
During the
Designing of the screen, a function code is assigned to pushbutton.
·
In field list, developer needs to specify OKCODE
as last field.
·
In module program it is a global field and can
be evaluated in the PAI event.
·
A function code is treated in the same way,
regardless it comes from pushbutton, menu item or any other GUI element.
A complete
example for transaction is shown below:
If you have a
screen like the one below:
When the user clicks on the
Display button, you want to display details of sflight, with corresponding carrid
and connid (which is entered by the user).
Module pool program to handle
this particular screen is as follows:
Program YVTEST7.
Tables:
SFlighT.
data:
okcode (4).
Module
input1 input,
case okcode.
when ‘disp’.
Select * from sflight
where carrid = sflight – carrid and
connid = sflight –
connid.
Endselect.
leave to screen 200.
When ‘exit’.
Leave to screen 0.
Endcase.
endmodule. “input1
input
module user_command_0200 input.
case okcode.
when ‘back’. Leave to screen 100.
endcase.
Endmodule. “user_command_0200
input
When the user clicks on display,
control is transferred to screen no. 200 on which you display sflight details
& on the same screen, when user clicks on BACK button, he comes back to
main screen.
Flow logic for screen 100 is as
follows:
Process
after input.
Module input.
Flow logic for screen 200
PROCESS AFTER
INPUT.
User_command_0200.
MODULES: modules are handled in module pool
program.
You need to
write flow logic for screen 200 and design screen 200.
In case of
transaction transfer of data from program to screen is automatic i.e. you need
not transfer the data from program to screen explicitly. The fields, which you
define in the screen receives the data from program and displays the same.
The Field Checks
As already
mentioned Transaction is the only method, which SAP recommends to update the
database tables. Data entered in the database table should be valid and
correct. Data entered is validated at each and every point. ABAP/4 offers
various methods to validate data and those are as follows:
·
Automatic field checks
·
Checks performed in the flow logic
·
Checks performed in the ABAP/4 module pool
program
Automatic Field Checks
These checks
are based on the field information stored in the dictionary. These checks are
performed by the system automatically when the user enters the data for the
screen field. System performs these checks before PAI event is triggered. Types
of field checks performed by system are as follows:
·
Required input
While
designing the screen, for particular screen field if you click the Req. Entry
checkbox, the field becomes mandatory. When the transaction is executed if user
leaves this particular field blank, the system displays error message. User
cannot proceed until the user enters some data.
·
Proper data
Format
Each field has
its own data format whether it is table field or screen field. Whenever data is
entered, system checks for the proper format of the data. For example date.
Each user has its own format for date, which is defined in the user master
record. If the date defined in the user master record is in the format
DD/MM/YYYY, if the user enters the date, say, in YY/DD/MM, the user displays
the error message. System also checks for the value of month or days. For
example if month entered is greater than twelve then the error message is
displayed.
·
Valid Value for the Field
In data
dictionary two tables are related by Primary key-Foreign key relationship. Whenever the user enters the data, the system
checks for the check table values. Also
in Domain, if you have fixed values, then the system checks for these values.
Automatic field checks are repeated each
time the user enters the data.
About at Exit – Command
Automatic
field checks can be avoided by AT EXIT-COMMAND, which works exactly the same
way as Cancel works on application tools bar. In the R/3 screen, if you want to
quit the processing of that particular screen without entering the mandatory
fields, user can click the Cancel button. Same functionality can be
incorporated in the user-defined transaction by using AT EXIT-COMMAND. This
module can be called before the system executes the automatic field checks and
it goes without saying that before PAI event. Code for AT EXIT-COMMAND in flow
logic and in module pool program can be written as follows:
In module pool program.
Module
exit.
Case
okcode.
When
‘Exit’.
Leave
to screen 0.
To achieve
this kind of functionality a pushbutton or menu item should be assigned a
function type ‘E’. It tells the system to process this particular module before
carrying out any field checks.
Flow Logic Validations
Consider the
case where you want user to enter only ‘LH’ and ‘SQ’ for sflight-carrid. In
this case, you are restricting value of a screen field. This cannot be achieved
by automatic field check. Hence there is a need of additional validation. It
can be done in flow logic by using following statement:
Field --------------- Values
Syntax
PAi.
Field
sflight-carrid values (‘LH’).
For multiple
values
PAI.
Field
sflight-carrid values (‘LH’ ‘SQ’).
Field
sflight-price values (between 1000 and 2000).
In this case
when the user enters the value, PAI is triggered and field is checked for that particular value. If the value entered
happens to be wrong, that field is enabled for user to enter. If you have
multiple Field statements in your flow logic, it is sequential execution.
Consider the
following case:
PAI.
Module assign.
Field
sflight-carrid values (‘LH’ ‘SQ’).
In ABAP/4
Module assign.
Data: carrid1
like sflight-carrid.
Carrid1 =
sflight-carrid.
Endmodule.
In this case,
Sflight-carrid is used in the flow logic before the field statement. The system
will give invalid value or some previous value as the field sflight-carrid is
used in module before it is checked i.e., field statement is after the module
in which sflight-carrid is being used. The
field is not available to the system unless it executes the field statement.
Field statement transfers the values to the program and is done only once. If
you don’t have Field statement in your flow logic, transfer of values takes
place in PAI event.
Consider one
more case where you have multiple field statement.
PAI.
Field
Sflight-carrid values (‘LH’).
Field
Sflight-connid values (‘0400’ ‘0500’).
In this case
if the user enters only carrid wrong, then this particular field is enabled and
rest of the fields are disabled for user to input. Many times if the user
enters wrong value for one field, then you might want to give option to user to
enter all the fields, which is not possible by using Field statement only. This
functionality can be achieved by Chain –
endchain.
Syntax
Chain.
Field
sflight-carrid value (‘LH’).
Field sflight-connid values (between
‘200’ and ‘500’).
Endchain.
Field
sflight-price values (‘100’ ‘1000’).
In this case,
if the user enters wrong value only for carrid, both the fields i.e. carrid and
connid are enabled as they are grouped together in the Chain statement. The
field price will be disabled for input. Usually, logically related fields are
grouped together with Chain-Endchain statement.
Module Pool Program Validations
Checking
fields ABAP/4 program includes
·
Field statement in flow logic.
·
Module statement in ABAP/4 module pool Program.
Syntax
PAI.
Field
sflight-carrid module <name>.
This module
can be handled in the main program i.e. module pool program.
In ABAP/4
program
Module Check.
Select single
* from sflight where carrid = sflight-carrid.
If sy-subrc ne
0.
Message e001.
Endif.
In this case,
field sflight-carrid is checked in the table for its existence.
Dynamically Calling the Screens
About Displaying Next Screen
Transaction is
a sequence of screens, which are displayed one after the other. The next screen
displayed depends upon the attributes of first screen. In attributes you need
to give Next Screen number i.e. if next screen displayed should be 200 screen,
then this number should be given in next Screen attributes. These are static
attributes of the screen. By default, if nothing is specified in the program,
the system branches out to the screen number, which is specified in the
attribute screen.
But this
doesn’t happen always. If you have many pushbuttons on the screen like the one
in the following case:
In this case, if user selects
MARA pushbutton, then fields from Mara table are displayed. When the user
clicks on the MARD, then the fields from MARD table are displayed. Depending
upon users selection, the screen is branched out and this has to be done during
runtime. This functionality can be achieved by dynamically calling the screen
in module pool program.
The screen can
branch out to new screen depending upon user selection. Following command in
module pool program can do this:
·
Set
Screem
·
Call
Screen
·
Leave to
screen <number>
All these commands override the
specifications given in the attributes. This overriding is temporary. The
values stored in the attribute are not changed.
Set Screen
Syntax
Set screen
<number>.
In module pool
program
Case okcode.
When
‘Disp’.
Set screen 200.
When ‘List’.
Set screen 300.
Endcase.
In this case,
the entire processing of current screen takes place and then the system
branches out to next screen. If you want to branch out to the next screen
without processing the current screen, LEAVE SCREEN should be used along with
the set screen.
For
Example:
Case okcode..
When
‘Disp’.
Set screen 200.
Leave Screen.
When ‘List’.
Set screen 300.
Leave Screen.
Endcase.
When SET SCREEN is used, control cannot be
transferred to the main screen or previous screen, unless you write code for
the same.
Call Screen
Usually used
for pop up screens. Many times, there is a need for user to enter additional
information or secondary information on another screen or pop up screen. Once
the user enters the data, he should be able to go back to main screen or to the
screen where he started. This is not possible by using SET SCREEN. CALL SCREEN
achieves this functionality.
Syntax
Call Screen 200.
Will simply
call a screen number 200 from a main screen. Once the screen is displayed the
user can enter all the data and return to the main screen by clicking back button.
To call screen
as pop up screen the syntax is
Call
screen starting at <col.no.> <line no>
Ending at <col no> <line no>.
In this case
window will be popped as window and user can close it by using back button.
Leave to screen
To SET a new
screen without processing current screen, you need to use the following two
statements together:
SET Screen 200.
Leave Screen.
Or a Single
statement
Leave to screen 200.
Subscreens
A subscreen is
a screen within screen. Consider the following case.
If user clicks
on First pushbutton, you want to
display details of MARA table and if user clicks on the second pushbutton, you want to display details of mard table. You can do this by calling two different
screens. But the information will be displayed on the next screen. Displaying
data on the same screen is possible by using Subscreens.
Step to create
a subscreen are as follows:
·
Create a subscreen area on main screen and name it.
·
Create a separate screen of subscreen type.
·
Arrange the fields on this screen so that they
fit in subscreen area exactly. Only when it is larger, the part of the screen
that fits in the main area will be visible.
·
Write code for calling subscreen in flow logic.
To call
subscreen, from your flow logic, you need to include the statement both in PAI
and PBO.
Syntax
PBO.
Call
subscreen <area> including <prg name> <’screen no’>.
PAI.
Call subscreen
<area>.
Area - is the
name of the area on main screen.
Prg. Name - is
the name of the module pool program.
Screen number
- is subscreen screen number.
Some of the
don’ts with subscreen are:
GUI status cannot
be set to the subscreen
·
OKCODE is not applicable to the subscreen.
·
Subscreen cannot call another screen.
·
It cannot contain at Exit-Command.
You can call
multiple subscreen in the same area (at any given point of time, only one
subscreen can be called in the subscreen area) and is done dynamically during
runtime by using variable screen number.
Table Controls
A table can be
created in transaction. These tables when designed on the screen are called as Screen Tables. These screen tables are
of two types viz.
·
Table controls
·
Step loops
Though these
are tables when code is written to handle them, the tables are treated as loops.
Features of Table Controls
·
Data is displayed in the form of table when many
records match the criteria.
·
Table control gives user the feeling of an
actual table.
·
You can scroll through the table vertically and
horizontally.
·
You can select rows and columns
·
Resize the width of a column
·
You can have separator lines in between rows and
columns
·
Automatic resizing of the table when the user
resizes the window.
In general
table control includes all the features of an actual table and user gets the
feeling that he is actually working with table. You can update information in
table control and it can be updated in the database table by writing code for
it.
Steps
associated for creating complete screen table are as follows:
·
Declaration of table control in module pool
program.
·
Designing of table control on the screen.
·
Passing data to table in flow logic.
Declaring of Table Control in the Module Pool Program
Syntax
Controls
TCI type Tableview using screen <screen no.>
When you use
table control in a screen you must declare the structure in module pool
program. Important fields of tableview are as follows:
·
Lines – number of displayable rows in a table.
·
Top_line – the row of table where the screen
displays start.
·
Current_line – The row currently being processed
inside a loop.
When you
process the table control in flow logic depending upon where you want to start
display of rows, you need to use these variables.
Designing Table Control on Screen
·
To design table control on the screen, you need
to click on Table in control bar and place it on the screen. You can adjust the
length and width of table control.
·
Name the table control. (Here you need to use
same name which you have used for declaration of table control in module pool
program)
·
From dictionary object, select table fields and
place them in the table control.
Passing data to table Control
As already
mentioned, table controls are tables but are treated like loops. Usually
transfer of data from program to screen is automatic. But in case of table
control, transfer of data is not automatic. You need to explicitly transfer the
data to table control. ABAP/4 provides loop statement, which is associated with
flow logic to transfer the data. Because table control is treated like a loop,
data from where it is transferred should be a loop. You cannot transfer the
data by only select statement; you need to put the data into internal table.
ABAP/4 provides the LOOP statement, which is
associated with the flow logic and allows you to loop through the table control
and internal tables. In between LOOP-ENDLOOP, you can use most of the flow
logic keywords like field values. Module
etc.
You need to
code a LOOP statement in both PBO and PAI
event of the screen. With LOOP statement, you
can transfer the data from program to table control and vice versa. That is, if user updates the value in the
table control, you can update database table with its value. And this can be
done in PAI event. So even if you are not updating database table through the
table control, you need to put the LOOP
statement in the PAI event also.
Syntax
PBO.
Loop at <internal table> with control <table
control name> cursor <scroll variable>
PAI.
Loop
at itab.
Proper usage
of Table Control is as follows:
In flow logic.
 |
PBO.
LOOP at iTAB with control
Tc1 cursor tc1-top_line.
Module assign.
Endloop.
Pai.
loop at itab.
endloop.
Considering,
we have following fields in table control and the screen looks like this:
In module pool
program
 |
Control TC1 type tableview using screen
200.
Module assign.
Sflight – carrid = itab – carrid.
Sflight
- connid= itab - connid.
Sflight
- fldate= itab – fldate.
Endmodule.
The transfer
of the data from program to table control takes place in steps and these steps
are as follows:
·
With LOOP AT statement the first row is picked
up and placed in the header of the internal table.
·
Whatever statements you have in between
LOOP-ENDLOOP are executed. In this case,
you have Module statement. In Module statement, value of internal table is
assigned to table control field.
·
The row in internal table is transferred to the
first line of the table control as stated in the LOOP
AT statement.
·
The system encounters the ENDLOOP statement and
Control is passed to the next line of the internal table.
·
In the same way, all the records of the internal
table are passed to the table control.
STEP LOOPS
Step Loops are
type of screen table as already mentioned. Step loops are repeated blocks of
field in a screen. Each block contains one or more fields and these blocks are
repeated. Step loops aren’t like actual table. You can scroll vertically but
not horizontally. Three steps are associated with creation of step loops:
·
Creation of step loops on screen, which includes
declaring fields on the screen and then defining the step, loops for these
fields.
·
Passing data to the step loop is exactly similar
to the passing of data to table controls.
·
In step loop, you don’t need to define the step
loop as such in the module pool program but the cursor needs to be defined in
the program.
Types of Step Loops
·
Static – Static Step Loop (SSL) have fixed size
that cannot be changed during the runtime. If user resizes the window, the size
of the static step loop is not changed.
·
Dynamic – Dynamic Step Loop (DSL) is variable in
size. When the user resizes the window, the system increases or decreases the
number of the step loop blocks.
You can have
only one dynamic step loop and can have as many static loops in your transaction.
Programming
with the Static and dynamic step loop is exactly same. For the system or for the user it doesn’t
make any difference whether it is static or dynamic step loop. Only attribute, which you fix during
designing of the step loop, is type attribute for step loop F for fixed i.e
static and V for variable i.e. dynamic.
Writing code
for Step Loop in the flow logic.
PBO.
Loop
at itab cursor cl.
Module set.
Endloop.
PAI.
Loop
at itab.
Endloop.
* Empty
loop is must for both table control and step loop
LOOP AT statement for step loops and Table controls is similar. Loop At statement transfers the data to screen table. You
need to have the Module to assign the values for the screen table.
In module pool program you need
to define the cursor.
Date: CL TYPE
i.
* Cursor
parameter tells which line of step loop display should start.
“Module Set” in module pool
program assigns the values to step loop fields, which is similar to table controls.
Branching to List Processing
Switching To List Mode
You can display a list within a transaction.
You can produce a list from
module pool program by using the command
Leave to List-Processing.
This statement switches the
system from dialog mode to list mode. And from this point onwards until you
return to dialog mode, you can use all the normal report statement like write,
select or any other event.
Returning back from LIST mode
You can return back to dialog
mode by clicking the BACK button.
You can have your GUI status and write code for the same. You can
include the command LEAVE LIST-PROCESSING. When the system reaches this
command, it leaves the list mode and returns to the dialog mode.
Help & Value Request
In
any transaction, When the user presses F1 or ? on a field, System provides the
help facility for that particular field.
In dialog program, when F1 is pressed, help provided by R3 system is sourced
from data element documentation. If this documentation is not present for that
particular field or if user needs to display additional information for that
particular field, then user defined help can be provided through PROCESS ON
HELP REQUEST.
In ABVP/4 help can be provided to
the user by:
Data element documentation: The
F1 help can be enhanced, by adding an additional text for the data element in
ABAP/4 dictionary.
It can be done with the help of
following steps:
Place cursor on the screen field,
GOTO à DOCUMENTATION à
DATA ELEMENT DOCUMENT
You can now extend the existing
help.
USING THE PROCESS ON
HELP-REQUEST.
If you don’t have this event in a
program, then the documentation of the field in the ABAP/4 dictionary is taken
into consideration. If this event exits in the program then it is executed.
Process on HELP-REQUEST event
This event is triggered when user
presses F1 on a screen field. You need to handle this event in flow-logic by
specifying the fields and attaching the module to it.
Syntax
PROCESS ON HELP –REQUEST.
FIELD SFLIGHT-CARRID MODULE
HELP-FOR-CARRID.
In module pool program
MODULE HELP.
Write : `This is field is from sflight table’
Write : /
‘It is of four Character’.
ENDMODULE.
When the user presses F1 on this
particular field, then this message will be displayed on the screen.
Value Request
Whenever the
user presses F4 on the screen field list of possible values, particular fields
are displayed. If the standard value-help is inadequate or if you want to
display additional fields or with different combination of fields, developer
can program this in PROCESS ON VALUE-REQUEST event in the flow-logic and
subsequent module in the module pool program. When the user presses F4, list of
possible values are displayed either from matchcode objects or check table or
help view or domain. Each one of them is explained briefly.
Matchcode objects: Are
aggregated dictionary objects and detailed procedure to create these objects is
explained in the later part of the material.
Check Table: If a check table is assigned to the table
field and if the user presses F4 for that particular field, then all the key
fields are displayed.
Domain Values: The values defined
in the domain are displayed. These values are set in domain when the domain is
created in the dictionary.
Help views: In cases where the check table is not sufficient,
you can create a help view with this check table, which gives additional
information like explanatory text for the fields of the check table.
PROCESS ON VALUE_REQUEST.
Each time the user presses F4 on
the screen field, following algorithm is called internally.
When the user presses F4 on flight number, the following
screen is displayed.
Flow-logic code
PROCESS ON VALUE-REQUEST.
FIELD
SFLIGHT-CONNID MODULE HELP-FOR-CONNID.
Code for module pool program.
MODULE HELP-FOR-CONNIDINPUT.
DATA: BEGIN OF ITAB OCCURS 0,
CONNID(50),
END OF ITAB.
REFRESH ITAB.
ITAB-CONNIDI= POSSIBLE VALUES FOR
CONNECTION ID’.
APPEND ITAB.
SELECT CONNID FROM SFLIGHT INTO
TABLE ITAB.
CALL FUNCTION
‘POPUP_WITH_TABLE_DISPLAY’
EXPORTING
ENDPOS_COL = 45
ENDPOS_ROW = 25
STARTPOS_COL = 10
STARTPOS_ROW = 1
TITLETEXT =
‘TEXT’
IMPORTING
CHOISE = Some Integer Variable
TABLES
VALUETAB = ITAB
EXCEPTIONS
BREAK_OFF =1
OTHERS =2.
ENDMODULE.
“HELP-FOR-CONNID INPUT
Changing The Screen During
Runtime
The attributes are assigned to the screen field when the screen is
designed in full screen editor. Such
kind of assignment is static, which means that these attributes are fixed. But
many times the need to change the attributes of the screen arises. And this has
to be done during runtime.
Need To Change Screen
There can be a requirement in the
transaction that, certain fields on the screen
Appear only in certain
conditions.
Are in Change/display mode
according to user inputs
Become mandatory subject to
specific inputs.
Changes its format depending upon
certain conditions.
Modifying the screen
At the runtime, attributes for each screen field is stored in system
defined internal table, with header line, called as SCREEN TABLE. It contains
name of field and its attributes. This tab le can be modified during the runtime
i.e. through module pool program. Screen table has following fields:
Field Name Length Description
NAME 30 Name of screen field
GROUP1 3 Field
belongs to field group1
GROUP2 3 Group
2
GROUP3 3 Group
3
GROUP4 3 Group
4
ACTIVE 1 Hide/Show
REQUIRED 1 Field
input is mandatory
INPUT 1 Enable/Disable
OUTPUT 1 Field
for display only
INTENSIFIED 1 Field
is highlighted.
INVISIBLE 1 Field
is suppressed.
LENGTH 1 Field
output length is reduced
DISPLAY 3D 1 Field
is displayed with 3-D Frame
VALUE_HELP 1 Field is displayed with
Value help
E.g., SCREEN-ACTIVE = 0
has the same effect as the following statements.
SCREEN- INPUT = 0.
SCREEN-OUTPUT = 0.
SCREEN-INVISIBLE = 1.
The fields SCREEN-NAME and
SCREEN-GROUP 1 through SCREEN-GROUP4 tell you which field and / or field group
has the attributes.
You can assign up to 4 groups to
a field.
You need to program screen
modifications in module, which is processed during the event PROCESS BEFORE
OUTPUT.
`SCREEN’ is an internal table and, in order to change the field values,
LOOP statement has to be used so that the header-line can be populated with the
new values, changing the earlier values, the SCREEN table consisted for the
specific screen. Finally the changed record in the header-line is NOT APPENDED,
but is MODIFIED to the SCREEN table. That is, we first use `LOOP AT SCREEN’ and
then assign the values. And finally PRIOR TO ENDLOPP give `MODIFY SCREEN’.
PROCESS BEFORE OUTPUT.
MODULE MODIFY_SCREEN OUTPUT.
MODULE MODIFY_SCREEN.
LOOP AT SCREEN.
IF SCREEN-NAME =
‘SFLIGHT-CARRID’.
SCREEN-INPUT =
1.
MODIFY SCREEN.
ENDIF.
ENDLOOP.
ENDMODULE.
Working with Matchcode
Objects
A Matchcode is
an aggregated object and it gives list of possible values for the user. A
matchcode is a collection of search terms on which you retrieve a data from the
database table.
All matchcode are associated with either selection criteria or
parameters. When an input field has a little triangle in the right-hand corner,
it indicates that it has an associated matchcode. When you click on drop-down
arrow or press F4 button, it gives a list of all possible values. For example
Matnr field i.e. material number from MARA table, user might not know all the
material number, but they might know other details like material description,
type or any other details. You can create matchcode, which has all these search
terms i.e. you can create matchcode with description as search term or
matchcode with type as search term.
R/3 system
includes many predefined matchcode but developers can create new matchcode as
is created in following case. Usually, system displays list of possible values
for all the primary keys with particular search term. Usually you create
matchcode in following cases:
When you use non-primary key of
input.
You need different search term
for the primary key.
Creating Matchcode object
Entire Matchcode object is
created in two steps:
Defining of Matchcode object.
Defining one or more search ids
for the object.
Defining Matchcode object
It includes all the tables and
fields, which make up the Matchcode, which are used for Matchcode Ids.
Steps for defining Matchcode
object are as follows:
From dictionary, enter name (four
character).
Select Matchcode radiobutton and
click on CREATE.
Define attributes for the object
i.e. description.
Select primary table.
Select the fields for the table
by clicking on the fields.
Activate the object.
If at all you are selecting
secondary table then it is done after selecting primary table.
And steps are as follows:
Tables à Choose secondary
table. A dialog box appears, which displays list of possible secondary tales.
Select the table by Choose à
copy.
To activate the object, Matchcode object -à activate
Creating Matchcode ids.
Once the object is created, you
need to define search term for the object and steps are as follows:
Click on the Matchcode ID from
maintenance screen.
Enter attributes for the Matchcode Id.
Short text.
Update
type - Default is 1 for logical
updating. It means that at the moment when you access the Matchcode object, the
table is created like view. Unlike logical updating, physical updates are: A,S,P.
System
Matchcode: If you click this particular
field, it indicates a system matchcode, which is used by SAP software and
cannot be changed by the end user.
Autho.checks:
If it is checked, the system performs authorization checks for this matchcode Id.
Selecting secondary tables
Position the cursor on the base
table of the ID.
Edit à Choose secondary
tables
A dialog box appears listing the
tables linked to the table by foreign keys
Select table.
Save.
Selecting fields for Matchcode Id
Select fields.
Choose fields.
Once all the fields are selected,
click on copy fields.
Fields are transferred to the
matchcode Id.
Activation of Id
A corresponding database view is
created in the database during activation for the Ids of update type I. During
activation, a check is made to see whether the corresponding index to support
view selection exists in the database. If it doesn’t, a warning is displayed.
Testing the Matchcode Id.
To test the matchcode Id: Maintain matchcode object.Utilities à display matchcode
data.
Using Matchcode
When the user do not know which
matchcodes are available for a field, user can find the matchcode by:
Positioning the cursor on a field
and clicking on drop arrow or pressing the F4 key.
A dialog box appears with a list
of available matchcode
User can select another matchcode
by clicking on the NEW selection button.
Double click on a matchcode to
use it. If you want to use this as default matchcode, click on standard button.
If user does this once, the selected matchcode is proposed automatically the
next time.
You can enter the search term and
press ENTER. If search term is not specified, the system displays all the
records for the specific matchcode.
Lock Objects
In a system where many users can
access the same data, it becomes necessary to control the access to the data.
In R/3 system this access control is built-in on database tables. Developers
can also lock objects over table records.
To lock an object you need to
call standard functions, which are automatically generated while defining the
lock object in ABAP/4 dictionary. This locking system is independent of the
locking mechanism used by the R/3 system. This mechanism also defines LUW i.e.
Logical Unit of Work. Whenever an object is locked, either by in built locking
mechanism or by function modules, it creates corresponding entry in global
system table i.e. table is locked. The system automatically releases the lock
at the end of transaction. The LUW starts when a lock entry is created in the
system table and ends when the lock is released.
Creating Lock Objects
Lock object is an aggregated
dictionary object and can be defined by using the following steps:
- From initial data dictionary screen, enter the name for the object, Click Lock object radiobutton and then click on Create. The system displays a dialog box for Maintain Lock Objects screen
- Enter short text as usual and the name for primary table.
- Save
- Select Tables option
From this screen you can:
Select secondary tables, if any,
linked by foreign key relationship.
Fields for the lock objects. This
option allows you to select fields for objects (R/3 system allows locking up to record level).
Lock object argument are not selected by user but are imposed by the system and
includes all the primary keys for the table.
Types of locks
You can lock the table or record
by using following types of locking:
Exclusive (E) the locked data can
only be displayed or modified by single user i.e the owner of the object.
Access to other users is denied.
Shared (S) several users can
access the same record simultaneously, but only in display mode and except the
first one, who has asked for the data in update mode.
Exclusive not cumulating (X) it
is similar to exclusive lock. It allows only a single user access. E can be
called several times from the same transaction. In contrast, a lock type X can
be called only once during the transaction. Any other call for this lock is
rejected.
Activation of Lock Object
When you activate the lock
object, the functions are automatically generated. And these are ENQUEUE-EZN
and DEQUEUE-EZN. EZN is name of the lock object.
While ENQUEUE is used in program
to set the code over the selected data depending upon the lock object
arguments. DEQUEUE is used to release the lock.
EXERCISES
1.
Create a
matchcode for MARA-MATNR with one matchcode ID. The fields in the ID should be
MARA_MATNR., MARD-WERKS. MARD-LGORT. MAKT-MAKTX.
2.
Create a GUI status of type list with the
following features and attach it to a report. (Create a simple report with
Write statement).
Use the
statement SUBMIT REPORT AND RETURN TO CALL A REPORT.
Menu
REPORTS SYSTEM HELP
Materials
Vendors
Exit
Application
tool bar: 3 push button - Material,
vendors, exit.
When material
push button or menu option is chosen to display a list a materials with the
following fields:
MARA-MATNR,
MARD-WERKS,MARD-LGORT,MAKT-SPRAS.
When vendor
pushbutton or menu option is chosen, display a list of vendors with the
following fields.
LFA1-LIFNR,
LFA1-NAME1, LFA1-ORTO1.
Exit to quit
the program.
3.
Create a transaction with three screens
Screen 1:
Radiobutton : 2
R1,R2.
Pushbutton :2-Next, Exit,
When NEXT button is pressed,
display screen 2 or screen 3 on the radio button selected.
i.e., if R1 is selected display
screen 2 or if R2 is selected display screen3.
Screen 2:
Entry fields : SPFLI-CARRID, SPFLI-CONNID,SPFLI-CITYFROM,
SPFLI-CITYTO.
Pushbutton : First screen, Exit.
Screen 3.
Entry fields : SFLIGHT-CARRID.
SFLIGHT-CONNID.SFLIGHT-FLDATE.SFLIGHT-SEATSMAX,SFLIGHT-SEATSOCC.
Pushbuttons: First screen, Exit.
`Firstscreen’ pushbutton is to
display screen 1 and exit is to quit the transaction.
***********USE
SELECT-SINGLE*************
4.
Create a transaction with on screen.
Screen one
Entry fields:
MARD-MANTNR,MARD-WERKS,MARD-LGORT
Pushbuttons: Firstrecord Next
Record, Previous record, Last Record, Exit.
Select the data from MARD into an
internal table and whenever a button is pressed display the corresponding
record (i.e. First, Next, Previous, or Last) using the internal table index.
Exit to quit the transaction.
5.
Copy above transaction and enhance it with these
features. Place another pushbutton ‘List’. When this button is pressed, Display
a list with the following fields. MARD-MATNR,MARD-WERKS,MARD-LGORT.
**********Use
LEAVE –TO-LIST-PROCESSING***********
6. Create a transaction with two normal
screens and two subscreens.
Screen1 : Normal
screen.
Entry fields : MARA-MATNR
Radiobuttons: Plant, Description
Push-button :Display, Exit.
Screen2: Normal
screen.
Display fields: MARA-MATNR.
Pushbuttons:Back,Exit.
Screen3: Subscreen.
Display fields:
MARD-WERKS,MARD-LGORT.
Screen4: Subscreen
Display
fields:MAKT-SPRAS,MAKT-MAKTX.
When the display pushbutton is
clicked, display Screen2 with proper subscreen attached to it based on the
selection of radio button..
i.e. Screen 3 - if plant is selected and Screen 4 - if
description is selected.
No comments:
Post a Comment