SAP NetWeaver AS ABAP Release 740, ©Copyright 2014 SAP AG. All rights reserved.
ABAP Keyword Documentation → ABAP Programming Guidelines → Robust ABAP → Dynamic Programming Techniques →Generic Programming
Background
Generic programming (dynamic generation of source code) makes programs as dynamic as possible. The following methods can be used to achieve this:
Rule
Avoiding Program Generation
Program generation should only be used as a last resort for generic programming. Other dynamic methods (especially in application programs) should be tried first, such as dynamic token specification, runtime type services (RTTS) and dynamic access to data objects.
Details
Program generation has a lot of conceptual problems such as checking, testing and maintaining generated programs. In addition, programs generated hastily can be a security risk because they cannot be statically checked. Generating programs is usually very intensive in terms of runtime and resources. Due to the above reasons, program generation should be avoided wherever possible and other dynamic methods used instead:
These methods, combined with field symbols and data references, are now usually sufficient for most tasks that could only be solved using program generation in older releases.
Exception
Program generation should only be used as a last resort if the other methods are not sufficient to achieve dynamic program control. Another reason is the processing speed. When program generation is used, the costs incurred due to checking and generation occur less frequently than with the other dynamic methods. However, program generation is usually associated with worse system performance than dynamic token specification. The conceptual problems explained at the start are still applicable here and therefore careful consideration is needed.
Unlike application programs, system programs usually frequently rely on program generation and the associated language constructs. Examples include the generation of proxy classes for Web Dynpro or Web Services. The ABAP Editor also uses statements such as READ REPORT and INSERT REPORT.
Note
Even generated programs should always adhere to the predefined guidelines. For example, the program logic should be implemented/generated in a generated subroutine pool in the form of local classes. The generated functions are usually called by means of a single subroutine that is used as an entry point into the generated local classes (see the following example).
To minimize the risks involved, it can be useful to save syntactically correct templates that adhere to the guidelines in the repository. READ REPORT can then be used to load the templates as templates for dynamically generated programs, in which only small parts are changed or added at runtime.
Subroutines in generated subroutine pools are an exception to the rule, which states that subroutines should no longer be created, and an exception to the rule, which states that subroutines should no longer be called. In addition, absolute type names can be used to access the local classes of a generated subroutine pool. However, this violates the rule Only call suitable procedures externally.
Bad example
The following source text demonstrates unnecessary program generation. The only reason for generating the program is dynamic read access to a database table. The name of the database table and the row type of the internal table (into which data is read) are replaced by a parameter value in the source code of the program to be generated. The value operator VALUE is used to create the internal table. As recommended, the subroutine of the generated subroutine pool only contains the call for a method of a local class where the actual implementation is located. Instead of filling the program table row by row, it would have also been possible in this case to create a corresponding program in the repository and load this program using READ REPORT.
Good example
The following source code produces the same result as the example above, when executed successfully. In other words, the field symbol <table> points to an internal table that is filled with data from the dynamically specified database table. However, this task is performed much more efficiently in the example below due to the generation of an anonymous data object and a dynamic token-specification. If the target table cannot be structured in exactly the same way as the database table, Runtime Type Creation (RTTC) must also be used.