This is a test message to test the length of the message box.
Structuring a report
Created by Software-Heroes

ABAP - Structuring a report

What's next after the virtual end of the form? How should you build a report, what should be considered and what is there for useful things. More you can read in this article.


In the last article, we looked at the ways in which we implement classes in the report and thus get away from the now obsolete forms. Today we want to show you, what else you can do to change the structure to generate clean and clear code.



When implementing the class, you will first be faced with the question of how should the class be implemented. Do you want to create them locally or globally? Should it be static, work with an instance or singleton principle?

Of course, each of these implementations has its own pros and cons, and you should be aware of this when choosing the appropriate implementation method.

  1. If you are thinking that you would like to use the class again or if it is so static that it only fits this one case, then create a local class directly in the program.
  2. If you want to reuse the class and use it slightly modified in other reports, then use a non-final global class.
  3. With a local class you can decide according to your own taste. If you want an instance, then create the class as an instance during initialization or during the load-of-program.



When creating a new report, a good structure is the first part of the goal. The clarity and navigation in the report is also important for your colleagues, who later have to take over or maintain the report.

Therefore, at the very beginning, you should think about how you want to structure your reports in general. We therefore want to give you a suggestion.


Immediately after entering the program you should offer direct navigation options. The whole thing with the example of a static/local class.

*--- Includes

*--- ABAP Events
  lcl_prog=>init_program( ).

  lcl_prog=>pbo_1000( ).

  lcl_prog=>ucomm( sscrfields-ucomm ).

  lcl_prog=>start( ).

In the example shown, the program starts with the includes of the report, everything that belongs to data and further definitions for the report. This is followed by the report events of the individual processing steps. In each include and each method of events, you can jump with a forward navigation and view the code directly.



The includes ensure a neat structuring of the program and the individual components.

  • The TOP include (_TOP) defines the program header and the message class. Furthermore, all global variables and types are defined. Normally, however, only the reference to the screen fields (sccrfields) is required, which passes the user command (see example above).
  • In the selection include (_SEL) are all the selection screens that are required for the report.
  • In the class include (_Cxx) all class definitions and implementations of a class are used to separate the resources from the rest of the program.
  • Furthermore, there could be a form include (_Fxx), which is actually only used for module routines of dynpros.


Selection screen

When transferring the data from the selection screen to the class, there are two basic concepts:

  • You use the global parameters and select options directly in the class and access them as if they were external data sources.
  • You pass the parameters directly to the processing routine at the start of the process.


The second case would actually be the cleanest, but also the most time-consuming, since you would have to typify the individual select options in the input.


Data management

The global data in a program would disappear for the most part, but this is not always possible because certain values need to be kept global. Here are some examples:

  • Screenfields for passing the user command to the method for evaluation
  • Auxiliary fields for select options of the selection screen
  • Global tables for screens for data storage and processing
  • Global typifications


All other values would migrate into the class, since the processing also takes place here. Thus, for example ...

  • Constants
  • Data
  • Typifications

... all in the class.

How exactly the individual class is implemented is up to you as a developer and should be carefully thought out, whether this fits your concept and whether this is also easily expandable and maintainable.



This should just be an example of structuring a report and is not an obligation for you. Maybe we could use the concept to bring you something new ideas and approaches that you can now incorporate into your daily work.

Included topics:
Comments (0)

ABAP - Predicative Method Call

Category - ABAP

Due to the OO concept, own methods are usually used for complex queries. This article is about comparing the result from such methods.


ABAP - Performance for the SELECT

Category - ABAP

In this article we will look at a few special cases with the SELECT and examine the performance of these constructs. We'll show you the current alternatives and give you little tips while reading.


ABAP - Check objects (Instances)

Category - ABAP

In this article we will show you how you can analyze instances and react to them correctly, for example if you hand them over during processing and want to react individually.


ABAP - Loops

Category - ABAP

With New ABAP, new loops and possibilities for restricting table contents were created. We'll take a closer look at these new commands in this article.


ABAP - Comparison

Category - ABAP

Today we'll look at comparisons and comparison operators in terms of the new commands and their current usage. What has changed so far and what should still be done?