ABAP Mentor

Overview

After finishing the blog post series, called 5 Ways to Improve the Readability of Your ABAP Code, I was thinking a lot about the topic of the next blog post series.

In the last few months, I worked with many 7.4 based SAP systems, developed many ABAP programs, and thanks to this, I had chances to try out the different new features, that the SAP has implemented. Since during my works, these improvements helped me a lot, and found them very useful, I decided to share them with you.

Right now, in 19th of February in 2015, we have Support Packages up to 09. Today, I want to share you a feature, that was released in the Support Package Stack 02, called Inline Declaration, and within that we are getting to know DATA inline declarations.

It's a very simple feature, but very useful, and can make our code thinner. Inline declaration means, that you declare your local variables as embedded in the given context, instead of declaring them separately:

  READ TABLE flight_schedules INDEX sy-index INTO DATA(flight_schedule).

Do you see it? From now on, we don't have to define any work area for the INTO clause of the READ TABLE statement, instead we are able to define this work area as embedded into the READ TABLE statement. Besides, you don't need to specify the data type of the target field (I did not specify the type of flight_schedule work area), since the system is able to determine it from its context (based on the type of the flight_schedules internal table).

Wait! Does it spoil the readability of our code? I think, yes, it does. But it doesn't mean, that you mustn't use it. You only need to comply with some simple rules.

Declaration Positions

We can apply this kind of declarations in many-many places, we called these places as declaration positions. We have many possible declaration positions, but I'm only going to demonstrate you my favorite ones, like (the list is not exhaustive):

LOOP Statement

The first declaration position, that I want to show you is the LOOP statement. Do you want to loop through on an internal table? Ohh again, first you need to define a work area, or a field-symbol based on the line-type of the internal table! Sounds familiar?

Old version

It looked like this, before inline declarations:

  DATA xml_line LIKE LINE OF xml_content.

  LOOP AT xml_content INTO xml_line.
    ...
  ENDLOOP.

New version

Using inline declaration, you only need to insert a single DATA keyword, and some brackets, nothing else. Nothing about data types, or declaration statements! Great huh?

  LOOP AT xml_content INTO DATA(xml_line).
    ...
  ENDLOOP.

READ TABLE Statement

Old version

The same effect, in the case of READ TABLE statement. You want to read a record from a table, but before reading you must to define a work area or a field-symbol for the result.

  DATA flight_schedule  TYPE spfli.

  READ TABLE flight_schedules INDEX sy-INDEX INTO flight_schedule.

New version

Since, system does know the data type of the flight_schedules internal table, we only have to indicate, that "please define a work area for me, based on the structure of the internal table". Thanks! I really like it! :)

  READ TABLE flight_schedules INDEX sy-index INTO DATA(flight_schedule).

Left Side of an Assignment

Old version

It's also good for counter and auxiliary fields, reference variables (more about in later posts), and so on.

  DATA discount_percentage TYPE i.

  discount_percentage = 30.

New version

It's thin, readable, and transparent!

  DATA(discount_percentage) = 30.

Catching an Exception

Old version

If you pay attention to robustness, and doing many exception handling, then you feel the same as me...

  DATA not_an_integer TYPE REF TO cx_abap_not_an_integer.

  TRY.
      ...
    CATCH cx_abap_not_an_integer INTO not_an_integer.
      ...
  ENDTRY.

New version

The code speaks for itself!

  TRY.
      ...
    CATCH cx_abap_not_an_integer INTO DATA(not_an_integer).
      ...
  ENDTRY.

SELECT Statement

Thanks to Uwe Fetzer (@se38), I have updated this post, extended with an example for SELECT statement, since it's a big improvement also, when we talk about inline declarations (Note: in contrast to the examples above, SELECT ... INTO TABLE @DATA(...), only available from SP08). 

Old version

Before 7.4 SP08, we had to define structures, and internal tables:

  TYPES:
    BEGIN OF flight_schedule_type,
      carrid    TYPE s_carr_id,
      connid    TYPE s_conn_id,
      countryfr TYPE land1,
      countryto TYPE land1,
    END OF flight_schedule_type.

  DATA flight_schedules TYPE STANDARD TABLE OF flight_schedule_type.

  SELECT carrid connid countryfr countryto
    FROM spfli
    INTO TABLE flight_schedules.

New version

The code speaks for itself! No structure definitions, internal table definitions, the system determines the structure of the flight_schedules, based on the defined SELECT list. It's amazing!
Note: don't forget about using the escape character, @ before the DATA keyword.

  SELECT carrid, connid, countryfr, countryto 
    FROM spfli
    INTO TABLE @DATA(flight_schedules).

Summary

What do you think? I hope, I could to convince you, that inline declaration is a great improvement in ABAP, and it's advisable to use.

My advices for you journey:

• write well-organized code, instead of a complex spaghetti code,
  
• write readable and well-formatted code,
• and use inline declaration only for local variables!

Next, we are going to talk about the other declaration operator, beside the DATA, called FIELD-SYMBOLS.

Now, go and try it out! If you don't have any access to any 7.4 based SAP system, then I recommend to watch my colleague's setup guide.

Stay tuned, keep reading! If you want to get notification about the newest posts, follow me or subscribe to our newsletter!

If you liked it, please share it! Thanks!