Acorel
To Acorel.nl
Acorel background

How ABAP moves towards Functional Programming

Wilco Menge, 11 December 2013

Back in 2006 when I started with SAP and ABAP development, people told me there was no future in ABAP: SAP would not develop new applications on the ABAP stack, but rather on the Java stack, possibly with ABAP as a data backend.

Boy, where they wrong. For several reasons ABAP is still very much alive and relevant, even more than Java. (Well at least in the SAP ecosystem).

This means that the two technology stacks (ABAP/Java) will both be here to stay. Only where the technologies overlap, choices will be made (an obvious example is the death of Java Web Dynpro).

Teach the old dog new tricks

Now the cool thing is that SAP is still actively evolving the language. At first, the Object Orientation paradigm was introduced and supported heavily by SAP. And now ABAP is making some very early steps into the world of functional programming.

Declarative vs Functional

ABAP is now mostly a declarative language. As a developer you tell the program the steps it needs to perform to complete a task. This has a number of side effects:

The functional paradigm puts the emphasis on what your intent is: What are you trying to achieve? It should let the developer focus on what he is trying to achieve and let the compiler fill in the details on how to achieve this goal.

The end result is more concise code that is easier to understand and easier to maintain.

Show me the code!

The following tricks are not really functional programming per se, but are interesting none the less, even more so as they are available in current ABAP releases and can actually be used today:

Inline declarations DATA() FIELD-SYMBOL()

It is no longer needed to explicitly define a variable when the type can be inferred from the context, for example when looping over a table or when executing a method.

Inline data declarations old versus new

The code samples above do the same thing. The old example needs three explicit variable declarations. The new example infers the type from the context. In this case, we have made the program 50% shorter. (In this example you could also use method chaining but that is beside the point).

The same can be done with Field Symbols:

Inline field symbols, old versus new

Creating inline data with VALUE()

This is a rather cool trick borrowed from Javascript with its JSON notation. Rather than creating code that creates an internal table with some data, you can now just create that internal table:

Creating data, old versus new

In the old example, there is some tedious code that moves data into work areas and moves those work areas into a table. In the new example, you can just specify the contents of the new table. The compiler will then take care of the implementation details.

New itab[] syntax

Another cool trick borrowed from javascript is accessing table using brackets. This means you can simply access and modify data in a table in a very precise manner:

Itab[] syntax, old versus new

On the left you see a nested internal table. The goal is to read the the contents of the cell with value 13. In the old style some tedious code is needed to move data from the internal tables into work areas and to move the data from the field to a variable.

In the new style, you can simply specify what lines and field you would like to access. I think the second example is better in simplicity and clarity of intent. This syntax does not only work with indexes but also with search parameters.

Disclaimer

Be aware that these features are only available in Netweaver 7.4. Also, I have not covered all new syntax elements. See the following resources for more in-depth information:

Receive our weekly blog by email?
Subscribe here: