The document discusses different aspects of SAP architecture and data modeling. It describes the three-tier client/server architecture of SAP R/3 systems with presentation, application, and database layers running on separate computers. It also discusses different types of database tables like transparent tables, pooled tables, and cluster tables and how they are structured and stored differently in the database. The key differences between pooled tables and cluster tables are explained. Important control properties of database tables like delivery class, data class, size category, and buffering status are also summarized.
2. 2
Sap architecture
If you use the possibilities of the distributed R/3 system according to the client/server
methodology, then the R/3 components are spread across a three-tier CPU hierarchy.
The database server is installed on a central computer, which means the processes
representing the database service run here. This computer also houses at least the R/3
update service, that is, this CPU is responsible for all database changes. Multiple application
servers can be connected to the dabase server. The application servers process the actual
application logic.
Multiple front-ends (workstation, PC) on which the users are working can then connect to
each application server. The individual front-ends handle all presentation tasks.
SAP AG
Central DB
(stores all data and
application programs)
R/3 Client/Server – Three-Level Computer
Hierarchy
User interaction
Application logic
Database update
Central DB
buffer
Input data
from the user
Output data to
the user
Read database and
update buffers
Object-
oriented
change
requests
(asynchronous)
3. 3
R/3 Basis configurations:
A: Central system with centrally installed presentation software
B: Two-tier client/server system with distributed presentation software
C: Two-tier client/server system; presentation and application run on the same computer
D: Three-tier client/server system; presentation, application, and database each run
on their own computer
The central process of the application server is the SAP dispatcher as central control. The
SAP dispatcher, together with the specific operating system, manages the resources for the
R/3 applications
The main tasks of the dispatcher include:
S A P A G
R / 3 C l i e n t / S e r v e r C o n f i g u r a t i o n s
T h r e e - t i e r
c l i e n t / s e r v e r
D i s t r i b u t e d
p r e s e n t a t i o n
T w o - t i e r
c l i e n t / s e r v e r
S A P R / 3 S y s t e m
P r e s e n t a t i o n A p p l i c a t i o n D a t a b a s e
C e n t r a l s y s t e m
SAP AG
The SAP Dispatcher
Presentation
Application
Buffer
Database
Communication
SAPGUISAPGUI SAPGUISAPGUI
Work
process
Work
process
Work
process
Dispatcher
4. 4
evenly distributing the transaction load among the work processes, interfacing with the
presentation level, organizing the communication activities.
The dispatcher carries out the following tasks during initialization
reading profile parameters, creating and initializing semaphores, generating roll areas,
starting work processes, logging on to the message server.
The user entries on the screen are received by the SAP presentation program SAPGUI which
converts it into its own format and sends it to the dispatcher.
The dispatcher manages the information exchange between the SAPGUI and the work
processes, whereby all users share a few work processes.
The dispatcher first stores the processing requests in request queues and then processes
them.
The dispatcher dispatches the requests one after the other to free work processes. The
actual processing is done by the work processes.
At end of processing, the dispatcher returns the results of a work process back to the SAPGUI
who interprets the data and generates the output screen.
SAP AG
Dialog Step Dataflow
Application
Presentation
Database
Relational
database system
Request queues
SAPGUI
ROLL
222
444
555
Terminal
process
Dialog object
333
666
111
777
Work
process
6. 6
Table Types
DATA BASE : Store the data base permanently until deleted. These tables are classified into 3
types
1.) Transparent Table
2.) Pooled Table
3.) Clustered Table
7. 7
Transparent Table: Exists with the same structure both in dictionary as well as in database exactly
with the same data and fields.
Pooled Table: Pooled tables are logical tables that must be assigned to a table pool when they are
defined. Pooled tables are used to store control data. Several pooled tables can be combined in a
table pool. The data of these pooled tables are then sorted in a common table in the database.
EG: All Condition tables i.e., Annn tables (pricing/discounts etc.,) belong to the table Pool KAPOL
(Condition Pool) as the underlying concept is same across different condition tables, but, they have
different Key (primary) fields.
Cluster Table: Cluster tables are logical tables that must be assigned to a table cluster when they
are defined. Cluster tables can be used to store control data. They can also be used to store
temporary data or texts, such as documentation.
EG: Accounting Document Segment (Line Item records) BSEG is a cluster table that belongs to the
table cluster RFBLG. Also, other tables such as BSEC, BSED, BSES, BSET also come under the same
table cluster as all of them possess the common Key i.e., BUKRS/BELNR/GJAHR. And CDPOS
(CDCLS)
BSEC - One-Time Account Data Document Segment, BSED- bill of exchange Fields Document
Segment
BSEG-Accounting Document Segment, BSES-Document Control Data, BSET-Tax Data Document
Segment
Pooled and Cluster Tables Differences
Table pools (pools) and table clusters (clusters) are special table types in the ABAP Dictionary. The
data from several different tables can be stored together in a table pool or table cluster. Tables
assigned to a table pool or table cluster are referred to as pooled tables or cluster tables.
A table pool or table cluster should be used exclusively for storing internal control information
(screen sequences, program parameters, temporary data, continuous texts such as
documentation). All data of commercial relevance is stored exclusively in transparent tables!
Table Pools
A table in the database in which all records from the pooled tables assigned to the table pool are stored
corresponds to a table pool.
The definition of a pool consists essentially of two key fields (Tabname and Varkey) and a long argument
field (Vardata). A pool has the following structure:
Field Data type Meaning
Tabname CHAR(10) Name of pooled table
Varkey CHAR (n) Contains the entries from all key fields of the pooled table record
as a string, max. length for n is 110
Dataln INT2(5) Length of the string in Vardata
8. 8
Vardata RAW (n) Contains the entries from all data fields of the pooled table record
as a string, max. length n depends on the database system used
If a pooled table record is saved, it is stored in the table pool assigned. The name of the pooled table is
written to the field Tabname. The contents of all key fields of the pooled table are written as a string to
field Varkey and the contents of all data fields as a string to field Vardata. The length of the string stored
in Vardata is entered in field Dataln by the database interface
Due to the
structure of a table pool, there are certain restrictions on the pooled tables assigned to it. The name of a
pooled table may not exceed 10 characters. Since Varkey is a character field, all key fields of a pooled
table must have character data types (for example, CHAR, NUMC, CLNT). The total length of all key
fields or all data fields of a pooled table must not exceed the length of the Varkey or Vardata field of the
assigned pool.
Table Clusters
Several logical data records from different cluster tables can be stored together in one physical record in
a table cluster.
A cluster key consists of a series of freely definable key fields and a field (Pageno) for distinguishing
continuation records. A cluster also contains a long field (Vardata) that contains the contents of the data
fields of the cluster tables for this key. If the data does not fit into the long field, continuation records are
created. Control information on the structure of the data string is still written at the beginning of the
Vardata field. A table cluster has the following structure:
Field Data type Meaning
CLKEY1 * First key field
CLKEY2 * Second key field
... ... ...
CLKEYn * nth key field
9. 9
Pageno INT2(5) Number of the continuation record
Timestamp CHAR(14) Time stamps
Pagelg INT2(5) Length of the string in Vardata
Vardata RAW (n) Contains the entries from the data fields of the assigned cluster
tables as a string, max. length n depends on the database system
used
The records of all cluster tables with the same key are stored under one key in the assigned table
cluster. The values of the key fields are stored in the corresponding key fields of the table cluster. The
values of all data fields of the assigned cluster tables are written as a string to the Vardata field of the
table cluster. Besides the actual data values, the data string contains information on the structure of the
data and which table it comes from. If the string exceeds the maximum length of the Vardata field, a
continuation record is written with the same key values. The continuation records for a key are
distinguished by their value in field Pageno. The actual length of the string in the Vardata field is stored
in the Pagelg field by the database interface.
You need the structural information stored in the ABAP Dictionary to read the data from a pooled table or
cluster table correctly. These tables can therefore only be processed using Open SQL with the cluster
interface, and not with Native SQL directly in the database.
10. 10
Transparent Pool Cluster
Contain a single table.
Used to store master
data
They are used to hold
a large number of
very small
tables(stores
customizing data or
system data)
They are used to hold
data from a few
number of large
tables.(stores system
data)
It has a one-to-one
relationship with a
table in the database
It has a many-to-one
relationship with a
table in the database
It has a many-to-one
relationship with
table in the database
For each transparent
table there is one
associated table in
the database
It is stored with other
pooled tables in a
single table called
table pool in the
database
Many cluster tables
are stored in a single
table in the database
called a table cluster
The database table
has the same name,
same number of fields
and the fields have
the same names
The database table
has different name,
different number of
fields and fields have
different names
The database table
has different name,
different number of
fields and fields have
different names
There is only a single
table
Table pools contain
more tables than
table clusters
Contains less tables
than table pools
Single table can have
one or more primary
key
Primary key of each
table does not begin
with same fields or
fields
Primary key of each
table begins with
same fields or fields
Secondary indexes
can be created
Secondary indexes
cannot be created
Secondary indexes
cannot be created
They can be accessed
using open and native
SQL
They can be accessed
using open SQL only
They can be accessed
using open SQL only
USE: They are used to
hold master data e.g.
Table vendors or
table of customers.
Example of
transaction data is
orders placed by
customers
USE: They reduce the
amount of database
resources needed
when many small
tables have to be
opened at the same
time
USE: They would be
used when the tables
have primary key in
common and data in
these tables are all
accesses
simultaneously
11. 11
IMPORTANT CONTROL PROPERTIES OF TABLE
1) Delivery class: The delivery class controls the transport of table data when installing or
upgrading, in a client copy and when transporting between customer systems. The delivery class is
also used in the extended table maintenance.
Example
A: Application table (master and transaction data). C: Customer table, data is maintained by
the customer only.
L: Table for storing temporary data.
2.) Data class in technical settings: The data class defines the physical area of the database
(for ORACLE the TABLESPACE) in which your table is logically stored. If you choose a data class
correctly, your table will automatically be assigned to the correct area when it is created on
the database.
Important table spaces are:-
APPL0 --- Master data
APPL1 --- Transaction data
APPL2 --- Organizational and customizing data
3.) Size category: The size category determines the probable space requirement for a table in
the database.(0 to 9).
Example: If size category 0 means 100 records. Then as a group sap stores a max of 100
records. If this is filed one more space equivalent to 100 records will be allocated
Note: if we store the records in too many places retrieving the records will be slower, so
choose appropriate size category
4.) Display Maintenance:
12. 12
This property Defines if the user can manipulate / Display the data directly on the table level
Allowed :- the user can directly manipulate(Create / Modify) directly on the table.
with Restriiction:- The user is not allowed to manipulate but he can only display .
Not Allowed:- The user can not manipulate or display the records. The separate program
should control the display and manipulation.
5.) Buffering status: Buffering specifies whether the records 1.) Buffering not allowed,
2.)Buffering allowed but not activated and 3.) Buffering Switched on.
Single-record buffering
With this kind of buffering, only the records of a table which are actually accessed are loaded
into the buffer.
This kind of buffering requires less storage space in the buffer than full buffering. However,
greater organization is necessary and considerably more database accesses are necessary for
loading.
ABAP Program
Select Query
Database interface
R/3 Database
table buffer
Database
buffer
Application
Server
Database
Server
Database
Fig.1. Database Table buffering
13. 13
If an as yet unbuffered record is accessed with SELECT SINGLE, a database access occurs to
load the record. If the table does not contain a record for the specified key ('no record found'),
this record is noted as nonexistent in the buffer. If a further attempt is made to access this
record, a renewed database access can be avoided.
When should single-record buffering be selected?
For large tables where there are frequent single-record accesses (with SELECT SINGLE
...). The size of the records being accessed should be between 100-200 KB.
For comparatively small tables for which the access range is large, it is normally
advisable to opt for full buffering. Only one database access is required to load such a
table for full buffering, whilst single-record buffering calls for a very large number of
table accesses.
Generic buffering
In a read access to a record of a generically buffered table, all the records whose left-justified
part of the key (generic area) corresponds are loaded into the buffer.
If this type of buffering is selected, the generic area must be defined by specifying a number n
of key fields. The first n key fields of the table then define the generic key.
The number of key fields to be entered must lie between 1 and the number of key fields -1. For
example, only values between 1 and 5 are permitted for a table with 6 key fields.
When should generic buffering be selected?
A table should be buffered generically if usually only certain areas of the table are
required. The individual generic areas are treated like independent tables which are
fully buffered. Please also read the text about full buffering.
The generic key area should be selected so that the generic areas are not too small to
prevent too may generic areas being produced. If there are only a few records per
generic area, it is more efficient to use full buffering.
Generic buffering only makes sense if the table is accessed by a specified generic key.
If, when an access takes place, a field of the generic key is not supplied with a value,
the buffer is ignored and the records are read directly from the database.
Language-specific tables are an example of a good use of generic buffering (with the
language key field as generic key area).
Full buffering
With full buffering, either the complete table or none of the table is in the buffer. If a read
access is made to a record, all records of the table are transferred to the buffer.
When should you select full buffering?
14. 14
For tables up to 30 KB in size. If a table is accessed frequently, but all accesses are read
accesses, this value can be exceeded.
For larger tables where large numbers of records are frequently accessed. However, if
the application program is able to formulate an extremely selective WHERE condition
using a database index, it may be advisable to dispense with full buffering.
For tables with frequent accesses to data not contained in the table. Since all records
are contained in the buffer, a quick decision can be made as to whether or not the
table contains a record for a specific key.
When considering whether a table should be fully buffered, you should take three aspects into
account: the size of the table, the number of read accesses, and the number of write accesses.
Tables best suited to full buffering are small, frequently read, and rarely updated.
Buffering of database tables is a technique in which the data from database table is copied
into the local storage place in application server, known as buffers. Hence the subsequent
requests for data is instead fetched from the buffered tables rather than actually accessing the
database tables. This in turn increases the performance by reducing the database hit time.
Database table buffering:
For the first time when data from a DB Table is requested, database interface hit the database
to fetch the data. However if the table is buffered one then the data from the table is filled
into the buffer also. Hence for all subsequent requests of data from the same table the data is
fetched from buffer.
Limitations:
Only transparent table and pooled tables can be buffered. Clustered tables can not be
buffered. The key fields of the buffered tables need to be mapped to one of the ABAP types C,
N, D or T.
Table buffering types:
Three types of buffering are allowed for any table.
Full table Buffering.
Generic Buffering with no of keys
Single record Buffering
Implementing Table buffer
Different types of buffering are explained with example below:
15. 15
Full table Buffering:
Full table buffering as the name suggest is to get all the data of a table into the buffer space.
When a SELECT statement is executed on the given table for the first time it hits the database
to get the data and also fills the table buffer in the application server. But all the select
statements requesting the data from this table will fetch it from the buffer.
Example:
Fig.2. the table ZZZ_EMP_PROJ
Let the table zzz_emp_proj be a database table that is not buffered.
Then for the select query of simple type that selects all the values from this table will
directly hit the database to fetch the data.
The following SQL trace list shows how much duration it takes to get the data from the
database.
Fig.3. SQL trace list showing database fetch time when table is not buffered
16. 16
Now let us change the technical settings of the table to Full Table Buffering. Then for all the
select statements which do a select on the table zzz_emp_proj we will have the following
characteristics, i.e. for the first time it will fetch from the database. Then it will buffer the
whole table data, so for subsequent requests data is fetched from the buffer. That reduces the
fetch time drastically. We can see from bellow screen shot of the SQL trace list the yellow lines
are for database hit. The rest are within application server only.
Fig.4. Technical Setting for Full Table Buffer
Fig.5. SQL Trace showing the duration of select statement executed first time in a fully
buffered table
17. 17
Fig.6. SQL trace showing data fetched from buffer for subsequent select statement
18. 18
Full buffering is preferred in the following cases.
If a table is accessed frequently for read purpose mostly then it is advisable to go for
full table buffering
If a table is accessed more often to check whether an entry is available or not, those
kinds of tables could be fully buffered so that it will be checked in the buffer without
going into the database
Primarily small tables with frequent read access and with very less probability of
written on to, are best suited for full table
SAP suggests tables of size below 30 KB should be fully buffered. However this could be
applied to larger tables depending on number of read and write attempt.
Sometimes it is also advisable to avoid buffers if a well formulated WHERE statement
could be written based on the indices of the db table.
Generic table Buffering:
When a table is buffered generically based on certain keys then the records containing the
given values for these keys are copied into the buffer. So for those select statements with fully
specified generic keys it gets the data from Buffer. If the key is not assigned a value in the
select statement then the statement will bypass the buffer and select it from the database. It is
always an important factor to decide the key of generic buffering. If we chose a key with small
variation then while buffering large amount of data will come into the buffer. This in turn will
increase the fetch time of data.
Example:
Let us again take the same database table zzz_emp_proj and which is buffered generically on
the first key that is project.
Fig.7. Here we can see the table we used
for our example for full table buffering
zzz_emp_proj. This table will get
buffered totally as we have maintained
full table buffer in the technical settings
of this table
19. 19
Fig.8. Table is Generic Area buffered with no of key fields 1
Then for the select query with certain value of project it will select those part of data for which
the key contains the given value from database and put them in buffer. For all subsequent
queries where the key value does not change it will go to the same place and get the data
without hitting the database.
Suppose we select all entries from this table
zzz_emp_proj where project is ‘DCSAPMNT’
and location is ‘Bangalore’ then it gets the
data from database for the first time and
populate the buffer with the values where
project is ‘DCSAPMNT’. As we have
maintained the technical settings of this
table as ‘generic buffer with no of keys 1’.
Hence for next time whenever it goes to get
the data with the same key value it will be
fetched from the buffer itself Hence you can
see the difference of time in following two
screen shots.
Fig.9. data that will be buffered for the given table
20. 20
Fig.10. Shows the db hit time for execution of select for the first time
Fig.11. Shows the decrease in total duration for fetch data as it is being fetched from buffer.
From these two SQL trace list above we can understand how drastically the fetch time
decreases if fetched from the buffer. The yellow lines indicate the database hit and light blue
lines indicates that the data is fetched from buffer.
21. 21
Single record Buffering:
Single record buffering will buffer only one
record in the application server. Hence for
the first selection statement it buffers the
records selected. And in case of
subsequent selections it gets the value
from the buffer. If you change the select
query in order to get some different lines
then it will fetch the data from database.
Similarly if the select query selects more
than one line then the buffer is overlooked
and data is fetched from the database
table.
Example:
The select query selecting one record from
table zzz_emp_proj which is not buffered
presently.
Fig.12. example of data selected in table
for single record buffering
Fig.13. Technical settings for single record buffering
22. 22
Fig.14- zzz_emp_proj table Without Buffering.
Fig.15. after buffering first time selection
Fig.16. After buffering subsequent time selection data fetched from buffer.
These SQL trace lists show how the duration has decreased in the buffering of the table.
Technically single-record buffer contains central administrative structure, a table directory and
the data area. The table names are stored in alphabetical order and the data area is organized
in frames of fixed size. While searching the buffer a binary search is done in the table directory
then in the corresponding frames to get the records. Single record buffering also stores
information about the nonexistent record of database table, by using a flag. So single record
buffering is advisable when again and again we are accessing nonexistent records of data base.
However depending upon our requirement we can chose our buffering so that it will increase
the performance of the program as a whole.
24. 24
Synchronization Issue:
The buffer is present in the application server. The data is copied into the buffer and for
subsequent selection it fetches the data from this storage. However any modification to the
database has to be reflected onto these buffers in application servers. Therefore we have
following two ways in which the buffer is synchronized.
Synchronous scenario: Whenever the database is updated corresponding to some buffered
table it floods the information across the applications servers those have buffered the values
of tables. This might lead to inconsistency of the data as this process is highly dependant on
the network’s reliability.
Asynchronous Scenario: the data is modified in the database table but is not updated to the
corresponding buffers in the application server. However a table DDLOG in the central
database is updated with these modifications. The application servers holding the buffers poll
at this table in certain time intervals. If it finds the modification in the given table relevant to
its buffers then it clear the corresponding buffer. So next time the select query executes the
data is fetched from the database table and buffered.
Avoiding Buffer:
In certain cases we might need to avoid buffers and directly fetch the data from database
table which might be more time effective. The following select queries do not make use of
the buffer even if the corresponding table is buffered.
i. SELECT... BYPASSING BUFFER
ii. SELECT with aggregate function (COUNT, MIN, MAX, SUM, AVG)
iii. SELECT DISTINCT
iv. SELECT... WHERE... IS NULL
v. ORDER BY (with the exception of PRIMARY KEY)
vi. SELECT FOR UPDATE
vii. All access through the Native SQL also by pass the buffer
25. 25
Domain: A domain describes the technical attributes of a field, such as the data type or the
number of positions in a field. The domain defines primarily a value range describing the valid data
values for the fields referring to this domain.
Different technical fields of the same type can be combined in a domain. Fields referring to the
same domain are changed at the same time when a domain is changed. This ensures the
consistency of these fields.
Data elements : (elementary types)
Elementary types have no structure. They describe the data type attributes (such as given
Dictionary data type, number of places) and information that is relevant for the screen (such as
title) of unstructured data objects (variables/fields).
Creation of Transparent Table
1. Enter the table name and press Create
2. Enter the description, Delivery class and check on table maintenance allowed. Then click on the
tab Fields.
26. 26
3. Enter the ZCHAR in fields tab and ZCHAR_DE in field type tab.
4. Double click on ZCHAR_DE. Then it will ask for Save. Press ‘YES”.
27. 27
5. Save it as a local object on pressing Local object button
6. Now it will ask for the creation of the data element. Press Yes.
28. 28
7. Click on the Field label tab and enter the lengths and descriptions accordingly.
8. Then press Definition tab and enter the domain.
29. 29
9. Double click on that zchar_d to create domain, then it will ask for save before going next screen.
Press Yes.
10. Save it as a local object.
30. 30
11. Now it will ask for domain creation. Press Yes.
12. Give short description for that domain which you are creating. And mention the data type in data
type field and length in no. characters field an press ENTER.
31. 31
13. Then press Ctrl+F3. It will ask for save before activation. Save it as a local Object.
14. Press Enter.
32. 32
15. Then the following screen appears. Press on back button.
16. Press Ctrl+F3. You will get the following screen. Press Back button.
34. 34
18. Create one more field ZNUM and give data element name as ZNUM_DE. And double click on
‘ZNUM_DE’
19. Save it by pressing Yes.
20. Now it will ask for the data element creation. Press Yes.
21. Give short description of the data element. And give the lengths and field labels accordingly in
Field label tab.
35. 35
22. Press on Definition tab and give the domain name in Domain field. Double click on ZNUM_D.
23. It will ask for save. Press Yes.
36. 36
24. Save it as a local Object.
25. Now it asks for Domain creation. Press Yes.
26. Give short description in short text field. Enter the data type and no. characters, Press Enter.
Then Press on Activate button or Press Ctrl+F3.
41. 41
33. Now we created two fields. And Data elements and Domain for these two fields.
Now we have to maintain the technical settings. Press on Technical settings button.
42. 42
34. Give the data class and size category of the table as per the requirement.
And press the back button.
35. Now activate the table by pressing the activate button or CTRL+F3.
36. Press enter.
44. 44
38. Now enter the data into table. Go to Utilities Table contents Create Entries.
39. Now enter the data in the fields and Save it.
45. 45
40. You will get the following screen after clicking the Reset Button.
41. Enter the data for the second entry into the table.
42. Save it and press reset.
46. 46
43. You will get the following screen.
44. Again enter the data for the third entry.
47. 47
45. Press save, Reset (Optional) and Back button.
46. Now you will get the following screen.
48. 48
47. To see the table contents go to Utilities Table contents Display. Or press Ctrl+Shift+F10.
48. You will get the following screen.
49. 49
49. Press on run button or press F8. Now it will display the table contents.
Creation of a table pool and pool table
Step 1:
Go to transaction SE11. Go to Utilities Other Dictionary Objects
50. 50
Step 2:
Select Radio button Table pool/Cluster Give table Pool Name: ZTBL_POOL.
Then press F5 or choose Create.
Step 3:
Then Select Radio button Table Pool. Press Enter.
51. 51
Step
4:
Then you go to maintain Poll Screen there give Short Description.
Step 5:
Then go to Technical settings.
52. 52
Step 6:
In the “Maintain technical Settings” screen Provide Size category.
Save and activate the table Pool. Go back to SE11.
Step 7:
Go to SE11 ABAP Dictionary: Initial Screen.
Create a Z table.
53. 53
Step 8:
Maintain Delivery and Maintenance attributes for the Z table.
Add fields to the Z table.
Maintain Technical settings and Enhancement Category.
54. 54
Step 9:
Then Go to Extras Change table category
Step 10:
Choose Table type.
In our Example it is Pooled table.
55. 55
Step 11:
Go back to Delivery and Maintenance tab and provide Pool/Cluster value.
We have successfully created Table pool and Pooled table.
57. 57
VIEW: Is a imaginary database which does not really exist
Projection View
Database View
Maintenance View
Help View
Database View (SE11)
Database views are implement an inner join, that is, only records of the primary table (selected
via the join operation) for which the corresponding records of the secondary tables also exist
are fetched. Inconsistencies between primary and secondary table could, therefore, lead to a
reduced selection set.
In database views, the join conditions can be formulated using equality relationships between
any base fields. In the other types of view, they must be taken from existing foreign keys. That
is, tables can only be collected in a maintenance or help view if they are linked to one another
via foreign keys.
58. 58
Help View ( SE54)
Help views are used to output additional information when the online help system is called.
When the F4 button is pressed for a screen field, a check is first made on whether a matchcode
is defined for this field. If this is not the case, the help view is displayed in which the check
table of the field is the primary table. Thus, for each table no more than one help view can be
created, that is, a table can only be primary table in at most one help view.
Projection View
Projection views are used to suppress or mask certain fields in a table (projection), thus
minimizing the number of interfaces. This means that only the data that is actually required is
exchanged when the database is accessed.
A projection view can draw upon only one table. Selection conditions cannot be specified for
projection views.
Maintenance View ( SE54 )
Maintenance views enable a business-oriented approach to looking at data, while at the same
time, making it possible to maintain the data involved. Data from several tables can be
summarized in a maintenance view and maintained collectively via this view. That is, the data
is entered via the view and then distributed to the underlying tables by the system.
Creating a projection view:-
We use projection view to mask unwanted fields and display only relevant fields in a table. Basically
View acts like a database table only, the difference is view will not occupy storage space.
1. Creating Projection View
59. 59
2. Choose Projection View in the pop up which appears when you click on create
3. Give Description & base Table name(In this example we have taken KNA1)
60. 60
4. After giving table name click on Table fields button
5. Choose the fields which you want to be displayed in output and click copy
62. 62
Summary
In standard SAP tables we will have many fields, of which we will use only few fields. whenever we go
and view the data we have to come across unwanted data, to avoid this and get display of field which
relevant to scenario we use this projection view.
63. 63
Structures
Structure:- Structure is a user defined group of variables which can hold 1 record during time
Go to transaction SE11 and select the radio button “Data type”. Enter a structure name starting with Y or
Z.
64. 64
Press create button.
A pop-up screen appears with 3 different options. Select the radio button structure.
The screen will be displayed like this.
Provide the description and also components.
67. 67
Introduction
Search helps are data selection methods used to provide the possible value list for a screen
field. I.e. Search helps are used to provide F4 help for screen fields. The selection logic for the
data to be displayed can be to show the entries from a single table (no coding required) or
even can be complex ABAP code to select the data from different tables which are related or a
combination of both. Thus search helps can be used to show very specific information that
would be required by the user to select an entry from the possible value list.
There are two types of search helps.
1) Elementary search helps: Elementary search help defines a specific search path. The
following components need to be defined for an elementary search help
a) Where to pick the data from (Selection method)
b) What fields have to be considered while selecting the data and what are fields
to be displayed (Search help parameters)
Dialog box of elementary search help
68. 68
An Elementary search help is a search help that describes an input help process in which it is not
possible to select one of a number of search paths.
The online behavior of an elementary search help is controlled by defining the dialog type and by
specifying the fields to be displayed in the dialog box for restricting values or in the dialog box for
displaying the hit list (including the order in these dialog boxes). These fields must be defined as
parameters of the search help.
For data collection, a database table or a view is normally defined and the possible values are
selected here. This table/view is called the selection method of the search help. If the selection
method is a table, a text table can also be used for collecting data if one exists. In the selection,
those fields of the selection method (and possibly of the text table) which have parameters with
the same names in the search help are used.
If the standard options for describing the online behavior or data collection for the search help are
not sufficient, you can define its behavior more flexibly by using a search help exit.
2) Collective Search helps: Collective search helps are a collection of elementary search
helps, thereby providing multiple search paths for a particular field on the screen.
The user can select the required search path and use it to get the desired list. Here too
we can define the input parameters and the output parameters for the search help.
Necessary mapping between the collective search help and the included elementary
search help has to be provided.
Dialog box of Collective search help
69. 69
A Collective search help describes an input help process in which the user
can choose one of several alternative search paths. Each alternative search
path corresponds to an elementary search help, i.e. a collective search help
contains several elementary search helps.
Both elementary search helps and other collective search helps can be
included in a collective search help. if a collective search help contains
other collective search helps, they are resolved down to the level of the
elementary search helps when the input help is called.
Like an elementary search help, a collective search help has an interface of
import and export parameters. The data is exchanged between the screen
template and the parameters of the elementary search helps contained in it
using this interface. The parameters of the search helps included in a
collective search help must be assigned to the parameters of the collective
search help.
During the input help process, the collective search help only controls the
user's selection of the required search path. The rest of the dialog and data
collection is controlled by the selected elementary search help. If selection
of the required elementary search help should be made flexible (e.g. with
context-specific definition of the set of available search paths), the
collective search help must be assigned a search help exit.
Creating Elementary Search Helps:
In SE11 give the search help name and click the create button. Choose “Elementary search
help” in the pop up that follows. This takes you to the screen where you enter the details of
the search help.
In the Definition tab you have to enter the following details:
1) Selection method: The table from which the data is to be selected by the search help
for display of possible value list is to be entered here. This is not a mandatory field. If
the selection method is not entered then the data selection (from displaying the
possible value list) will have to be done in the search help exit (explained later).
2) Text Table: This field is non editable. If a text table exists for the selection method
(table) entered then this field is populated automatically.
70. 70
3) Dialog type: The dialog type defines the steps that are followed by the search help
through the process of displaying the search help. You can select from the following
dialog types:
a) Immediate value display: The possible value list is displayed immediately on
calling the search help.
b) Dialog with value restriction: On calling the search help a dialog box for
restricting the values (Just like a selection screen) selected is displayed first.
This dialog box will have those parameters, which are defined as the import
parameters in the search help parameters.
c) Dialog depends on value set: If the possible value list contains less than 100
entries then the list is displayed immediately. If not then this behaves similar to
dialog with value restriction.
As a convention, if the possible value list has very less number of entries we would be
using the first (a) and if the list will have large volume of data we would use options (b)
and (c).
4) Hot key: Hot key (short cut) can be assigned to elementary search help. This can be
any character or digit. This will be used when this elementary search help is used as a
part of the collective search help. (To call a specific elementary search help from a
collective search help enter the following in the field to which the collective search help
is attached “ =<Hot key of the elementary search help> “ and do an F4. For e.g. =A and
press F4, where A is the hotkey for a specific elementary search help).
5) Search help exit: Search help exit is a function module, which is used to modify and
manipulate with the data selection procedure and the selected data. The function
module should have the same interface as the function module
F4IF_SHLP_EXIT_EXAMPLE.
The function module defined as the search help exit will be called at different time
points during the process of data selection by the search help. The different time
points at which this function module is called and the manipulations that are possible
at each time point are explained in detail in a later section.
71. 71
6) Parameters: Here you define the search help parameters. You can define import
parameters and export parameters for the search help. Following are the
characteristics of the parameters that you would have to define.
a) Checkbox ‘IMP’: If the parameter is an import parameter then check this
checkbox.
b) Checkbox ‘EXP’: If the parameter is an export parameter then check this
checkbox.
(Note: A parameter can be both import as well as export parameter depending
on the requirement. See the section Value transfer for input help for knowing
how the import and export parameters transfer values to and from the field to
which the search help is attached).
c) LPOS: This is the position of the parameter in the hit list. If a parameter need
not appear in the hit list then leave this field blank. Note that same position
number cannot occur more than once in a search help.(This will set postion on
the box which is displayed after F4 is pressed)
d) SPOS: This is the position of the parameter in the dialog box for value
restriction. (Selection screen). If a parameter need not appear in the dialog box
then leave this field blank. If no dialog box appears for value restriction then
this field can be left blank for all the parameters. Note that same position
number cannot occur more than once in a search help.
e) SDIS: If this check box is checked then in the dialog box for value restriction,
the parameter will appear as a display only field. The user will be able to see
the value restriction for this field but will not be able to modify the value.
f) Data Element and Checkbox ‘Modified’: A search help parameter should have
an associated data element. This data element will define the output attributes
for the parameter and the help functions (F4 help) for the parameter on the
dialog box for value restriction.
If a table is entered in the “Selection method’ of the search help then the data
element is picked up from the field of the table having the same name. All the
changes that you perform on this field in the database table, those get reflected
in the search help too.
72. 72
If you want to assign a different data element other than that is defined in the
database table then check the checkbox ‘Modified” for the parameter. Now the
data element field becomes editable and you can enter any required data
element. The new data element should have same data type, length and the
number of decimal places as the previous one. Only difference would be that
the changes that you make to the field in the ‘Selection method’ would not get
reflected in the search help.
g) Default Value: You can enter the default value for the parameter in this field.
Once these details are defined, activate the search help. We can test the search help by
doing an ‘F8’ on the maintain search help screen or the display search help screen.
Creating Collective Search Helps:
In SE11 give the search help name and click the create button. Choose “Collective search help”
in the pop up that follows. This takes you to the screen where you enter the details of the
search help.
In the definitions tab enter the following details:
73. 73
1) Search Help Exit: The use of the search help exit is the same as that in an elementary
search helps. In case of collective search helps the time points at which the exit (FM) is
called is slightly different than in case of elementary search helps.
The different time points at which this function module is called and the manipulations
that are possible at each time point are explained in detail in a later section.
2) Parameters: Just like elementary search helps collective search also has the import and
export parameters. See the section Value transfer for input help for knowing how the
import and export parameters transfer values to and from the field to which the search
help is attached.
In the included search helps tab define the following.
1) List down the elementary search helps that are going to be the part of this collective
search help.
2) Do the parameter assignment for each of the elementary search helps listed. This
procedure actually does a mapping between the parameters of the collective search
help and the individual elementary search helps. The mapping is automatically
proposed by the system but can be changed manually.
Once done, activate the search help. The collective search help also can be single tested from
the maintain search help screen or the display search help screen using the ‘F8’ functionality.
Attaching search helps to fields
1) Attaching the search help to a data element.
For attaching the search help to a data element go to further characteristics tab of the
data element through SE11 and enter the search help name in the field provided. Then
map an export parameter of the search help to the data element.
When input help is asked for any field using this data element, the corresponding
search help is triggered. If the user selects a line of the hit list in the input help, the
74. 74
contents of this parameter are returned to the corresponding screen field. It is not
possible to return several values when the search help is attached to a data element.
2) Attaching the search help to a check table
If a field has check table then the possible values for this field is defined by the contents
of the check table. The key fields of the check table will be automatically present in the
possible value list. If a text table is assigned to the check table then the text will also be
present in the hit list.
Attaching a search help to the check table can again modify the hit list obtained from
the check table. Assigning a search help to the check table field can do this. (Through
SE11)
75. 75
(Place the cursor on the field to which the search help has to be assigned and click on the
button “Search help”)
3) Attaching the search help to a table field
Assign a search help to the table field through SE11 (Refer the above screen shot)
4) Attaching the search help to a screen field
Search help can be assigned to a screen field. In this case the search help assignment is
valid only for that screen.
For dialog screens the assignment can be done through the Screen Painter in the
attributes for the field.
In the selection screen of the executable programs the search helps can be assigned to
the parameters and select-options as follows:
Parameter : <PAR> like <field name> matchcode object
<Search help>.
Select-Options:<SEL> for <fieldname> matchcode object
<Search help>.
Value Transport for input helps
76. 76
If a search help is attached to a screen field directly or through a data element then
only one search help parameter can be assigned to the field. The value transport takes place
between this field and the export parameter of the search help attached to the field.
(Even in this case the search help can have more than one export parameter. The search help
will transfer that field which is the first export parameter defined in the search help)
If the search help is attached to a table field or a check table then the value transport
can take place for more than one field that are linked to the search help through its
parameters. The import parameter of the search help picks up data from that field of the
screen, which has the same name as the search help parameter. If such a field is found then it
copies the data into the respective parameter and if not found then it leaves the parameter
blank. Mapping of the output parameters to the screen fields is similar to the input
parameters. The values are transported to the fields having the same name. Thus data can be
transferred to more than one fields.
Using Search help Exits
Search help Exit is just like any other function module and is used to modify the input help
process of any search help. Doing so we can provide very specific information required by the
user for choosing from the hit list. As mentioned earlier search help exits are called at specific
time points of the input help process. The current time point can be obtained from the
Function module parameter callcontrol-step.
Some of the time points at which manipulations with the data will be required most of the
time are:
1) SELONE
This time point occurs (only for collective search helps) before the dialog box for
entering the import parameters are displayed. This can be used for selecting an
77. 77
elementary search help in the collective search help. This time point occurs only once in
the entire search help process.
The parameter SHLP_TAB has one entry each for all the possible elementary search
helps. If an entry for a specific search help is deleted from SHLD_TAB that search help
will not be offered in the dialog box for selection.
If there is only one entry remaining in SHLP_TAB, then the dialog box for selection can
be skipped by setting the parameter CALLCONTROL-STEP to either ‘PRESEL’ or ‘SELECT’.
2) PRESEL1
Once the search help is selected this event occurs before the interface of the selected
search help is entirely copied. So at this time point you can change the properties of
the interface parameters of the selected search help by changing the Function module
parameter SHLP-INTERFACE.
The properties like the screen field to which the search help parameter is attached, the
output field for which the input help is asked etc can be changed at this stage.
3) PRESEL
This time point occurs before the dialog box for value restriction is displayed. At this
time you can predefine the value restriction. This can be done by populating the
function module parameter SHLP-SELOPT.
e.g.
DATA: l_selopt LIKE ddshselopt.
l_selopt-shlpfield = <Name of any import parameter of the search help>.
l_selopt-sign = 'I'.
l_selopt-option = 'EQ'.
l_selopt-low = <Value for the field>.
l_selopt-shlpname = <Search help name>.
APPEND l_selopt TO shlp-selopt.
78. 78
In the dialog box that appears the above restriction would already be
present. Use can enter any further selections if required.
4) SELECT
This is the time point where the actual selection of the data takes place. If you do not
want the default selection to take place, do the data selection that is required and
populate the same into the function module parameter RECORD_TAB.
For this first select the required data into an internal table and then use the FM
‘F4UT_RESULTS_MAP’.
Pass the following parameters in the above function module.
APPY_RESTRICTIONS = If you have not already applied the value restrictions then the
FM will do it if you pass this parameter as ‘X. SHLP_TAB = This is available in
the exit . Pass the same
RECORD_TAB = This is available in the exit . Pass the same
SOURCE_TAB = The internal table into which you have selected the data
Now to skip the standard selection set the function module parameter CALLCONTROL-
STEP to ‘DISP’. If this is not set then the default selection will over ride your data
selection.
5) DISP
This time point occurs before the data is displayed as the hit list. So here you can
manipulate with the parameter RECORD_TAB to change the values to be displayed.
Once you are done with the manipulations with the data if you want to display the data
then do not change CALLCONTROL-STEP.
If you do not want to display the hit list and select one value directly then keep only
that value in the table RECORD_TAB and set the CALLCONTROL-STEP as ‘RETURN’.
79. 79
If you input help request should be aborted then set the CALLCONTROL-STEP as ‘EXIT’.
If you want to re initiate the whole selection process starting from the dialog box for
value restriction then set CALLCONTROL-STEP as ‘PRESEL’.
Note: Function modules are provided in the function library for operations that are
frequently executed in search help exits. The names of these function modules begin
with the prefix F4UT_. The use of each of these function modules are available in
the documentation of each of these Function modules.
An Append search help is used for modification-free enhancement of a
collective search help (that is not the original in the current system) with
further search help inclusions. This technique can be used for example in
special developments and country versions, and by SAP partners and
customers to add further search paths to a collective search help of the
standard system.
An append search help has a fixed assignment to a collective search help (its
appending object). This appending object is enhanced with the append
search help.
The structure of an append search help corresponds to that of a collective
search help, but the append search help takes on the parameters of its
appending object so that it cannot be maintained separately any longer.
Furthermore, an append search help cannot be assigned a search help exit.
An append search help is automatically included in its appending object. The
parameters of the two search helps having the same name are assigned to
each other.
Note: You can also hide modification-free search helps from a collective
search help with an append search help. You have to insert the search help
to be hidden in the append search help and then hide the inclusion there.
The search path(s) defined by this search help are no longer offered in the
appending search help. To cancel this, remove the hidden inclusion again
from the append search help.
Note: Append search helps can also be used themselves to describe an input
help. They are treated like collective search helps.
Note: If the parameters of the appending object change, this change is not
automatically made in the append search help. Instead, you are informed
80. 80
that the parameters of the append search help should be adjusted. In this
case you should check if you want to change the assignments between the
parameters of the append search help and the search helps included in
them.
Procedure: Proceed as follows to enhance a collective search help of the
standard system with your own search paths:
1. For each search path, create an elementary search help in your namespace
and activate these search helps.
2. In display mode, go to the maintenance screen for the collective search help
and choose Goto -> Append search helps. Create the append search help in your
namespace.
3. Include the elementary search help defined in the first step in the append
search help. Maintain the parameter assignments between the parameters of
the append search help and the parameters of the included search helps.
4. Activate the append search help. The append search help is automatically
added to your appending object. The search paths inserted in the append search
help are now available in the collective search help. They appear at the end of
the list of available elementary search helps.
82. 82
What is table maintenance generator?
Table Maintenance Generator ( from now we call it as ‘TMG’) acts as a user interface tool
which is used to create a equipment by which customized tables created by end users can be
changed as required, such as making an entry to that table, deleting an entry etc.
Table maintenance generator is a user interface tool which is used to change the entry of the
table or delete an entry from the table or create an entry for the table.
A table can be maintained in two ways:
1. from any program
2. Using the TMG.
Through whatever we may update the table; the table should have the “Maintenance allowed”
property defined in the attributes.
Transaction Codes:
SE54: Generate Table Maintenance Dialog
SE55: Table view maintenance DDIC call
SE56: Table view display DDIC call
SE57: Deletion of Table Maintenance
83. 83
SM30: Maintenance Table Views:
Implementation of table maintenance generator for a custom table
We will implement the table maintenance generator for a custom table.
Requirement:
A table is having certain no. of fields say field1 to field5. During the maintenance of the table by end-
user, if the user has entered value ‘X’ in field2, then field4 should be enabled and filled with certain value
and field5 should be disabled and if the field2 has value ‘Y’, then field4 should be disabled and field5
should be enabled and filled with certain value.
Go to SE11 and create a table with the fields as per the requirement.
84. 84
In table change mode, click on Utilities and then click on Table maintenance generator.
If the table needs to be maintained by only particular group of people, then the Authorization group
needs to be filled otherwise fill it as &NC&. To maintain the authorization group refer to SU21.
Function group is the name to which the generated maintenance modules will belong to.
Generally Function Group name can be same as table name.
Maintenance can be done in two ways:
1. Maintenance & Overview both on one screen
2. Maintenance on one screen and Overview on another screen.
85. 85
Table entries can be transported with the help of “Dialog data transport details”. If Standard recording
routine is checked, then table entries will be included in Transport request (More information available at
the end of the document). If other is checked the entry won’t be included in the TR.
Click on create on the application tool bar and after generation of TMG without errors click on save.
To disable & enable the fields of the table during maintenance, Maintenance screens need to be
modified during every new entry accordingly. Follow the procedure to achieve the same:
Click on Environment Modification Maintenance Screens & Click on Layout.
In the Layout, Click on Sales Org field and assign the group as ‘ABC’ and for Plant assign group as
‘DEF’.
86. 86
In the PBO, create a Z Module and write the following code:
87. 87
LOOP AT SCREEN.
IF ztestvks-field1 EQ 'X'.
IF screen-group1 = 'DEF'.
screen-input = '0'.
ENDIF.
ELSEIF ztestvks-field1 EQ 'Y'.
IF screen-group1 = 'ABC'.
screen-input = '0'.
ENDIF.
ENDIF.
MODIFY SCREEN.
ENDLOOP.
As per the requirement, for every new entry in the table, the fields should have the constant values
before only. For this purpose, the event needs to be chosen which performs the action. We will go with
“05 creating a new entry”.
List of Events available in Table maintenance
01 Before saving the data in the database
02 After saving the data in the database
03 Before deleting the data displayed
04 After deleting the data displayed
05 Creating a new entry
06 After completely performing the function 'Get original'
07 Before correcting the contents of a selected field
08 After correcting the contents of a selected field
09 After getting the original of an entry
10 After creating the header entries for the change task (E071)
11 After changing a key entry for the change task (E071K)
12 After changing the key entries for the change task (E071K)
13 Exit editing (exit main function module)
14 After lock/unlock in the main function module
15 Before retrieving deleted entries
16 After retrieving deleted entries
17 Do not use. Before print: Event 26
18 After checking whether the data has changed
19 After initializing global variables, field symbols, etc.
20 after input in date sub screen (time-dep. tab. /views)
88. 88
21 Fill hidden fields
22 Go to long text maintenance for other languages
23 Before calling address maintenance screen
24 After restricting an entry (time-dep. tab./views)
25 Individual authorization checks
26 Before creating a list
27 After creation or copying a GUID (not a key field)
28 After entering a date restriction for time-dep. views
AA Instead of the standard data read routine
AB Instead of the standard database change routine
AC Instead of the standard 'Get original' routine
AD Instead of the standard RO field read routine
AE Instead of standard positioning coding
AF Instead of reading texts in other languages
AG Instead of 'Get original' for texts in other languages
AH Instead of DB change for texts in other languages
ST GUI menu main program name
AI Internal use only
89. 89
Click on New Entries tab and Choose 05.
In form routine enter “AT_NEWENTRY” and click on EDITOR.
90. 90
Go to the events and in the form routine: AT_NEWENTRY, write the following code:
LOOP AT SCREEN.
IF ztestvks-field1 EQ 'X'.
IF screen-group1 = 'DEF'.
ztestvks-vkorg = '2011'.
ENDIF.
ELSEIF ztestvks-field1 EQ 'Y'.
IF screen-group1 = 'ABC'.
ztestvks-werks = '1400'.
ENDIF.
ENDIF.
MODIFY SCREEN.
ENDLOOP.
Click on Save & activate and press F3 & F3.
Check the same by adding some entries through SM30:
91. 91
Dialog Data Transport details (Changing the option to “Standard recording routine”):
Values entered in ZTESTVKS through SM30 and clicked on save:
93. 93
Introduction
Search helps are data selection methods used to provide the possible value list for a screen
field. I.e. Search helps are used to provide F4 help for screen fields. The selection logic for the
data to be displayed can be to show the entries from a single table (no coding required) or
even can be complex ABAP code to select the data from different tables which are related or a
combination of both. Thus search helps can be used to show very specific information that
would be required by the user to select an entry from the possible value list.
There are two types of search helps.
3) Elementary search helps: Elementary search help defines a specific search path. The
following components need to be defined for an elementary search help
a) Where to pick the data from (Selection method)
b) What fields have to be considered while selecting the data and what are fields
to be displayed (Search help parameters)
Dialog box of elementary search help
4) Collective Search helps: Collective search helps are a collection of elementary search
helps, thereby providing multiple search paths for a particular field on the screen. The
user can select the required search path and use it to get the desired list. Here too we
can define the input parameters and the output parameters for the search help.
Necessary mapping between the collective search help and the included elementary
search help has to be provided.
94. 94
Dialog box of Collective search help
Creating Elementary Search Helps:
In SE11 give the search help name and click the create button. Choose “Elementary search
help” in the pop up that follows. This takes you to the screen where you enter the details of
the search help.
In the Definition tab you have to enter the following details:
7) Selection method: The table from which the data is to be selected by the search help
for display of possible value list is to be entered here. This is not a mandatory field. If
the selection method is not entered then the data selection (from displaying the
possible value list) will have to be done in the search help exit (explained later).
8) Text Table: This field is non editable. If a text table exists for the selection method
(table) entered then this field is populated automatically.
9) Dialog type: The dialog type defines the steps that are followed by the search help
through the process of displaying the search help. You can select from the following
dialog types:
a) Immediate value display: The possible value list is displayed immediately on
calling the search help.
b) Dialog with value restriction: On calling the search help a dialog box for
restricting the values (Just like a selection screen) selected is displayed first.
This dialog box will have those parameters, which are defined as the import
parameters in the search help parameters.
95. 95
c) Dialog depends on value set: If the possible value list contains less than 100
entries then the list is displayed immediately. If not then this behaves similar to
dialog with value restriction.
As a convention, if the possible value list has very less number of entries we would be
using the first (a) and if the list will have large volume of data we would use options (b)
and (c).
10) Hot key: Hot key (short cut) can be assigned to elementary search help. This can be any
character or digit. This will be used when this elementary search help is used as a part
of the collective search help. (To call a specific elementary search help from a
collective search help enter the following in the field to which the collective search help
is attached “ =<Hot key of the elementary search help> “ and do an F4. For e.g. =A and
press F4, where A is the hotkey for a specific elementary search help).
11) Search help exit: Search help exit is a function module, which is used to modify and
manipulate with the data selection procedure and the selected data. The function
module should have the same interface as the function module
F4IF_SHLP_EXIT_EXAMPLE.
The function module defined as the search help exit will be called at different time
points during the process of data selection by the search help. The different time
points at which this function module is called and the manipulations that are possible
at each time point are explained in detail in a later section.
12) Parameters: Here you define the search help parameters. You can define import
parameters and export parameters for the search help. Following are the
characteristics of the parameters that you would have to define.
a) Checkbox ‘IMP’: If the parameter is an import parameter then check this
checkbox.
b) Checkbox ‘EXP’: If the parameter is an export parameter then check this
checkbox.
96. 96
(Note: A parameter can be both import as well as export parameter depending
on the requirement. See the section Value transfer for input help for knowing
how the import and export parameters transfer values to and from the field to
which the search help is attached).
c) LPOS: This is the position of the parameter in the hit list. If a parameter need
not appear in the hit list then leave this field blank. Note that same position
number cannot occur more than once in a search help.
d) SPOS: This is the position of the parameter in the dialog box for value
restriction. (Selection screen). If a parameter need not appear in the dialog box
then leave this field blank. If no dialog box appears for value restriction then
this field can be left blank for all the parameters. Note that same position
number cannot occur more than once in a search help.
e) SDIS: If this check box is checked then in the dialog box for value restriction, the
parameter will appear as a display only field. The user will be able to see the
value restriction for this field but will not be able to modify the value.
f) Data Element and Checkbox ‘Modified’: A search help parameter should have
an associated data element. This data element will define the output attributes
for the parameter and the help functions (F4 help) for the parameter on the
dialog box for value restriction.
If a table is entered in the “Selection method’ of the search help then the data
element is picked up from the field of the table having the same name. All the
changes that you perform on this field in the database table, those get reflected
in the search help too.
If you want to assign a different data element other than that is defined in the
database table then check the checkbox ‘Modified” for the parameter. Now the
data element field becomes editable and you can enter any required data
element. The new data element should have same data type, length and the
number of decimal places as the previous one. Only difference would be that
the changes that you make to the field in the ‘Selection method’ would not get
reflected in the search help.
g) Default Value: You can enter the default value for the parameter in this field.
97. 97
Once these details are defined, activate the search help. We can test the search help by
doing an ‘F8’ on the maintain search help screen or the display search help screen.
Creating Collective Search Helps:
In SE11 give the search help name and click the create button. Choose “Collective search help”
in the pop up that follows. This takes you to the screen where you enter the details of the
search help.
In the definitions tab enter the following details:
3) Search Help Exit: The use of the search help exit is the same as that in an elementary
search helps. In case of collective search helps the time points at which the exit (FM) is
called is slightly different than in case of elementary search helps.
The different time points at which this function module is called and the manipulations
that are possible at each time point are explained in detail in a later section.
4) Parameters: Just like elementary search helps collective search also has the import and
export parameters. See the section Value transfer for input help for knowing how the
import and export parameters transfer values to and from the field to which the search
help is attached.
In the included search helps tab define the following.
3) List down the elementary search helps that are going to be the part of this collective
search help.
4) Do the parameter assignment for each of the elementary search helps listed. This
procedure actually does a mapping between the parameters of the collective search
help and the individual elementary search helps. The mapping is automatically
proposed by the system but can be changed manually.
98. 98
Once done, activate the search help. The collective search help also can be single tested from
the maintain search help screen or the display search help screen using the ‘F8’ functionality.
Attaching search helps to fields
5) Attaching the search help to a data element.
For attaching the search help to a data element go to further characteristics tab of the
data element through SE11 and enter the search help name in the field provided. Then
map an export parameter of the search help to the data element.
When input help is asked for any field using this data element, the corresponding
search help is triggered. If the user selects a line of the hit list in the input help, the
contents of this parameter are returned to the corresponding screen field. It is not
possible to return several values when the search help is attached to a data element.
6) Attaching the search help to a check table
If a field has check table then the possible values for this field is defined by the contents
of the check table. The key fields of the check table will be automatically present in the
possible value list. If a text table is assigned to the check table then the text will also be
present in the hit list.
99. 99
Attaching a search help to the check table can again modify the hit list obtained from
the check table. Assigning a search help to the check table field can do this. (Through
SE11)
(Place the cursor on the field to which the search help has to be assigned and click on the
button “Search help”)
7) Attaching the search help to a table field
Assign a search help to the table field through SE11 (Refer the above screen shot)
8) Attaching the search help to a screen field
Search help can be assigned to a screen field. In this case the search help assignment is
valid only for that screen.
For dialog screens the assignment can be done through the Screen Painter in the
attributes for the field.
100. 100
In the selection screen of the executable programs the search helps can be assigned to
the parameters and select-options as follows:
Parameter : <PAR> like <field name> matchcode object
<Search help>.
Select-Options:<SEL> for <fieldname> matchcode object
<Search help>.
Value Transport for input helps
If a search help is attached to a screen field directly or through a data element then
only one search help parameter can be assigned to the field. The value transport takes place
between this field and the export parameter of the search help attached to the field.
(Even in this case the search help can have more than one export parameter. The search help
will transfer that field which is the first export parameter defined in the search help)
If the search help is attached to a table field or a check table then the value transport
can take place for more than one field that are linked to the search help through its
parameters. The import parameter of the search help picks up data from that field of the
screen, which has the same name as the search help parameter. If such a field is found then it
copies the data into the respective parameter and if not found then it leaves the parameter
blank. Mapping of the output parameters to the screen fields is similar to the input
parameters. The values are transported to the fields having the same name. Thus data can be
transferred to more than one fields.
101. 101
Using Search help Exits
Search help Exit is just like any other function module and is used to modify the input help
process of any search help. Doing so we can provide very specific information required by the
user for choosing from the hit list. As mentioned earlier search help exits are called at specific
time points of the input help process. The current time point can be obtained from the
Function module parameter callcontrol-step.
Some of the time points at which manipulations with the data will be required most of the
time are:
6) SELONE
This time point occurs (only for collective search helps) before the dialog box for
entering the import parameters are displayed. This can be used for selecting an
elementary search help in the collective search help. This time point occurs only once in
the entire search help process.
The parameter SHLP_TAB has one entry each for all the possible elementary search
helps. If an entry for a specific search help is deleted from SHLD_TAB that search help
will not be offered in the dialog box for selection.
If there is only one entry remaining in SHLP_TAB, then the dialog box for selection can
be skipped by setting the parameter CALLCONTROL-STEP to either ‘PRESEL’ or ‘SELECT’.
7) PRESEL1
Once the search help is selected this event occurs before the interface of the selected
search help is entirely copied. So at this time point you can change the properties of
the interface parameters of the selected search help by changing the Function module
parameter SHLP-INTERFACE.
102. 102
The properties like the screen field to which the search help parameter is attached, the
output field for which the input help is asked etc can be changed at this stage.
8) PRESEL
This time point occurs before the dialog box for value restriction is displayed. At this
time you can predefine the value restriction. This can be done by populating the
function module parameter SHLP-SELOPT.
e.g.
DATA: l_selopt LIKE ddshselopt.
l_selopt-shlpfield = <Name of any import parameter of the search help>.
l_selopt-sign = 'I'.
l_selopt-option = 'EQ'.
l_selopt-low = <Value for the field>.
l_selopt-shlpname = <Search help name>.
APPEND l_selopt TO shlp-selopt.
In the dialog box that appears the above restriction would already be
present. Use can enter any further selections if required.
9) SELECT
This is the time point where the actual selection of the data takes place. If you do not
want the default selection to take place, do the data selection that is required and
populate the same into the function module parameter RECORD_TAB.
For this first select the required data into an internal table and then use the FM
‘F4UT_RESULTS_MAP’.
Pass the following parameters in the above function module.
APPY_RESTRICTIONS = If you have not already applied the value restrictions then the
FM will do it if you pass this parameter as ‘X. SHLP_TAB = This is available in
the exit . Pass the same
103. 103
RECORD_TAB = This is available in the exit . Pass the same
SOURCE_TAB = The internal table into which you have selected the data
Now to skip the standard selection set the function module parameter CALLCONTROL-
STEP to ‘DISP’. If this is not set then the default selection will over ride your data
selection.
10) DISP
This time point occurs before the data is displayed as the hit list. So here you can
manipulate with the parameter RECORD_TAB to change the values to be displayed.
Once you are done with the manipulations with the data if you want to display the data
then do not change CALLCONTROL-STEP.
If you do not want to display the hit list and select one value directly then keep only
that value in the table RECORD_TAB and set the CALLCONTROL-STEP as ‘RETURN’.
If you input help request should be aborted then set the CALLCONTROL-STEP as ‘EXIT’.
If you want to re initiate the whole selection process starting from the dialog box for
value restriction then set CALLCONTROL-STEP as ‘PRESEL’.
Note: Function modules are provided in the function library for operations that are
frequently executed in search help exits. The names of these function modules begin
with the prefix F4UT_. The use of each of these function modules are available in
the documentation of each of these Function modules.
105. 105
CLASSICAL REPORTS
ABAP – Advanced Business Application Programming is a fourth generation
programming language and is used to develop all SAP R/3 applications. Programs In
ABAP can be broadly classified as:-
List/Report Programs
Dynamic/Dialog Programs.
Dynamic/Dialog programming serves as an interface to the SAP R/3 database. Dialog
programs, frequently called as module pools enable the user to interact with the SAP
database. This interaction can be in the form of adding entries, retrieving them for
display or even modifying them. Therefore such programs often act as the front end
to the R/3 database.
106. 106
On the other hand List/Report programs serve as a medium to retrieve large amounts
of data from the R/3 database and process it for display to the user. In addition to this
report programs provide the user with the functionality of downloading the data in a
desired format from SAP to Excel or Notepad for distribution or record purposes.
This document is aimed to introduce the reader to Report Programming in ABAP. It
takes you through the basics of the ABAP Editor (SE38) and into the various aspects of
Report Programming. It provides a small tutorial with screen snapshots to enable the
reader to understand the concepts of Report Programming as well as create his/her
first report program.
Pre-Requisites: The reader should be comfortable with ABAP Data Dictionary,
Language constructs and Working with tables.
INDEX
1. ABAP EDITOR: SE38
2. INCLUDES
3. DEFINITIONS
4. SELECTION SCREEN
5. FORMS
6. EVENTS
7. DISPLAY OPTIONS
8. TEXT ELEMENTS
9. PROCESSING
10. VARIANTS
11. SAMPLE CODE
ABAP EDITOR: SE38
107. 107
The ABAP Editor commonly referred to as SE38 is used for the creation of all Report
Programs. The editor is used for creating/editing the source code for the report
program as well as for the creation of variants, documentation, etc. Each of these will
be covered separately in the chapters to follow.
Let us now begin by creating our very own Report say z_samplereport. As we proceed
by clicking the “Create” button we are presented with a window where we define the
attributes of our report. Some of the basic attributes are explained below.
1. Title: The title provides a brief idea of what the report is designed to do.
2. Type: All reports are of the type “Executable program” (Type 1).
3. Status: The status defines whether the program is a Standard SAP Program or
a Customer Production Program or a Test Program.
4. Application: This refers to the Application Type Area-SD, FI, etc.
5. Authorization Group: This defines the Authorization Group to which a report is
assigned. This plays an important role when the system has to check whether
the user is authorized to execute a program or edit a program.
6. Editor Lock: This option provides the functionality of preventing other users
from making changes to the program.
108. 108
Once these attributes are set, we proceed by saving the report. This brings us to the
main editor page of the report. This is where we write the code for the program.
The first line always contains the report name. We now define the line size and line
count for the report. We also include the NO STANDARD PAGE HEADING line so as to
suppress the list heading or name of the program. For displaying error / warning /
information messages, we define the message class which is maintained via
transaction SE91.
Thus an ideal report program would begin as:-
Report <report name> NO STANDARD PAGE HEADING
LINE-SIZE <size>
LINE-COUNT <n(n1)>
MESSAGE-ID <message class>.
INCLUDES
109. 109
The Includes are reports of the type “Include Program”. These are used to separate
the definitions for the program and the actual code consisting of the select queries
and other presentation logic. The definitions are generally written in the top include
and the queries and other logic goes into the forms include. However there is no
standard naming convention for these includes and the names vary according to the
project standards.
Also, the use of includes is optional. If the program is a simple report with no complex
queries and few definitions, the entire code including the definitions & logic can be
written together in the main program itself. However the use of includes is a good
coding practice and aides in maintenance of code and debugging.
DEFINITIONS
110. 110
The definition part of the code basically includes the list of tables which will be used in
the report. This is followed by the definitions of internal tables, constants & other
variables which will be used in the course of the report.
We now come to the definition of the Selection Screen - the interface between the
user and program. It is here that the user specifies the input values for which the
report should be executed.
SELECTION SCREEN
111. 111
The syntax for defining the selection screen is as follows.
SELECTION-SCREEN BEGIN OF SCREEN <SCREEN #>
SELECTION-SCREEN BEGIN OF BLOCK <#> WITH FRAME TITLE <TEXT>
………
………
SELECTION-SCREEN END OF BLOCK <#>
SELECTION-SCREEN END OF SCREEN <SCREEN #>
The Selection Screen basically comprises of 2 main components:
Select Options
Parameters
SELECT OPTIONS:
A select option can be used to input a range of values or a set of values to the
program.
The syntax for defining a select option like the field of a table is as follows.
SELECT-OPTIONS: s_name FOR Table-Field.
Eg: SELECT-OPTIONS: s_bukrs FOR lfb1-bukrs.
A Select Option can be made mandatory by using the following syntax.
SELECT-OPTIONS: s_name FOR Table-Field OBLIGATORY.
112. 112
Eg: SELECT-OPTIONS: s_bukrs FOR lfb1-bukrs OBLIGATORY.
The above illustration shows how a select option would look like for the definition
stated in the example.
PARAMETERS:
A parameter on the other hand can accept one single value for the course of
execution of the program.
The syntax for defining a parameter like the field of a table is as follows.
PARAMETERS: p_name LIKE Table-Field.
Eg: PARAMETERS: p_lifnr LIKE lfb1-lifnr.
As explained in the case of select options, a parameter can also be made
obligatory by use of the OBLIGATORY syntax.
A select option can be used as a parameter by using the following syntax.
SELECT-OPTIONS: s_name FOR Table-Field NO INTERVALS
NO- EXTENSIONS.
The above illustration shows how a parameter would look like for the definition
stated in the example.
We can assign a default value to both select options and parameters by using the
DEFAULT <VALUE> tag after the definition.
FORMS
113. 113
The forms generally contain the functions containing the select queries based on the
values input on the selection screen. These functions will be called from the main
program once the report is executed.
The forms also contain the logic for displaying the data fetched from the database by
the report program. This will be dealt in detail in the following sections.
EVENTS
114. 114
The events in a report program basically define the order in which the code is
executed.
Following are the basic events in any report program:
1. LOAD-OF-PROGRAM: This event triggers the associated event in an internal
session after loading the program.
2. INITIALIZATION: This event is used for filling in values in the selection screen at
runtime. Basically, all values are initialized during the course of this event
3. AT SELECTION-SCREEN: Validation checks for input occur during this event.
4. START-OF-SELECTION: This event triggers the start of selection of data from
the database tables. All functions involving select queries are called during this
event. Once the requisite data is fetched, it is modified/customized as per the
requirements and then finally prepared for display.
5. END-OF-SELECTION: This event causes all fetched data to be displayed on the
screen. All functions associated with displaying the fetched data are called
during this event.
List Processing also occurs during End of Selection. Events during List
Processing include the following:
TOP-OF-PAGE
NEW PAGE
END-OF-PAGE
115. 115
DISPLAY OPTIONS
There are primarily 2 ways of displaying data fetched by a report.
“WRITE” statements
ALV List/Grid
WRITE STATEMENTS:
Following is the syntax for using write statements.
WRITE : / '|'.
WRITE AT 5: 'TITLE 1'.
WRITE AT 15 : '|'.
WRITE AT 20 :'TITLE 2'.
WRITE AT 35 : '|'.
WRITE AT 40 :'TITLE 3'.
WRITE AT 60 : '|'.
WRITE AT 65 :'TITLE 4'.
WRITE AT 75: '|'.
WRITE AT 80: 'TITLE 5'.
WRITE AT 90: '|'.
LOOP AT TABLE.
WRITE : / '|'.
WRITE AT 5: Table-Field.
WRITE AT 15 : '|'.
WRITE AT 20 :Table-Field.
WRITE AT 35 : '|'.
WRITE AT 40 :Table-Field.
WRITE AT 60 : '|'.
WRITE AT 65 :Table-Field.
WRITE AT 75: '|'.
WRITE AT 80: Table-Field.
WRITE AT 90: '|'.
ENDLOOP.
Additional formatting options available with WRITE options are use of different colors,
intensifying text and hotspots.
Hotspots: When one drags the mouse over the lines of data where hotspots are
activated, the cursor changes to a hand with an outstretched index finger. Hotspots
can be used for adding additional features such as redirection to tables, transactions,
etc.
116. 116
The above screenshot shows an example of how a report developed using write
statements would look like.
However, it is a cumbersome task to design the output layout using write statements
especially when the amount of data being displayed is huge and display requirements
are complex. This also affects the readability of the report. Hence this method is
preferred only for small simple reports.
ALV-LIST/GRID:
SAP provides a list of ALV (ABAP List Viewer) function modules which can enhance the
functionality and readability of a report. Hence ALV is generally preferred for all
report displays. ALV also provides added functionalities like dynamic sorting of report
output and rearranging columns in the report output.
ALV’s are generally of 3 types:
1. List /SimpleALV
2. Grid/Block ALV
3. Hierarchical Sequential Report
117. 117
The above illustration shows how an ALV Grid display would look like. However the
procedure for generating an ALV is beyond the scope of this document.
TEXT ELEMENTS
There are 3 different types of text elements:
1. LIST HEADINGS:
These are used to make dynamic List headings
118. 118
2. SELECTION TEXTS:
These are used to give names to the select-options, parameters and block
titles used in the selection screen.
119. 119
3. TEXT SYMBOLS:
Text symbols are used for printing texts on the selection screen or in the
report output. The use of selection texts is considered to be a good
programming practice as it serves as a substitute for hard-coding.Text symbols
also provides multi-lingual support.
120. 120
PROCESSING THE REPORT
Once we are done with the coding, we check the report for any syntactic errors. The
editor displays the errors if any along with the line numbers and the suggested
correction.
Check the illustration below.
121. 121
Once the report is found to be syntactically correct, we activate it. On activation, the
program is checked & an active version of the report is saved. Once the report is
activated, it is ready for processing.
On direct processing, the report is executed. Thus, the selection screen will be
displayed prompting the user to input the values for selection. Pressing the F4 Key
gives the user a list of possible values for that particular field
122. 122
Once the user has entered the desired values, the report is executed.
On execution, the data is fetched from the data base and displayed to the user.
VARIANTS
A variant is a saved version of the input data filled into the selection screen. At
runtime, the variant can directly be selected. This removes the need to manually
enter the data in the selection screen over and over again. This generally helps when
we are testing a report for a particular set of values. Check the illustrations below for
the procedure to create a variant.
123. 123
Once we have created the variants, they can be directly selected from the list of
available variants displayed on the selection screen.
124. 124
Types of Internal Tables
1. Overview
This document highlights performance issues related to the 3 different kinds of internal tables:
Standard table
Sorted Table
Hashed Table
It emphasizes how the selection of either of these tables, subject to functional requirements
and limitations, can affect the performance and execution time of our code.
125. 125
2. Types of Internal Tables in ABAP/4
The table type defines how ABAP accesses individual table entries. There are three kinds of
internal table types:
o Standard table: A standard table has an internal logical index. You can access it either using
the index or using its key (refer to Appendix A for notes on KEY). If you use key access, the
response time is in linear relation to the number of table entries. The key of a standard
table is always non-unique. You cannot use the UNIQUE KEY addition in the definition of a
standard table.
o Sorted table: A sorted table is always stored correctly sorted by its key. Like standard
tables, they also have a linear index, and you can access them using either the index or
their key. If you use key access, the response time is in logarithmic relation to the number
of table entries, since the system uses a binary search. The key of a sorted table may be
either unique or non-unique, and you must use one of the additions UNIQUE or NON-
UNIQUE when you specify the key.
Standard tables and sorted tables are generically known as index tables.
o Hashed tables: Hashed tables do not have a logical index. You can only access a hashed
table using its key. The response time is therefore independent of the number of table
entries, since the system uses a hash algorithm to access the entries. The key of a hashed
table must be unique, so you must always use the UNIQUE addition when creating the
table.
126. 126
Standard Sorted Hashed
Index type Logical Logical No Index
Access Type Index/Key Index/Key Key
Response time Linear Logarithmic Constant
Key Type Non-unique Unique/Non-Unique Unique
3. Choosing a Table Type
The table type that you use in a particular situation will depend on which of the typical internal
table operations listed above will be used with the table, and how often.
Standard Tables
This table type is most appropriate when you intend to address the table entries using the
index. This is the quickest way to access entries in a standard table. You should fill standard
tables using the APPEND statement, and read, modify, and delete entries using the index
(INDEX addition to the corresponding ABAP statement). If you use the key to access a standard
table, the access time increases in linear relation to the number of entries. If you need to use
key entries, standard tables are suitable if you can separate filling the table from the remaining
table processing. For example, you can fill a standard table by appending entries, and then sort
it. If you then use key access with the BINARY SEARCH option, the response time is only in
logarithmic relation to the number of table entries.
You should use index operations to access standard tables. For the sake of compatibility, you
can use TABLE as a synonym of STANDARD TABLE
Sorted Tables
This table type is suitable for tables that must be correctly sorted even while you are filing
them. You fill a sorted table using the INSERT ... INTO TABLE statement, observing the sort
sequence defined in the key. When you access the table using its key, the response time is in
logarithmic relation to the number of table entries, since the system automatically uses a
binary search. Sorted tables are particularly useful for partial sequential processing in a LOOP if
you can specify a portion of the table key starting from the left in the WHERE condition.
Hashed Tables
Hashed tables are useful if the main operation on the table is going to be key access. You
cannot access a hashed table using index access. However, the response time for key access is
constant, regardless of the number of table entries. Like database tables, hashed tables always
127. 127
have a unique key. Hashed tables are therefore useful for constructing and processing internal
tables that resemble database tables.
4. General Performance Notes for Internal Tables
4.1 Index Management
As soon as you change an internal table using INSERT, DELETE or SORT, the logical sequence of
the table entries will no longer correspond with the physical sequence in the memory. When
this happens, the system creates a logical index, which also requires memory. Furthermore,
each INSERT or DELETE statement requires further memory. If your internal table is very large,
changing the index can result in significantly increased runtime.
The system does not administer secondary indexes for internal tables.
4.2 Filling Line-by-line
Unlike filling a table using the INSERT statement, using APPEND does not cost runtime in terms
of maintaining the index. If the sequence of the entries is unimportant, or they are already in
the correct order, you should use APPEND instead of INSERT.
4.3 Points to Remember
Functional
Only STANDARD tables are allowed as TABLES parameters in FM’s.
Performance
1. The runtime required to sort an internal table increases with the number of entries and the
length of the sort key.
2. Sorting an internal table with 100 entries with a 50 byte key requires about 1300 msn
(standardized microseconds). Using a 30-byte key, the runtime is about 950 msn.
3. If one of the specified sort criteria is itself an internal table, SORT may sometimes take
much longer.
Example 1: Declaration of hashed internal table with a unique key.
DATA: BEGIN OF tb_itab,
col1 TYPE i,
col2 TYPE c,
END OF tb_itab.
DATA itab LIKE HASHED TABLE OF tb_line WITH UNIQUE KEY col1.
And similarly we can declare internal tables as sorted or standard. Standard table are the
default tables created, i.e.
128. 128
DATA itab LIKE STANDARD TABLE OF tb_line.
Is equivalent to
DATA itab LIKE tb_line.
5. Various tables operations w.r.t to types of internal tables
5.1 INSERT - Insert into an Internal Table
INSERT [wa INTO|INITIAL LINE INTO] TABLE itab.
The way in which the system inserts a new entry into the table depends on the table type:
o Standard Table: The new entry is added to the end of the table. Generic insertion is
therefore the same as an APPEND.
o Sorted Table: The new entry is added in its appropriate place, determined by the table
key. The key values are taken from the specified work area wa or from the header line
of the table. If the key is NON-UNIQUE, the entry is placed at the top of the list of
duplicates. The insertion point is determined internally using a binary search. This
makes the relationship between the runtime required and the number of table entries
logarithmic.
o Hashed Table: The new entry is placed in the internal hash administration of the table
according to the table key. The key values are taken from the specified work area wa or
the header line of the table. The runtime required remains constant, since it does not
depend on the number of table entries. The key must be unique.
Insert in a Sorted Table with Unique Key Insert in Hashed Table with Unique Key
* Entries: 1000, Duplicates: 250
* Line width: 100, Key width: 20
* ITAB2 takes 750 entries with unique key K
REFRESH ITAB2.
LOOP AT ITAB1 INTO WA.
INSERT WA INTO TABLE ITAB2.
IF SY-SUBRC <> 0.
" ...
ENDIF.
ENDLOOP.
* Entries: 1000, Duplicates: 250
* Line width: 100, Key width: 20
* ITAB2 takes 750 entries with unique key K
REFRESH ITAB2.
LOOP AT ITAB1 INTO WA.
INSERT WA INTO TABLE ITAB2.
IF SY-SUBRC <> 0.
" ...
ENDIF.
ENDLOOP.
4,337 2637