ABAP basics: syntax, data types, keyword index

ABAP statements follow a fixed pattern: a keyword first, then operands, then a period. The period ends the statement, not the line, so a single statement can run across several lines and several statements can share one line. Keywords are not case sensitive, but most shops write them in uppercase and the operands in mixed case. A reference written in Italian, the Registro ABAP, collects the same ground rules along with a keyword index and worked examples of ABAP syntax and statements, which is useful when you want a second explanation of a construct you already met at work.

How do you write basic ABAP syntax and statements?

Every statement starts with a keyword from the language. WRITE, MOVE, IF, LOOP, CALL FUNCTION, SELECT: these are the verbs. After the keyword come the operands, separated by spaces or commas depending on the statement. The statement closes with a period. That period is the only mandatory punctuation in classic ABAP.

A few rules cover most of what you will read in existing code:

• A statement can span multiple lines. The period, not the line break, marks the end.
• Chained statements use a colon. WRITE: a, b, c. is the same as three separate WRITE statements.
• Comments start with an asterisk in column one, or with a double quote anywhere on the line.
• String literals sit between single quotes. Text symbols sit between backquotes and are filled from the text pool.
• Comparison operators are written as words: EQ, NE, LT, GT, LE, GE. The symbolic forms =, <>, <, >, <=, >= also work in modern releases.

Older code often uses MOVE and COMPUTE. Newer code uses the assignment operator = and inline declarations such as DATA(lv_count) = lines( lt_items ). Both compile. Reading both is part of maintenance work.

What data types does ABAP use?

ABAP separates elementary types from complex ones. The elementary types cover single values:

• C for character fields, fixed length, padded with blanks.
• N for numeric text, digits only, used for codes and account numbers.
• I for integers, P for packed decimals, F for floating point.
• D for dates in the form YYYYMMDD, T for times in the form HHMMSS.
• STRING for variable length character data, XSTRING for byte sequences.

Complex types build on those. A structure groups fields under one name. An internal table holds many rows of the same structure or type. A table type describes the row type plus the access mode: standard, sorted, or hashed.

Declarations name the type. DATA lv_name TYPE string. declares a variable. DATA lt_items TYPE STANDARD TABLE OF ty_item. declares an internal table. TYPES declares a type without creating a variable, which is how most shops define their row structures.

One habit saves time later: declare with TYPE and a named type rather than with LIKE and another variable. Named types survive refactoring. LIKE chains break when the reference variable changes.

Where do I find an index of ABAP keywords?

An index of keywords is a list of the language statements grouped by purpose, with the short description of each one. Three places carry that list:

1. The official keyword documentation shipped with the system. In transaction ABAPDOCU you get the full reference, searchable by statement name. 2. The online documentation published by SAP for the release you run. Statements change between releases, so match the version. 3. Community references and study guides, which often group keywords by task instead of alphabetically. The Italian guide mentioned above keeps a keyword index next to its syntax pages, which helps when you know what you want to do but not what the statement is called.

A keyword index is not a tutorial. Use it to confirm the exact spelling and the allowed operands, then read the full entry for the statement you picked.

Internal tables: APPEND, LOOP, READ TABLE, SORT

Internal tables are the workhorse of ABAP. Four statements cover most of the daily work.

APPEND adds a row at the end of a standard table. APPEND wa_item TO lt_items. The work area must match the row type.

LOOP walks the table row by row. LOOP AT lt_items INTO wa_item. ... ENDLOOP. Inside the loop you read and write the work area. To change the table itself, use LOOP AT lt_items ASSIGNING FIELD-SYMBOL(<fs_item>). and modify the field symbol.

READ TABLE fetches one row by key or by index. READ TABLE lt_items INTO wa_item WITH KEY id = lv_id. Check the system field sy-subrc right after the read. Zero means found, four means not found. Skipping that check is the most common source of short dumps in maintenance code.

SORT orders the table. SORT lt_items BY id ASCENDING. Sorting before a READ TABLE with BINARY SEARCH used to matter for speed. On sorted and hashed tables the runtime handles the access path, so the explicit binary search is less common in new code.

Two more statements appear constantly: DESCRIBE TABLE for the row count, and CLEAR or FREE to empty a table. CLEAR keeps the allocated memory, FREE releases it.

Data Dictionary: tables, views, and primary keys

The Data Dictionary, transaction SE11, stores the definitions that the rest of the system reads. Three objects matter first.

A table is a physical table in the database. It has fields, each with a data element and a domain, and it has a primary key. The primary key is the set of fields that identifies a row uniquely. Choose it well: it drives the indexes, the access paths, and the foreign key checks.

A view is a virtual table built from one or more tables. A database view joins tables and exists in the database. A maintenance view allows editing through the dictionary. A projection view hides fields. A help view feeds a search help. Views do not store data; they read it.

A primary key in the dictionary is not the same as a key in an internal table, though the idea matches. In the dictionary, the key fields are marked in the table definition and the system builds a unique index on them. Secondary indexes can be added for frequent access patterns.

Data elements carry the semantic meaning and the field labels. Domains carry the technical attributes: type, length, value range. When a report shows a column header, that text usually comes from the data element. Changing a data element changes every table and structure that uses it, so the dictionary rewards caution.

From dictionary to report

The path from a dictionary table to a printed list is short. Declare a work area with TYPE and the table name. Select the rows you need. Loop over the internal table and write the fields. The field labels come from the data elements, so the column headers are already defined.

For output, classic lists use WRITE. Modern reports use ALV grids, which handle sorting, filtering, and export without extra code. Both read from the same internal tables, so the dictionary work pays off either way.

A practical order for a beginner: learn the statement pattern and the period rule, learn the elementary types, learn the four internal table statements, then learn SE11. That sequence covers the code you will be asked to read in the first months on a maintenance team.