SAP ABAP basics

ABAP is a high-level, business-oriented language that runs inside the SAP application server. It has deep, built-in integration with the database (via Open SQL), the ABAP Dictionary, and SAP’s screens and business objects. It has evolved from procedural roots into a modern object-oriented language, and recent "ABAP for HANA" and CDS additions push logic down to the database.

One thing that surprises developers from other backgrounds: ABAP runs inside the application server and cannot be run outside it. There is no local development, no running a program on your own machine, and no build step in the usual sense. Code is written in a system, activated there, and runs there, which is why development, quality assurance and production systems exist and why transports rather than deployments move code between them.

Classic development uses the ABAP Workbench (SE80) and editor (SE38 for programs, SE24 for classes) in SAP GUI. Modern development increasingly uses ABAP Development Tools (ADT) in Eclipse, especially for CDS, RAP and cloud ABAP.

The practical guidance for anybody starting now: learn Eclipse with the ABAP Development Tools rather than SE80. Some objects, notably CDS views and anything in the RESTful programming model, can only be created there, so a developer limited to the classic workbench cannot work on modern development at all. The classic transactions remain useful for looking things up and for systems where Eclipse is not available.

REPORT z_hello.
DATA lv_name TYPE string VALUE 'SAP'.
WRITE: / |Hello, { lv_name }!|.

Coming from another language, the thing that will surprise you is how much of ABAP's typing is shared with the database, and how much that helps.

The Data Dictionary holds types centrally. A domain defines the technical characteristics: length, decimals, and optionally a fixed list of allowed values. A data element adds semantics: the field label a user sees, and the documentation. A structure groups fields, and a table type describes a set of them.

The consequence is that declaring a variable with TYPE matnr gives you the right length, the right conversion behaviour and the right screen label, everywhere, because the definition lives once in the dictionary. Changing the length of a field in the dictionary changes it in every program that referenced it.

Locally you also have elementary types: c for characters, n for numeric text, i for integers, p for packed decimals, which is what money uses, d and t for dates and times, and string for variable length.

Two traps worth knowing early. Character fields are padded to their length, so comparisons can surprise you. And p types need the decimals declared, or arithmetic truncates silently.

The instruction that follows: reference dictionary types rather than declaring lengths by hand. It is shorter, and it keeps your program correct when the underlying field changes.

An hour, and it takes you from hello world to something recognisably useful.

1. Create a report and declare an internal table typed from a dictionary table.
2. Select a limited number of rows into it, naming the fields rather than using an asterisk.
3. Loop over the table and write a few fields. Note that the output already knows how to format a date and a currency amount, because the types carry that.
4. Add a selection screen parameter and use it in the where clause, so the report takes input.
5. Replace the write statements with an ALV grid display. It takes a few lines and produces a sortable, filterable, exportable list, which is what users expect.
6. Set a breakpoint and step through it in the debugger, watching the internal table fill.

Steps five and six are the ones that matter for real work: nobody ships WRITE output, and nobody debugs by adding print statements. See ALV and debugging.

From here you learn data types and variables, control flow (loops, conditions), the workhorse internal tables, and then object-oriented ABAP (classes and methods), ALV reporting, and integration objects (BAPI, RFC, IDoc). Modern topics, CDS views and OData, connect ABAP to Fiori.

A realistic order for the first few months: syntax and types, then internal tables, which is where most ABAP time is spent, then selection screens and ALV so your programs are usable, then the debugger, then modularisation and classes, then Open SQL properly, then CDS. Enhancement and the frameworks come after that, because they assume the rest.

A great deal of ABAP in production predates the current style, and knowing what has been superseded stops you learning yesterday's habits from today's codebase.

Procedural over object-oriented. Reports built from form routines with global data still exist and are not how new code is written. Classes are the default.

Obsolete statements. Several older constructs still compile and are forbidden in modern syntax, and the compiler will tell you when strict mode is on.

Selecting then processing. The pattern of reading raw rows and calculating in ABAP has an Open SQL or CDS equivalent in most cases, and on HANA the difference is substantial.

Modifying standard code. Direct modification means every upgrade is a merge. Enhancement points, BAdIs and, in current landscapes, extension on the platform exist so that customisation survives an upgrade.

Hardcoded values. Client numbers, system names, file paths and company codes written into programs is what makes them fail after a transport into a different system.

The general instruction: when a codebase shows you a pattern, check whether it is current before adopting it, because much of what is in production was correct when it was written.

New developers write everything as a report because that is what they learned first. Knowing the alternatives saves a lot of unnecessary code.

A report suits something a user runs with a selection screen and reads.

A CDS view suits anything that is reading and shaping data for consumption, and it does that better than ABAP can.

A class suits logic that is reused or needs testing, and it is where business rules belong.

An enhancement or BAdI suits changing standard behaviour, and it is what keeps that change surviving an upgrade.

Configuration suits a surprising amount of what gets requested as development, and the first question on any requirement is whether the standard already does it.

The instinct worth building early: ask what the smallest thing is that meets the requirement, because every line written is a line to maintain through every upgrade.

• Learning only procedural ABAP, modern ABAP is object-oriented and CDS-based.
• Ignoring Open SQL performance from the start.
• Skipping ADT/Eclipse, the modern development environment.

• Learning from tutorials written for older releases. Much of what they teach still compiles and is no longer how it is done.
• Declaring types by hand. It works until the underlying field changes and every program that guessed is now wrong.
• Skipping the debugger. See internal tables and ABAP performance for the two things that most affect whether your code survives real data.

• Copying a pattern from production code without checking its age. Much of what is running was correct when it was written and is not how it would be written now.

Writing a first report is straightforward, and building one that reads efficiently, displays properly and can be debugged is the part you do in the course.

The habit worth forming from day one is referencing dictionary types rather than declaring lengths by hand. It is shorter to write and it keeps your program correct when somebody changes the field underneath it.