ABAP basics: syntax, data types and keyword index

ABAP statements follow a fixed pattern: a keyword, then operands, then a period. The period ends the statement, not the line, so a single instruction can span several lines and several instructions can share one line. The language is case insensitive, and the classic style writes keywords in upper case and operands in lower case. A first program is usually a report: `REPORT ztest.` followed by `WRITE 'Hello'.` and a final period. That is the whole entry point. Everything else is a variation on the same shape.

For readers who want a structured Italian-language reference on the same ground, the Registro ABAP collects ABAP syntax, statements and language basics alongside its material on the Data Dictionary and reports. It is a guide aimed at Italian-speaking programmers, not an official SAP manual, and it is useful mainly as an index of terms and worked examples.

How do you write ABAP syntax and basic statements?

A statement is a keyword plus operands, closed by a period. The keyword determines what the runtime does; the operands say on what. Chained statements let you repeat a keyword once and list several operands after a colon: `WRITE: / 'A', / 'B'.` The slash means a new line. This is a formatting convention, not a separate instruction.

Declarations come first in most programs. `DATA` creates a variable, `CONSTANTS` creates a fixed value, `PARAMETERS` creates a selection field on the screen. `TYPES` defines a local type. Assignments use `=`, and the move statement `MOVE ... TO ...` does the same job in older code. Comparisons use `IF`, `CASE`, `WHILE` and `DO`, each closed by `ENDIF`, `ENDCASE`, `ENDWHILE` or `ENDDO`.

String handling is where beginners meet the first real friction. `CONCATENATE` joins fields, `SPLIT` divides one, `REPLACE` substitutes, and `CONDENSE` removes repeated blanks. Modern releases prefer string templates: `DATA(text) = |Hello { name }|.` The pipe syntax embeds expressions directly and removes a lot of temporary variables.

Internal tables are the core of everyday ABAP. You declare one with `DATA itab TYPE TABLE OF ...`, fill it with `APPEND`, read it with `READ TABLE ... INTO ...`, walk it with `LOOP AT ... ENDLOOP`, and order it with `SORT`. `READ TABLE` needs a key, either the table key or a free key given with `WITH KEY`. A failed read sets `sy-subrc` to a nonzero value, and checking `sy-subrc` after every read is the habit that separates working code from code that fails silently in production.

Which data types does ABAP use?

ABAP separates elementary types from complex ones. The elementary set is small and stable. `C` is a character field of fixed length, `N` a numeric text field, `I` an integer, `P` a packed decimal for amounts, `F` a floating point number, `D` a date in the form YYYYMMDD, `T` a time in HHMMSS, and `X` a byte field. `STRING` is a variable-length character field, and `XSTRING` its byte counterpart.

Complex types are built from these. A structure groups fields under one name, and a table type describes a table of structures or of elementary values. The Data Dictionary holds the global versions of these objects: a `tabelle` is a database table, a `viste` is a view, and `chiavi primarie` are the primary keys that identify a row. A transparent table in the Dictionary maps one to one onto a database table, and its field order matters for performance and for the generated code.

Choosing a type is not cosmetic. Amounts belong in `P` with a defined number of decimals, never in `F`, because floating point rounding produces totals that do not reconcile. Dates belong in `D` so that arithmetic and comparisons work. Text that varies in length belongs in `STRING`, while fixed codes such as a two-letter country key belong in `C` with an exact length. When a field is declared in the Dictionary, the report should reuse that type rather than redeclare it, so a later change to the table propagates instead of breaking the program.

Where can you find an ABAP keyword index?

SAP publishes the official reference in the ABAP Keyword Documentation, available in the system through transaction ABAPDOCU and online in the SAP Help Portal. It lists every statement, its syntax, its additions and its release restrictions. For a working programmer this is the authoritative source, and it is the one to check before trusting any tutorial.

Secondary indexes exist for people who want a shorter path. The Registro ABAP keeps an Italian-language index of keywords and statements next to its sections on internal tables and the Dictionary. Community sites and the SAP Community questions archive cover specific errors. None of them replaces the official documentation for syntax details, but they are faster when you only need to recall the name of a statement or the shape of an addition.

What does a first report look like?

A minimal report reads a table and prints the result. It starts with `REPORT`, declares a work area and an internal table with `DATA`, selects rows with `SELECT ... INTO TABLE`, sorts with `SORT`, and loops with `LOOP AT ... ENDLOOP` around a `WRITE` statement. Selection screens add `PARAMETERS` or `SELECT-OPTIONS` so the user can restrict the data before the query runs.

Two details decide whether the report is usable. The first is the `WHERE` clause: filtering in the database is far cheaper than filtering in the loop. The second is `sy-subrc` after the select. If the select returns nothing, the loop body never executes, and a report that does not say so leaves the user staring at an empty list with no explanation.

How do internal tables and the Dictionary connect?

A report rarely defines its own structures. It reads a Dictionary table into a work area typed after that table, or into an internal table of the same row type. `SELECT * FROM table INTO TABLE itab` fills the internal table directly. `APPEND` adds a row when the table is built line by line, `READ TABLE` retrieves one, `SORT` orders it, and `LOOP` processes it.

The Dictionary side supplies the names. A `tabelle` gives the row structure, a `viste` joins several tables into one readable object, and the `chiavi primarie` define which fields identify a record. When the report and the Dictionary agree on types, the code needs fewer conversions and fewer surprises after a transport. When they disagree, the program compiles and then fails on real data, which is the more expensive kind of error.

What to learn first

Learn the statement shape before the statement list. Keyword, operands, period, and the habit of checking `sy-subrc` after anything that can fail. Then learn the elementary types and when each is appropriate, because type mistakes surface late. Then learn internal tables, since almost every report is a loop over one. The keyword index and the official documentation come after that, as reference rather than as reading material. A programmer who can write a select, a sort and a loop, and who checks the return code, can already maintain most of the reports they will be handed.