Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at [email protected].
ABAP Dynamic Programming Techniques
We have all seen it…..
Some of us have been around 20+ years and still don’t REALLY understand it. Imagine how a fresher feels when they encounter this form of code. Now I can hear the old timers here screaming it just NOT necessary to code this way and what does it buy you anyway? Well, this is exactly what I intend to look at in this series. All manner of DYNAMIC ABAP and DYNAMIC OPEN SQL. If nothing else it will be a good place for freshers to look when they encounter this madness… lets go!
Dynamic Programming Concepts and Benefits
What exactly is ABAP dynamic programming, and why is it so beneficial? Fundamentally, dynamic programming is used in almost every program, but the extent varies. Most programs consist of both dynamic and static parts. In this sense, programs are rarely black and white — most are shades of gray. Perhaps the best way to answer that question is to contrast dynamic with static programming.
In this context, dynamic and static apply to the data and/or operations performed on the data within a program. Static properties of data or operations are those characteristics that are known and fixed at compile time. They are explicitly defined in the program source code and will not change during runtime. In contrast, dynamic properties of data or operations are the characteristics that are not known or fixed at compile time. Instead, they are defined by the values of parameters that are passed to the program at runtime.
To understand what these characteristics mean in a practical context, let’s review three examples that illustrate the static versus dynamic aspects of ABAP parameters and operations.
Example#1
Lets consider a subroutine that calculates the number of days between two dates. It requires two dates as input parameters and produces a number of days as an output parameter. Simple enough? OK, based on this what can we say are the characteristics?
(1) We can say the type and size of the input data (two dates) are known at compile time so this would be static.
(2) The type and size of the output data (one number) are known at compile time. Again this is static.
(3) The operation of the subroutine (calculating the difference between two dates) is known at compile time (static).
Actually from our analysis, we can classify this subroutine as wholly static.
Example#2
Next, consider a variation of the classic “Hello, World” programming exercise. This subroutine takes a person’s name as an input parameter and produces a welcome message addressed to that person. Thus we can say it has the following characteristics…
(1) The type of the input parameter (a person’s name) is known at compile time (static), but its size (the length of the person’s name) is known only at runtime (dynamic).
(2) The type of the output parameter (the welcome message) is known at compile time (static). However, its size is known only at runtime (dynamic) because the length of the resulting welcome message is affected by the length of the person’s name.
(3) The operation of the subroutine is known at compile time (static): it must concatenate the welcome message and the person’s name.
Here you see the first evidence of dynamic programming. This subroutine is dynamic in terms of parameter size; it must be able to handle parameters of varying sizes.
Example#3
In this final example, lets consider a subroutine that writes the contents of any internal table to the ABAP List. This subroutine takes any internal table as an input parameter and writes all components of all rows to the ABAP List, which in this example is the output parameter. Although this subroutine is a little more complex, we can see that it has the following characteristics…
(1) The type and size of the input parameter (any internal table) is known only at runtime (dynamic).
(2) Since the ABAP List is the output parameter, at compile time you don’t know anything about its size (the count of rows and components) or the type of data that it will contain (dynamic).
(3) All subroutine operations are known only partially at compile time because we don’t know anything about the count of WRITE statements needed or the type of data that will be written to the ABAP List (dynamic).
Here we have a subroutine that is dynamic in all three characteristics — operations, parameter type, and parameter size. It must be able to handle internal tables of different types and sizes as input. Furthermore, it needs to be able to provide the right parameters for the WRITE statements for every component of every line as output.
Advantages and Disadvantages of Dynamic Programming
Based on these examples above, we can now define dynamic programming as follows: Dynamic programming is the use of special programming constructs that enable you to use selected features of data and/or operations at runtime that cannot, for various reasons, be determined at compile time.
While very powerful, this flexibility of Dynamic Programming has both advantages and disadvantages….
With the use of dynamic programming techniques, you can design your programs to be more flexible. For example, you can distinguish between parameter types at runtime and adapt both the behavior and sequence of operations. You can also write more generic subroutines instead of writing several specific subroutines. The third example illustrates the possibility of writing any internal table to the ABAP List. Well you could use the same subroutine with a new internal table type you created, or even if an existing internal table type is changed, this subroutine will execute without intervention from a developer.
That said, this added flexibility isn’t completely without cost. While programs and subroutines with dynamic features can be more flexible and generic, at the same time they also become more complex and harder to maintain. (OK I can hear you saying I told you so).
For example, the compiler cannot check or analyze dynamic features because the necessary information is not available until runtime. That inherently means some checks must be done at runtime, which is not beneficial to performance. Furthermore, it is much harder to test a subroutine or program with dynamic features. The range of accepted parameters is much broader, and the runtime order of operations can depend on those parameters.
OK, so everything in life is a trade-off. Now that you understand the basic concepts of dynamic programming, it’s time to look at how you implement them in ABAP. I will begin in the next blog with using Dynamic OPEN SQL. As we explore this idea, any relevant ABAP specific Dynamic material may take us on small tangents, but we will march forward undeterred. I will provide plenty of code in this series for you to cut and paste into your own development system, so it can be an actionable artifact and hopefully add value.
Remember to visit the SCN ABAP Page regularly for the latest ABAP Development news!
ABAP Development | SCN – This is a community for learning, sharing, getting help and keeping your skills up to date. Join the conversation about the ABAP programming language.
