ABAP/4 programs can take a very long time to execute, and can make other processes have to wait before executing. Here are some tips to speed up your programs and reduce the load your programs put on the system:
Use the GET RUN TIME command to help evaluate performance. It's hard to know whether that optimization technique REALLY helps unless you test it out. Using this tool can help you know what is effective, under what kinds of conditions. The GET RUN TIME has problems under multiple CPUs, so you should use it to test small pieces of your program, rather than the whole program.
Generally, try to reduce I/O first, then memory, then CPU activity. I/O operations that read/write to hard disk are always the most expensive operations. Memory, if not controlled, may have to be written to swap space on the hard disk, which therefore increases your I/O read/writes to disk. CPU activity can be reduced by careful program design, and by using commands such as SUM (SQL) and COLLECT (ABAP/4).
Avoid 'SELECT *', especially in tables that have a lot of fields. Use SELECT A B C INTO instead, so that fields are only read if they are used. This can make a very big difference.
Field-groups can be useful for multi-level sorting and displaying. However, they write their data to the system's paging space, rather than to memory (internal tables use memory). For this reason, field-groups are only appropriate for processing large lists (e.g. over 50,000 records). If you have large lists, you should work with the systems administrator to decide the maximum amount of RAM your program should use, and from that, calculate how much space your lists will use. Then you can decide whether to write the data to memory or swap space. See the Fieldgroups ABAP example.
Use as many table keys as possible in the WHERE part of your select statements.
Whenever possible, design the program to access a relatively constant number of records (for instance, if you only access the transactions for one month, then there probably will be a reasonable range, like 1200-1800, for the number of transactions inputted within that month). Then use a SELECT A B C INTO TABLE ITAB statement.
Get a good idea of how many records you will be accessing. Log into your productive system, and use SE80 -> Dictionary Objects (press Edit), enter the table name you want to see, and press Display. Go To Utilities -> Table Contents to query the table contents and see the number of records. This is extremely useful in optimizing a program's memory allocation.
Try to make the user interface such that the program gradually unfolds more information to the user, rather than giving a huge list of information all at once to the user.
Declare your internal tables using OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to be accessing. If the number of records exceeds NUM_RECS, the data will be kept in swap space (not memory).
Use SELECT A B C INTO TABLE ITAB whenever possible. This will read all of the records into the itab in one operation, rather than repeated operations that result from a SELECT A B C INTO ITAB... ENDSELECT statement. Make sure that ITAB is declared with OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to access.
If the number of records you are reading is constantly growing, you may be able to break it into chunks of relatively constant size. For instance, if you have to read all records from 1991 to present, you can break it into quarters, and read all records one quarter at a time. This will reduce I/O operations. Test extensively with GET RUN TIME when using this method.
Know how to use the 'collect' command. It can be very efficient.
Use the SELECT SINGLE command whenever possible.
Many tables contain totals fields (such as monthly expense totals). Use these avoid wasting resources by calculating a total that has already been calculated and stored.
Showing posts with label Reports Basics. Show all posts
Showing posts with label Reports Basics. Show all posts
Saturday, October 11, 2008
abap type key ward
TYPES - Defining an Internal Table Type
Variants:
1. TYPES itabtype {TYPE tabkind OF linetype|
LIKE tabkind OF lineobj}
[WITH [UNIQUE|NON-UNIQUE] keydef[INITIAL SIZE n].
2. TYPES itabtype TYPE RANGE OF type.
TYPES itabtype LIKE RANGE OF f.
3. TYPES itabtype {TYPE linetype|LIKE lineobj} OCCURS n.
Effect
Defines a user-defined type (abap type concept for an internal table
Variant 1
TYPES itabtype {TYPE tabkind OF linetype|
LIKE tabkind OF lineobj}
[WITH [UNIQUE|NON-UNIQUE] keydef] [INITIAL SIZE n].
Effect
Defines the type itabtype for an internal table without header line in a program with table type tabkind and line type linetype (if you use a TYPE reference) or the type of the referred object lineobj (if you use a LIKE reference). Internal tables without a header line consist of any number of table lines, each of which has the structure defined by the line type.
You may also define a table key. If you do not, the system creates a generic table type with any key. You can use generic types to specify the type of generic subroutine parameters.
The UNIQUE and NON-UNIQUE additions allow you to specify whether a table with type itabtype may contain two or more records with the same key or not. The following rules apply:
* STANDARD TABLE:
The key is always NON-UNIQUE by default. You cannot use the UNIQUE addition with a standard table.
* SORTED TABLE:
There is no default setting for sorted tables. If you do not specify UNIQUE or NON-UNIQUE, the system creates a generic table type without a particular uniqueness attribute. You can use generic types to specify the types of generic subroutine parameters.
* HASHED TABLE:
There is no default setting for hashed tables. However, you must define a UNIQUE key. The NON-UNIQUE addition is not permitted.
The optional INITIAL SIZE addition allows you to specify how much memory should be allocated to the table when you create it. This corresponds to the OCCURS specification in variant 2 (see also Performance Notes for Internal Tables). The value n is not taken into consideration in the type check.
Example
The following type definitions define tables using the line type STRUC and the key NAME:
TYPES: BEGIN OF STRUC,
NAME(10) TYPE C,
AGE TYPE I,
END OF STRUC.
TYPES: TAB1 TYPE STANDARD TABLE OF STRUC WITH DEFAULT KEY,
TAB2 TYPE SORTED TABLE OF STRUC
WITH NON-UNIQUE KEY NAME,
TAB3 TYPE HASHED TABLE OF STRUC WITH UNIQUE KEY NAME.
Unlike the above types, the following types are generic. This means that you can use them to specify the type of a generic subroutine parameter, but not to create a table object uisng the DATA statement. The only exception to this is that the system allows you to use a generic standard table type in a DATA statement - the type description is completed automatically by the system according to the rules described under DATA.
TYPES: GEN_TAB1 TYPE STANDARD TABLE OF STRUC,
GEN_TAB2 TYPE SORTED TABLE OF STRUC WITH KEY NAME,
GEN_TAB3 TYPE HASHED TABLE OF STRUC.
The following example shows the definition of a sorted table using a LIKE reference to the ABAP Dictionary structure SFLIGHT:
TYPES: FLTAB LIKE SORTED TABLE OF SFLIGHT
WITH NON-UNIQUE KEY CARRID CONNID FLDATE.
Variant 2
TYPES itabtype TYPE RANGE OF type. TYPES itabtype LIKE RANGE OF f.
Addition:
... INITIAL SIZE n
Effect
Crates a table type itab with table type STANDARD. The line type is a structure, made up as follows:
SIGN(1) TYPE C
OPTION(2) TYPE C
LOW TYPE type or LIKE f
HIGH TYPE type or LIKE f
Addition
...INITIAL SIZE n
Effect
INITIAL SIZE specifies how many lines of the table are created along with the table. The table size increases dynamically as required - for further information, refer to Performance Notes for Internal Tables. The INITIAL SIZE value has no semantic meaning except in the APPEND SORTED BY statement. If you do not specify an INITIAL SIZE, the system uses 0 as the default value.
Variant 3
TYPES itabtype {TYPE linetype|LIKE lineobj} OCCURS n.
Defines the type itabtype as the type for a standard table without a header line. The key is the default key for internal tables.
This variant is the same as the following type definition:
TYPES itabtype {TYPE STANDARD TABLE OF linetype|
LIKE STANDARD TABLE OF lineobj}
WITH DEFAULT KEY INITIAL SIZE n.
Note
Type names
A type name can be up to 30 characters long. The name may only consist of alphanumeric characters and the underscore character. It may not consist entirely of digits. Special characters such as German umlauts are not allowed. As well as these characters, certain special characters are used internall. However, these should not be used in application programs. SPACE is a reserved name, and cannot therefore be used. Furthermore, you should not use a field in a statement if it has the same name as one of the additions of the keyword (for example: PERFORM SUB USING CHANGING.).
Recommendations for Type Names:
1. Always start the name with a letter.
2. Use the underscore to separate compound names (for example, NEW_PRODUCT).
Variants:
1. TYPES itabtype {TYPE tabkind OF linetype|
LIKE tabkind OF lineobj}
[WITH [UNIQUE|NON-UNIQUE] keydef[INITIAL SIZE n].
2. TYPES itabtype TYPE RANGE OF type.
TYPES itabtype LIKE RANGE OF f.
3. TYPES itabtype {TYPE linetype|LIKE lineobj} OCCURS n.
Effect
Defines a user-defined type (abap type concept for an internal table
Variant 1
TYPES itabtype {TYPE tabkind OF linetype|
LIKE tabkind OF lineobj}
[WITH [UNIQUE|NON-UNIQUE] keydef] [INITIAL SIZE n].
Effect
Defines the type itabtype for an internal table without header line in a program with table type tabkind and line type linetype (if you use a TYPE reference) or the type of the referred object lineobj (if you use a LIKE reference). Internal tables without a header line consist of any number of table lines, each of which has the structure defined by the line type.
You may also define a table key. If you do not, the system creates a generic table type with any key. You can use generic types to specify the type of generic subroutine parameters.
The UNIQUE and NON-UNIQUE additions allow you to specify whether a table with type itabtype may contain two or more records with the same key or not. The following rules apply:
* STANDARD TABLE:
The key is always NON-UNIQUE by default. You cannot use the UNIQUE addition with a standard table.
* SORTED TABLE:
There is no default setting for sorted tables. If you do not specify UNIQUE or NON-UNIQUE, the system creates a generic table type without a particular uniqueness attribute. You can use generic types to specify the types of generic subroutine parameters.
* HASHED TABLE:
There is no default setting for hashed tables. However, you must define a UNIQUE key. The NON-UNIQUE addition is not permitted.
The optional INITIAL SIZE addition allows you to specify how much memory should be allocated to the table when you create it. This corresponds to the OCCURS specification in variant 2 (see also Performance Notes for Internal Tables). The value n is not taken into consideration in the type check.
Example
The following type definitions define tables using the line type STRUC and the key NAME:
TYPES: BEGIN OF STRUC,
NAME(10) TYPE C,
AGE TYPE I,
END OF STRUC.
TYPES: TAB1 TYPE STANDARD TABLE OF STRUC WITH DEFAULT KEY,
TAB2 TYPE SORTED TABLE OF STRUC
WITH NON-UNIQUE KEY NAME,
TAB3 TYPE HASHED TABLE OF STRUC WITH UNIQUE KEY NAME.
Unlike the above types, the following types are generic. This means that you can use them to specify the type of a generic subroutine parameter, but not to create a table object uisng the DATA statement. The only exception to this is that the system allows you to use a generic standard table type in a DATA statement - the type description is completed automatically by the system according to the rules described under DATA.
TYPES: GEN_TAB1 TYPE STANDARD TABLE OF STRUC,
GEN_TAB2 TYPE SORTED TABLE OF STRUC WITH KEY NAME,
GEN_TAB3 TYPE HASHED TABLE OF STRUC.
The following example shows the definition of a sorted table using a LIKE reference to the ABAP Dictionary structure SFLIGHT:
TYPES: FLTAB LIKE SORTED TABLE OF SFLIGHT
WITH NON-UNIQUE KEY CARRID CONNID FLDATE.
Variant 2
TYPES itabtype TYPE RANGE OF type. TYPES itabtype LIKE RANGE OF f.
Addition:
... INITIAL SIZE n
Effect
Crates a table type itab with table type STANDARD. The line type is a structure, made up as follows:
SIGN(1) TYPE C
OPTION(2) TYPE C
LOW TYPE type or LIKE f
HIGH TYPE type or LIKE f
Addition
...INITIAL SIZE n
Effect
INITIAL SIZE specifies how many lines of the table are created along with the table. The table size increases dynamically as required - for further information, refer to Performance Notes for Internal Tables. The INITIAL SIZE value has no semantic meaning except in the APPEND SORTED BY statement. If you do not specify an INITIAL SIZE, the system uses 0 as the default value.
Variant 3
TYPES itabtype {TYPE linetype|LIKE lineobj} OCCURS n.
Defines the type itabtype as the type for a standard table without a header line. The key is the default key for internal tables.
This variant is the same as the following type definition:
TYPES itabtype {TYPE STANDARD TABLE OF linetype|
LIKE STANDARD TABLE OF lineobj}
WITH DEFAULT KEY INITIAL SIZE n.
Note
Type names
A type name can be up to 30 characters long. The name may only consist of alphanumeric characters and the underscore character. It may not consist entirely of digits. Special characters such as German umlauts are not allowed. As well as these characters, certain special characters are used internall. However, these should not be used in application programs. SPACE is a reserved name, and cannot therefore be used. Furthermore, you should not use a field in a statement if it has the same name as one of the additions of the keyword (for example: PERFORM SUB USING CHANGING.).
Recommendations for Type Names:
1. Always start the name with a letter.
2. Use the underscore to separate compound names (for example, NEW_PRODUCT).
PERFORMENCE TIPS
ABAP/4 programs can take a very long time to execute, and can make other processes have to wait before executing. Here are some tips to speed up your programs and reduce the load your programs put on the system:
• Use the GET RUN TIME command to help evaluate performance. It's hard to know whether that optimization technique REALLY helps unless you test it out. Using this tool can help you know what is effective, under what kinds of conditions. The GET RUN TIME has problems under multiple CPUs, so you should use it to test small pieces of your program, rather than the whole program.
• Generally, try to reduce I/O first, then memory, then CPU activity. I/O operations that read/write to hard disk are always the most expensive operations. Memory, if not controlled, may have to be written to swap space on the hard disk, which therefore increases your I/O read/writes to disk. CPU activity can be reduced by careful
program design, and by using commands such as SUM (SQL) and COLLECT (ABAP/4).
• Avoid 'SELECT *', especially in tables that have a lot of fields. Use SELECT A B C INTO instead, so that fields are only read if they are used. This can make a very big difference.
• Field-groups can be useful for multi-level sorting and displaying. However, they write their data to the system's paging space, rather than to memory (internal tables use memory). For this reason, field-groups are only appropriate for processing large lists (e.g. over 50,000 records)
. If you have large lists, you should work with the systems administrator to decide the maximum amount of RAM your program should use, and from that, calculate how much space your lists will use. Then you can decide whether to write the data to memory or swap space.
• Use as many table keys as possible in the WHERE part of your select statements.
• Whenever possible, design the program to access a relatively constant number of records (for instance, if you only access the transactions for one month, then there probably will be a reasonable range, like 1200-1800, for the number of transactions inputted within that month). Then use a SELECT A B C INTO TABLE ITAB statement.
• Get a good idea of how many records you will be accessing. Log into your productive system, and use SE80 -> Dictionary Objects (press Edit), enter the table name you want to see, and press Display. Go To Utilities -> Table Contents to query the table contents and see the number of records. This is extremely useful in optimizing a program's memory allocation.
• Try to make the user interface such that the program gradually unfolds more information to the user, rather than giving a huge list of information all at once to the user.
• Declare your internal tables using OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to be accessing. If the number of records exceeds NUM_RECS, the data will be kept in swap space (not memory).
• Use SELECT A B C INTO TABLE ITAB whenever possible. This will read all of the records into the itab in one operation, rather than repeated operations that result from a SELECT A B C INTO ITAB... ENDSELECT statement. Make sure that ITAB is declared with OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to access.
• If the number of records you are reading is constantly growing, you may be able to break it into chunks of relatively constant size. For instance, if you have to read all records from 1991 to present, you can break it into quarters, and read all records one quarter at a time. This will reduce I/O operations.
Test extensively with GET RUN TIME when using this method.
• Know how to use the 'collect' command. It can be very efficient.
• Use the SELECT SINGLE command whenever possible.
• Many tables contain totals fields (such as monthly expense totals). Use these avoid wasting resources by calculating a total that has already been calculated and stored.
• Use the GET RUN TIME command to help evaluate performance. It's hard to know whether that optimization technique REALLY helps unless you test it out. Using this tool can help you know what is effective, under what kinds of conditions. The GET RUN TIME has problems under multiple CPUs, so you should use it to test small pieces of your program, rather than the whole program.
• Generally, try to reduce I/O first, then memory, then CPU activity. I/O operations that read/write to hard disk are always the most expensive operations. Memory, if not controlled, may have to be written to swap space on the hard disk, which therefore increases your I/O read/writes to disk. CPU activity can be reduced by careful
program design, and by using commands such as SUM (SQL) and COLLECT (ABAP/4).
• Avoid 'SELECT *', especially in tables that have a lot of fields. Use SELECT A B C INTO instead, so that fields are only read if they are used. This can make a very big difference.
• Field-groups can be useful for multi-level sorting and displaying. However, they write their data to the system's paging space, rather than to memory (internal tables use memory). For this reason, field-groups are only appropriate for processing large lists (e.g. over 50,000 records)
. If you have large lists, you should work with the systems administrator to decide the maximum amount of RAM your program should use, and from that, calculate how much space your lists will use. Then you can decide whether to write the data to memory or swap space.
• Use as many table keys as possible in the WHERE part of your select statements.
• Whenever possible, design the program to access a relatively constant number of records (for instance, if you only access the transactions for one month, then there probably will be a reasonable range, like 1200-1800, for the number of transactions inputted within that month). Then use a SELECT A B C INTO TABLE ITAB statement.
• Get a good idea of how many records you will be accessing. Log into your productive system, and use SE80 -> Dictionary Objects (press Edit), enter the table name you want to see, and press Display. Go To Utilities -> Table Contents to query the table contents and see the number of records. This is extremely useful in optimizing a program's memory allocation.
• Try to make the user interface such that the program gradually unfolds more information to the user, rather than giving a huge list of information all at once to the user.
• Declare your internal tables using OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to be accessing. If the number of records exceeds NUM_RECS, the data will be kept in swap space (not memory).
• Use SELECT A B C INTO TABLE ITAB whenever possible. This will read all of the records into the itab in one operation, rather than repeated operations that result from a SELECT A B C INTO ITAB... ENDSELECT statement. Make sure that ITAB is declared with OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to access.
• If the number of records you are reading is constantly growing, you may be able to break it into chunks of relatively constant size. For instance, if you have to read all records from 1991 to present, you can break it into quarters, and read all records one quarter at a time. This will reduce I/O operations.
Test extensively with GET RUN TIME when using this method.
• Know how to use the 'collect' command. It can be very efficient.
• Use the SELECT SINGLE command whenever possible.
• Many tables contain totals fields (such as monthly expense totals). Use these avoid wasting resources by calculating a total that has already been calculated and stored.
SAP ABAP INTERNAL TABLES IN BRIEF
Purpose of Internal Tables
• In ABAP/4, you work mainly with tables. Tables are the essential data structures in the R/3 System. Long-life data is stored in relational database tables.
• Besides database tables, you can create internal tables which exist only during the runtime of your program. ABAP/4 provides various operations for working with internal tables. You can, for example, search for, append, insert, or delete lines.
• The number of lines in an internal table is not fixed. Depending on requirements, the system increases the size of internal tables at runtime.
• You can use internal tables to perform table calculations on subsets of database tables. For example, you can read a certain part of a database table into an internal table (see Reading Data into an Internal Table).
From the internal table, you can then calculate totals or generate a ranked list.
• Another use for internal tables is reorganizing the contents of database tables according to the needs of your program. For example, you can read data relevant for creating a telephone list from one or several large customer tables into an internal table. During the runtime of your program, you can then access this list directly without having to perform a time-consuming database query for each call.
Structure of Internal Tables
In ABAP/4, you can distinguish between internal table data types, which define the structure of internal tables, and internal table data objects, which are the actual internal tables and can be filled with data. An internal table data type is an abstract definition of a data structure which can be used to declare data objects as internal tables.
Data type
An internal table is one of the two structured data types in ABAP/4. The other structured data type is the field string. An internal table consists of any number of lines which all have the same data type. The data type of the lines can be elementary or structured.
This definition opens a variety of internal table structures which range from lines consisting of one field to lines consisting of field strings which have internal tables as components.
You can define a data type as an internal table by using the TYPES statement with the OCCURS parameter. No memory is occupied when defining a data type.
Data object
A data object which has a data type defined as an internal table is the actual internal table you work with. It occupies memory and you can fill or read its lines.
You create a data object as an internal table by using the DATA statement either with the OCCURS parameter or by referring to another internal table by using the TYPE or LIKE parameters.
Identifying Table Lines
In order to access a certain line of a table, you must specify a field or combination of fields that can be used to identify the line. In the relational data model which is used to store long-life data in the R/3 System, the minimum combination required for this purpose is known as the key. The fields that define the key are called key fields.
Internal Table Index
The index is the sequential number of a table line. It is not a table field, but is created and managed automatically by the system.
You can use the index with the DELETE, INSERT, MODIFY, LOOP, and READ statements. In these statements, you can specify the index either as literal or as variable.
After processing a particular line of an internal table, the system field SY-TABIX generally contains the index of that line.
Internal Table Key
There are two kinds of internal table keys.
Self-defined Key
When reading lines from an internal table using the READ statement, you can specify a self-defined.
Standard Key
By definition, the key fields of an internal table are those fields which are not numeric (type F, I, and P) and are not internal tables. These key fields form the standard key of an internal table.
To obtain the standard key of an internal tables with nested structures (table lines which contain field strings as components), the system breaks down the sub-structures to the level of elementary fields.
• In ABAP/4, you work mainly with tables. Tables are the essential data structures in the R/3 System. Long-life data is stored in relational database tables.
• Besides database tables, you can create internal tables which exist only during the runtime of your program. ABAP/4 provides various operations for working with internal tables. You can, for example, search for, append, insert, or delete lines.
• The number of lines in an internal table is not fixed. Depending on requirements, the system increases the size of internal tables at runtime.
• You can use internal tables to perform table calculations on subsets of database tables. For example, you can read a certain part of a database table into an internal table (see Reading Data into an Internal Table).
From the internal table, you can then calculate totals or generate a ranked list.
• Another use for internal tables is reorganizing the contents of database tables according to the needs of your program. For example, you can read data relevant for creating a telephone list from one or several large customer tables into an internal table. During the runtime of your program, you can then access this list directly without having to perform a time-consuming database query for each call.
Structure of Internal Tables
In ABAP/4, you can distinguish between internal table data types, which define the structure of internal tables, and internal table data objects, which are the actual internal tables and can be filled with data. An internal table data type is an abstract definition of a data structure which can be used to declare data objects as internal tables.
Data type
An internal table is one of the two structured data types in ABAP/4. The other structured data type is the field string. An internal table consists of any number of lines which all have the same data type. The data type of the lines can be elementary or structured.
This definition opens a variety of internal table structures which range from lines consisting of one field to lines consisting of field strings which have internal tables as components.
You can define a data type as an internal table by using the TYPES statement with the OCCURS parameter. No memory is occupied when defining a data type.
Data object
A data object which has a data type defined as an internal table is the actual internal table you work with. It occupies memory and you can fill or read its lines.
You create a data object as an internal table by using the DATA statement either with the OCCURS parameter or by referring to another internal table by using the TYPE or LIKE parameters.
Identifying Table Lines
In order to access a certain line of a table, you must specify a field or combination of fields that can be used to identify the line. In the relational data model which is used to store long-life data in the R/3 System, the minimum combination required for this purpose is known as the key. The fields that define the key are called key fields.
Internal Table Index
The index is the sequential number of a table line. It is not a table field, but is created and managed automatically by the system.
You can use the index with the DELETE, INSERT, MODIFY, LOOP, and READ statements. In these statements, you can specify the index either as literal or as variable.
After processing a particular line of an internal table, the system field SY-TABIX generally contains the index of that line.
Internal Table Key
There are two kinds of internal table keys.
Self-defined Key
When reading lines from an internal table using the READ statement, you can specify a self-defined.
Standard Key
By definition, the key fields of an internal table are those fields which are not numeric (type F, I, and P) and are not internal tables. These key fields form the standard key of an internal table.
To obtain the standard key of an internal tables with nested structures (table lines which contain field strings as components), the system breaks down the sub-structures to the level of elementary fields.
SAP ABAP RUN TIME ANALASIS
Debugging
ABAP Debugger
Runtime Analysis
Runtime Measurement of Program Segments
BREAK-POINT
Basic form
BREAK-POINT.
Additions:
1. ... f
2. ... AT NEXT APPLICATION STATEMENT
Effect
The BREAK-POINT is a debugging aid. When you run a program normally, it is interrupted at the statement, and the system automatically starts the debugger, allowing you to display the contents of any fields in the program and check how the program continues.
If the program is running in the background or in an update task, the system generates a Syslog message.
Note
• If a COMMIT WORK statement occurs in a SELECT loop, the database cursor is lost. This causes a runtime error in the next loop pass when the system tries to read the next line of the table.
Since debugging sometimes generates automatic COMMIT WORKs (non-production client or not debugging in debugging mode), it can be difficult to debug SELECT loops because BREAK-POINT statements within the loop can so easily lead to runtime errors.
• You can set dynamic breakpoints in the Debugger without having to change the ABAP program. Such breakpoints are only valid for the user that set them, and are deleted when the user logs off.
Addition 1
... f
Effect
If the program is not running in dialog mode (background, update task), the contents of field f are output along with the system log message.
Addition 2
... AT NEXT APPLICATION STATEMENT
Note
This addition is for internal use only.
Changes and further developments, which may be incompatible, are possible at any time, and without notice or warning.
Effect
This statement is only relevant to system programs (program attributes, status "S"), or system modules, subroutines, or function modules (names begin with "%_")
If system debugging is not switched on, the program is not interrupted until it reaches a statement that is not in a system program (or module, subroutine, or function module).
If system debugging is switched on, the program is interrupted at the statement itself.
Note
When system debugging is switched off, BREAK-POINT statements in system programs are ignored at runtime unless you use the AT NEXT APPLICATION STATEMENT addition.
GET RUN TIME FIELD
Basic form 5
GET RUN TIME FIELD f.
Effect
Relative runtime in microseconds. When you first call GET RUN TIME, the field f is set to zero (initialized). Each subsequent call places the runtime since the first call into the field f. f must have type I.
The ABAP statements between two GET RUN TIME statements are known as the performance section, and the time between the two calls is known as the measurement interval.
Notes
You can use SET RUN TIME CLOCK RESOLUTION to set the measurement accuracy. The default setting is high accuracy.
Example
Runtime measurement for the MOVE statement
DATA: T1 TYPE I,
T2 TYPE I,
TMIN TYPE I.
DATA: F1(4000), F2 LIKE F1.
TMIN = 1000000.
DO 10 TIMES.
GET RUN TIME FIELD T1.
MOVE F1 TO F2.
GET RUN TIME FIELD T2.
T2 = T2 - T1.
IF T2 < tmin =" T2."> Interval...').
Variant 1
SET RUN TIME CLOCK RESOLUTION HIGH.
Effect
GET RUN TIME uses high accuracy with a short measurement interval to measure the runtime.
Variant 2
SET RUN TIME CLOCK RESOLUTION LOW.
Effect
GET RUN TIME uses low accuracy with a long measurement interval to measure the runtime.
Note
Runtime errors:
• SET_RUN_TIME_CLOCK_ERROR : After GET RUN TIME, you may no longer use SET RUN TIME CLOCK RESOLUTION.
SET RUN TIME ANALYZER ON/OFF
Variants:
1. SET RUN TIME ANALYZER ON.
2. SET RUN TIME ANALYZER OFF.
Effect
These statements only work if you are executing a program using runtime analysis. If you select the Particular units option, the system only measures the statements that occur between SET RUN TIME ANALYZER ON and SET RUN TIME ANALYZER OFF.
Note
You should remove these statements from your source code when you have finished measuring runtime. This ensures that other users can define their own runtime monitoring criteria as well.
Variant 1
SET RUN TIME ANALYZER ON.
Effect
Starts writing performance data.
The return code is set as follows:
SY-SUBRC = 1:
The runtime analysis is not active, or the performance data file is not open for writing.
SY-SUBRC = 0:
All other cases.
Variant 2
SET RUN TIME ANALYZER OFF.
Effect
Stops writing performance data.
Example
DO 3 TIMES.
PERFORM NOT_TO_BE_MEASURED.
SET RUN TIME ANALYZER ON.
PERFORM TO_BE_MEASURED.
SET RUN TIME ANALYZER OFF.
PERFORM NOT_TO_BE_MEASURED.
ENDDO.
FORM NOT_TO_BE_MEASURED. ENDFORM.
FORM TO_BE_MEASURED. ENDFORM.
Note
You can also start and stop measurement dynamically:
1. From the menu:
• System → Utilities → Runtime analysis → Switch on
• System → Utilities → Runtime analysis → Switch off
1. In the command field
• /RON
• /ROFF
ABAP Debugger
Runtime Analysis
Runtime Measurement of Program Segments
BREAK-POINT
Basic form
BREAK-POINT.
Additions:
1. ... f
2. ... AT NEXT APPLICATION STATEMENT
Effect
The BREAK-POINT is a debugging aid. When you run a program normally, it is interrupted at the statement, and the system automatically starts the debugger, allowing you to display the contents of any fields in the program and check how the program continues.
If the program is running in the background or in an update task, the system generates a Syslog message.
Note
• If a COMMIT WORK statement occurs in a SELECT loop, the database cursor is lost. This causes a runtime error in the next loop pass when the system tries to read the next line of the table.
Since debugging sometimes generates automatic COMMIT WORKs (non-production client or not debugging in debugging mode), it can be difficult to debug SELECT loops because BREAK-POINT statements within the loop can so easily lead to runtime errors.
• You can set dynamic breakpoints in the Debugger without having to change the ABAP program. Such breakpoints are only valid for the user that set them, and are deleted when the user logs off.
Addition 1
... f
Effect
If the program is not running in dialog mode (background, update task), the contents of field f are output along with the system log message.
Addition 2
... AT NEXT APPLICATION STATEMENT
Note
This addition is for internal use only.
Changes and further developments, which may be incompatible, are possible at any time, and without notice or warning.
Effect
This statement is only relevant to system programs (program attributes, status "S"), or system modules, subroutines, or function modules (names begin with "%_")
If system debugging is not switched on, the program is not interrupted until it reaches a statement that is not in a system program (or module, subroutine, or function module).
If system debugging is switched on, the program is interrupted at the statement itself.
Note
When system debugging is switched off, BREAK-POINT statements in system programs are ignored at runtime unless you use the AT NEXT APPLICATION STATEMENT addition.
GET RUN TIME FIELD
Basic form 5
GET RUN TIME FIELD f.
Effect
Relative runtime in microseconds. When you first call GET RUN TIME, the field f is set to zero (initialized). Each subsequent call places the runtime since the first call into the field f. f must have type I.
The ABAP statements between two GET RUN TIME statements are known as the performance section, and the time between the two calls is known as the measurement interval.
Notes
You can use SET RUN TIME CLOCK RESOLUTION to set the measurement accuracy. The default setting is high accuracy.
Example
Runtime measurement for the MOVE statement
DATA: T1 TYPE I,
T2 TYPE I,
TMIN TYPE I.
DATA: F1(4000), F2 LIKE F1.
TMIN = 1000000.
DO 10 TIMES.
GET RUN TIME FIELD T1.
MOVE F1 TO F2.
GET RUN TIME FIELD T2.
T2 = T2 - T1.
IF T2 < tmin =" T2."> Interval...').
Variant 1
SET RUN TIME CLOCK RESOLUTION HIGH.
Effect
GET RUN TIME uses high accuracy with a short measurement interval to measure the runtime.
Variant 2
SET RUN TIME CLOCK RESOLUTION LOW.
Effect
GET RUN TIME uses low accuracy with a long measurement interval to measure the runtime.
Note
Runtime errors:
• SET_RUN_TIME_CLOCK_ERROR : After GET RUN TIME, you may no longer use SET RUN TIME CLOCK RESOLUTION.
SET RUN TIME ANALYZER ON/OFF
Variants:
1. SET RUN TIME ANALYZER ON.
2. SET RUN TIME ANALYZER OFF.
Effect
These statements only work if you are executing a program using runtime analysis. If you select the Particular units option, the system only measures the statements that occur between SET RUN TIME ANALYZER ON and SET RUN TIME ANALYZER OFF.
Note
You should remove these statements from your source code when you have finished measuring runtime. This ensures that other users can define their own runtime monitoring criteria as well.
Variant 1
SET RUN TIME ANALYZER ON.
Effect
Starts writing performance data.
The return code is set as follows:
SY-SUBRC = 1:
The runtime analysis is not active, or the performance data file is not open for writing.
SY-SUBRC = 0:
All other cases.
Variant 2
SET RUN TIME ANALYZER OFF.
Effect
Stops writing performance data.
Example
DO 3 TIMES.
PERFORM NOT_TO_BE_MEASURED.
SET RUN TIME ANALYZER ON.
PERFORM TO_BE_MEASURED.
SET RUN TIME ANALYZER OFF.
PERFORM NOT_TO_BE_MEASURED.
ENDDO.
FORM NOT_TO_BE_MEASURED. ENDFORM.
FORM TO_BE_MEASURED. ENDFORM.
Note
You can also start and stop measurement dynamically:
1. From the menu:
• System → Utilities → Runtime analysis → Switch on
• System → Utilities → Runtime analysis → Switch off
1. In the command field
• /RON
• /ROFF
MEMORY In SAP ABAP
A logical memory model illustrates how the main memory is distributed from the view of executable programs. A distinction is made here between external sessions and internal sessions .
An external session is usually linked to an R/3 window. You can create an external session by choosing System/Create session, or by entering /o in the command field. An external session is broken down further into internal sessions. Program data is only visible within an internal session. Each external session can include up to 20 internal sessions (stacks).
Every program you start runs in an internal session.
All "squares" with rounded "corners" displayed in the status diagram represent a set of data objects in the main memory.
The data in the main memory is only visible to the program concerned.
CALL TRANSACTION and SUBMIT AND RETURN open a new internal session that forms a new program context. The internal sessions in an external session form a memory stack. The new session is added to the top of the stack.
When a program has finished running, the top internal session in the stack is removed, and the calling program resumes processing.
The same occurs when the system processes a LEAVE PROGRAM statement.
LEAVE TO TRANSACTION removes all internal sessions from the stack and opens a new one containing the program context of the calling program.
The ABAP memory is initialized after the program is called. In other words, you cannot transfer any data to a program called with LEAVE TO TRANSACTION via the ABAP memory.
SUBMIT replaces the internal session of the program performing the call with the internal session of the program that has been called. The new internal session contains the program context of the called program with which it is performed.
When a function module is called, the following steps are executed:
A check is made to establish whether your program has called a function module of the same function group previously.
If this is not the case, the system loads the associated function group to the internal session of the calling program as an additional program group. This initializes its global data.
If your program used a function module of the same function group before the current call, the function module that you have called up at present can access the global data of the function group. The function group is not reloaded.
Within the internal session, all of the function modules that you call from the same group access the global data of that group.
If, in a new internal session, you call a function module from the same function group as in internal session 1, a new set of global data is initialized for the second internal session. This means that the data accessed by function modules called in session 2 may be different from that accessed by the function modules in session 1.
You can call function modules asynchronously as well as synchronously. To do so, you must extend the function module call using the addition STARTING NEW TASK ''. Here, '' is a symbolic name in the calling program that identifies the external session, in which the called program is executed.
Function modules that you call using the addition STARTING NEW TASK '' are executed independently of the calling program. The calling program is not interrupted.
To make function modules available for local asynchronous calls, you must identify them as executable remotely (processing type: Remote-enabled module).
There are various ways of transferring data between programs that are running in different program contexts (internal sessions). You can use:
(1) The interface of the called program (standard selection screen, or interface of a
subroutine, function module, or dialog module)
(2) ABAP memory
(3) SAP memory
(4) Database tables
(5) Local files on your presentation server.
For further information about transferring data between an ABAP program and your presentation server, refer to the documentation for the function modules WS_UPLOAD and WS_DOWNLOAD.
Function modules have an interface, which you can use to pass data between the calling program and the function module itself (there is also a comparable mechanism for ABAP subroutines). If a function module supports RFC, certain restrictions apply to its interface.
If you are calling an ABAP program that has a standard selection screen, you can pass values to the input fields. There are two options here:
By using a variant of the standard selection screen in the program call
By passing actual values for the input fields in the program call
If you want to call a report program without displaying its selection screen (default setting), but still want to pass values to its input fields, there is a variety of techniques that you can use.
The WITH addition allows you to assign values to the parameters and select-options fields on the standard selection screen.
If the selection screen is to be displayed when the program is called, use the addition: VIA SELECTION-SCREEN.
Use the pattern button in the ABAP Editor to insert a program call via SUBMIT. The structure shows you the names of data objects that you can complete with the standard selection screen.
For further information on working with variants and further syntax variants for the WITH addition, see the key word documentation in the ABAP Editor for SUBMIT.
You can use SAP memory and ABAP memory to pass data between different programs.
The SAP memory is a user-specific memory area for storing field values. It is available in all of the open sessions in a user's terminal session, and is reset when the terminal session ends. You can use its contents as default values for screen fields. All external sessions can access SAP memory. This means that it is only of limited use for passing data between internal sessions.
The ABAP memory is also user-specific, and is local to each external session. You can use it to pass any ABAP variables (fields, structures, internal tables, complex objects) between the internal sessions of a single external session.
Each external session has its own ABAP memory. When you end an external session (/i in the command field), the corresponding ABAP memory is released automatically.
To copy a set of ABAP variables and their current values (data cluster) to the ABAP memory, use the EXPORT TO MEMORY ID statement. The (up to 32 characters) is used to identify the different data clusters.
If you repeat an EXPORT TO MEMORY ID statement to an existing data cluster, the new data overwrites the old.
To copy data from ABAP memory to the corresponding fields of an ABAP program, use the IMPORT FROM MEMORY ID statement.
The fields, structures, internal tables, and complex objects in a data cluster in ABAP memory must be declared identically in both the program from which you exported the data and the program into which you import it.
To release a data cluster, use the FREE MEMORY ID statement.
You can import just parts of a data cluster with IMPORT, since the objects are named in the cluster.
In the SAP memory, you can define memory areas (SET/GET parameters, or parameter IDs), which you can then address by a name of up to 20 characters.
You can fill these memory areas either using the contents of input/output fields on screens, or using the ABAP statement:
SET PARAMETER ID '' FIELD .
The memory area with the name now has the value .
You can use the contents of a memory area to display a default value in an input field on a screen.
You can also read the memory areas from the SAP memory using the ABAP statement GET PARAMETER ID FIELD . The field then contains the value from parameter .
The link between an input/output field and a memory area in SAP memory is inherited from the data element on which the field is based. You can enable the set parameter or get parameter attributes in the input/output field attributes.
Once you have set the Set parameter attribute for an input/output field, you can fill it with default values from SAP memory. This is particularly useful for transactions that you call from another program without displaying the initial screen. For this purpose, you must activate the Set parameter functionality for the input fields of the first screen of the transaction.
You can:
(1) Copy the data that is to be used for the first screen of the transaction to be called to the parameter ID in the SAP memory. To do so, use the statement SET PARAMETER immediately before calling the transaction.
(2) Start the transaction using CALL TRANSACTION or LEAVE TO
TRANSACTION . If you do not want to display the initial screen, use the AND
SKIP FIRST SCREEN addition.
(3) The system program that starts the transaction fills the input fields that do not already have default values and for which the Get parameter attribute has been set with values from SAP memory.
The Technical information for the input fields in the transaction you want to call contains the names of the parameter IDs that you need to use.
Parameter IDs should be entered in table TPARA. This happens automatically if you create them via the Object navigator.
Programs that you call using the statements SUBMIT , LEAVE TO TRANSACTION , SUBMIT AND RETURN, or CALL TRANSACTION run in their own SAP LUW, and update requests receive their own update key.
When you use SUBMIT and LEAVE TO TRANSACTION , the SAP LUW of the calling program ends. If no COMMIT WORK statement occurred before the program call, the update requests in the log table remain incomplete and cannot be processed. They can no longer be executed. The same applies to inline changes that you make using PERFORM … ON COMMIT.
Data that you have written to the database using inline changes is committed the next time a new screen is displayed.
If you use SUBMIT AND RETURN or CALL TRANSACTION to insert a program and then return to the calling program, the SAP LUW of the calling program is resumed when the called program ends. The LUW processing of calling and called programs is independent.
In other words, inline changes are committed the next time a new screen is displayed. Update requests and calls using PERFORM ... ON COMMIT require an independent COMMIT WORK statement in the SAP LUW in which they are running.
Function modules run in the same SAP LUW as the program that calls them.
If you call transactions with nested calls, each transaction needs its own COMMIT WORK, since each transaction maps its own SAP LUW.
The same applies to calling executable programs, which are called using SUBMIT AND RETURN.
The statement CALL TRANSACTION allows you to
Shorten the user dialog when calling using CALL TRANSACTION USING .
Determine the type of update (asynchronous, local, or synchronous) for the transaction called. For this purpose, use the addition CALL TRANSACTION USING UPDATE 'update_mode', where update_mode can have the values a (asynchronous), L (local), or S (synchronous).
Combining the two options enables you to call several transactions in sequence (logical chain), to reduce their screen sequence, and to postpone processing of the SAP LUW 2 until processing of the SAP LUW 1 has been completed.
When you call a function module asynchronously using the CALL FUNCTION STARTING NEW TASK ' ' statement, it runs in its own SAP LUW.
Programs that are executed with a SUBMIT AND RETURN or CALL
TRANSACTION statement starts their own LUW processing. You can use these to perform nested (complex) LUW processing.
You can use function modules as modularization units within an SAP LUW.
Function modules that are called asynchronously are suitable for programs that allow parallel processing of some of their components.
All techniques are suitable for including programs with purely display functions.
Note that a function module called with CALL FUNCTION STARTING NEW TASK is executed as a new logon. It, therefore, sees a separate SAP memory area. You can use the interface of the function module for data transfers.
Example: In your program, you want to call a display transaction that is displayed in a separate window (amodal). To do so, you encapsulate the transaction call in a function module, which you set as to Remote-enabled module. You use the function module interface to accept values that you write to the SAP memory. You then call up the transaction in the function module using CALL TRANSACTION AND SKIP FIRST SCREEN. You call the function module itself asynchronously.
Type ‘E' locks for nested program calls may be requested more than once from the same object. This behavior can be described as follows:
Lock entries from function modules called synchronously increment the cumulative counter, And are therefore successful.
Lock entries from programs called with CALL TRANSACTION or SUBMIT
RETURN is refused. The object to be locked by the called program is displayed as already Locked by another user.
Programs that you call using SUBMIT or LEAVE TO TRANSACTION cannot come into conflict with lock entries from the calling program, since the old program ends when the call is made. When a program ends, the system deletes all of the lock entries that it had set.
Lock requests belonging to the same user from different R/3 windows or logons are treated as lock requests from other users.
An external session is usually linked to an R/3 window. You can create an external session by choosing System/Create session, or by entering /o
RETURN is refused. The object to be locked by the called program is displayed as already Locked by another user.
Programs that you call using SUBMIT or LEAVE TO TRANSACTION cannot come into conflict with lock entries from the calling program, since the old program ends when the call is made. When a program ends, the system deletes all of the lock entries that it had set.
Lock requests belonging to the same user from different R/3 windows or logons are treated as lock requests from other users.
NAVIGATION In SAP ABAP
The R/3 System is a client system. The client concept enables the joint operation, in one system, of several enterprises that are independent of each other in business terms. During each user session you can only access the data of the client selected during the logon.
A client is, in organizational terms, an independent unit in the R/3 System. Each client has its own data environment and therefore its own master data and transaction data, assigned user master records and charts of accounts, and specific customizing parameters.
A user master record linked to the relevant client must be created for users to be able to log on to the system.
To protect access, a password is required for logon.
The password is hidden as you type (you only see asterisks).
SAP systems are available in several languages. Use the Language input field to select the logon language for each session.
Multiple logons are always logged in the system beginning with Release 4.6. This is for security as well as licensing reasons. A warning message appears if the same user attempts to log on twice or more. This message offers three options:
Continue with current logon and end any other logons in the system
Continue with current logon without ending any other logons in the system (logged in system)
Terminate current logon
Command field: You can use the command field to go to applications directly by entering the transaction code. You can find the transaction code either in the SAP Easy Access menu tree (see next slide) or in the relevant application under System® Status.
Menu bar: The menus shown here depend on which application you are working in. These menus contain cascading menu options.
Standard toolbar: The icons in the system function bar are available on all R/3 screens. Any icons that you cannot use on a particular screen are dimmed. If you leave the cursor on an icon for a moment, a small flag will appear with the name (or function) of that icon. You will also see the corresponding function key. The application toolbar shows you which functions are available in the current application.
Title bar: The title bar displays your current position and activity in the system.
Check boxes: Checkboxes allow you to select several options simultaneously within a group.
Radio buttons: Radio buttons allow you to select one option only.
Status bar: The status bar displays information on the current system status, for example, warning and error messages.
A tab provides a clearer overview of several information screens.
Options: You can set your font size, list colors, and so on here.
SAP Easy Access is the standard entry screen displayed after logon. Using the menu path Extras® Set start transaction you can select a transaction of your choice to be the default entry screen after logon.
You navigate through the system using a compact tree structure that you can adapt to your own specific requirements. Use the menu path Extras® Settings to change your view of the tree structure. You can use this to display technical names (transaction codes).
You can also create a Favorites list of the transactions, reports, files and Web sites you use most.
You can add items to your favorites list using the Favorites menu option or by simply dragging & dropping them with the mouse.
You can select system functions in the following ways:
Use the mouse to choose
Menu options
Favorites
Other options in the tree structure (tree control)
Use the keyboard (ALT + the underlined letter of the relevant menu option)
Enter a transaction code in the command field:
A transaction code (T-Code) is assigned to each function in R/3 (not each screen).
You can access the assigned transaction code from any screen in the R/3 System.
You can find the transaction code for the function you are working in under the Status option of the System menu.
For example, to display Accounts receivable master data, enter “/n” and the appropriate
transaction code (in this case “/nfd03”).
Other possible entries:
“/n” ends the current transaction. “/i” ends the current session.
“/osm04” creates a new session and goes to the transaction specified (SM04).
You can also use the keyboard to get to the command field. Use the CTRL + TAB key
combination to make the cursor move from one (input) field group to the next. Use TAB to move between fields within a group.
Use F1 for help on fields, menus, functions and messages.
F1 help also provides technical information on the relevant field. This includes, for example, the parameter ID, which you can use to assign values to the field for your user.
Use F4 for information on what values you can enter. You can also access F4 help for a selected field using the button immediately to the right of that field.
If input fields are marked with a small icon with a checkmark, then you can only continue in that application by entering a permitted value.
You can flag many fields in an application to make them either required entry fields or optional entry fields. You can also hide fields using transaction or screen variants or Customizing.
The R/3 System provides comprehensive online help. You can display the help from any screen in the system. You can always request help using the Help menu or using the relevant icon.
The Help menu contains the following options :
Application help: Displays comprehensive help on the current application. Selecting this menu option in the initial screen displays help on getting started with R/3.
SAP Library: This is where all online documentation can be found.
Glossary: Enables you to search for definitions of terms.
Release notes: Displays notes which describe functional changes that occur between R/3 releases.
SAPNet: Enables you to log on to SAPNet.
Feedback: Enables you to send a message to the SAPNet R/3 Frontend, SAP’s service system.
Settings: Enables you to select settings for help.
The System menu contains, among others, the following options:
Create/end session: Enables you to create and end sessions. You can work with up to 6 sessions at a time.
User profile: This is where you can enter user-specific settings.
Services: Takes you to important service functions (see below).
List: Contains important list functions, such as searching for character strings, saving in PC files, printing, and so on.
Status: Enables you to display important user and system data.
Log off: Ends the SAP R/3 session with a confirmation prompt.
The System ® Services menu contains, among others, the following options:
Reporting: Starts reports (ABAP programs).
Output controller: This is where you manage user-specific print requests.
Table maintenance: This is where you process tables and views.
Batch input: Administers batch input sessions and data transfer.
Jobs: This is where you can administer jobs that are processed in the background.
SAP Service: Enables you to log on to SAP’s SAPNet R/3 Frontend.
Use the menu option System® User profile® Own data to set your own personal profile. You can choose between the Address, Defaults and Parameters tabs.
Address: You can create and maintain personal data here, for example, name,function, room number, telephone number, e-mail addresses and so on.
Defaults: Defaults include the date display format, the decimal notation format, the default printer, the logon language, and so on.
Parameters: Use this to assign entries to commonly-used fields. This is only available for input fields that have been allocated a parameter ID.
Procedure for finding out a field’s Parameter ID: Go to the input field to which you want to assign a value. Choose F1, then the “Technical info” pushbutton. This opens a window that displays the corresponding parameter ID (if one has been allocated to the field) in the “Field data” section.
The User profile menu also contains, among others, the following options:
Hold data, Set data, Delete data. Use Hold data to keep data values that you have entered in fields in an application for the duration of a user session. When you call up the application again, you can overwrite these values. Once you have Set data , you can no longer overwrite these values and have to use Delete data if you want to enter different values.
Use the Table Settings function to change, in the table control, the individual basic table settings that are supplied with the system. This is particularly useful for tables where you do not need all the columns. You can use the mouse to drag & drop column positions and widths, or even make the column disappear.
Save the changed table settings as a variant. The number of different variants you can create per table is not restricted.
The first variant is called the basic setting; the SAP System defines this setting. You cannot delete the basic setting (you can delete the variants you define yourself).
The table settings are stored with your user name. The system uses the variant currently valid until you exit the relevant application. If you then select the application again, the system will use the standard settings valid for this table.
Note: you can change table settings wherever you see the table control icon in the top right-hand corner of a table.
The R/3 System provides numerous options for settings and adjustments:
Define default values for input fields
Hide screen elements
Deactivate screen elements (shaded out).
You can do this by, for example, defining transaction variants.
If you pre allocate all necessary parameters for parameter transactions, you do not need to go
through the initial screen.
These functions have been available in R/3 for several releases.
SAP now also includes the GuiXT. In addition to all the above functions, you can now:
Include graphics
Convert fields and add pushbuttons and text
Change input fields (or their F4 help results) into radio buttons
The GuiXT scripts are stored on the frontend. In accordance with local scripts, the GuiXT scripts determine how data sent from the application server is displayed. These scripts can be standard throughout a company, or they can be different for each frontend.
Subscribe to:
Posts (Atom)
