M.

Rajagopalan
ABAP/4 Optimization
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 Field groups 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.

28/Nov/2007 1 of 2
 M. Rajagopalan

SAP Development: Recommendations

These are some recommendations I make to new SAP programmers. Take 'em or leave 'em.

Read the online help for the related modules, or any other related material (not necessarily technical) to
understand the broader perspective or what you are trying to do in the system, and what the system already has,
and how the processes work. Try to convince all the heads of departments and top management to read the
material as well. This will greatly increase the efficiency of the implementation. When the people with authority
understand exactly what the system can and cannot do, and have already decided what they want to get out of
the system, they are in a position to monitor and direct their part of the implementation. When this is not the case,
and top management is less involved, the IT department may start to make implementation decisions that only top
management should be making, and it becomes unclear who is responsible for the consequences of these
decisions.

Comment program code extensively.

Whenever possible, combine summary and detail reports into a single single report with drill-down. This makes
things much easier for the lead programmer, project manager, and end-user to verify correctness.

Remember to write authority-checks into each program where appropriate.

Before agreeing to user requirement specifications, consider whether the proposed report or program is feasible,
and if so, if it is the best way to achieve the goal. If, for instance, a slight change in specifications results in a big
performance gain or a much lower error margin, try to get the specs changed. It is often much more efficient for
the appropriate applications consultant to look over the user requirements first, to make sure that what the user
wants is consistent with what SAP can provide. For instance, the user may confuse one-to-many relationships,
and ask that a single line be used to display information that is multi-dimensional. The applications consultant is
most in tune with these details, and can save the programmer much wasted time by correcting any program
design problems early.

Learn to use ABAP/4 queries, and use them where appropriate. They're not quite as efficient, but they require no
programming, can be set up in minutes, and can be set up directly on your productive system without transporting
from the development system. Good for temporary solutions or for reports that are not run very often.

ABAP/4: Tips for Finding Data in SAP

Go to an SAP report or program that does something similar to what you want to do, and:
Click on the screen fields, and use F1->Technical Info to find the field & table names
Trace the program with ST05 (SQL Trace) and ST01 (System Trace)
Follow the program with the debugger (enter /h in the command line)

Use the Table Contents utility to verify that the tables have the data that you think they have (SE80 -> Dictionary
Objects (press Edit), enter the name of the table you want to see, and press Display. Go To Utilities -> Table
Contents).

Look for a logical database that sounds like what you're looking for. Analyze its structure and program to
understand how its data is processed, and where the data is being kept.

Reference URL: [Link]

28/Nov/2007 2 of 2