/abap-performance-hana

name: abap-performance-hana
description: ABAP performance best practices for S/4HANA and HANA database systems.Use when writing or reviewing ABAP code on HANA-based systems.IMPORTANT: First use the SAP system info tool to check the system type — if the system is ECC or runs on a traditional database (Oracle, DB2, MSSQL), load the abap-performance-ecc skill instead. Covers code pushdown, CDS views, AMDP, advanced SQL, and HANA-optimized patterns.
argument-hint: '[ABAP code to optimize on HANA]'
user-invocable: true
disable-model-invocation: false

ABAP Performance — S/4HANA / HANA Database

These rules apply to SAP S/4HANA systems or any ABAP system running on HANA DB.

Before writing, optimizing, or reviewing ABAP code, read the `abap-code-review-helper` skill in full (skip if skill is unavailable), unless its complete contents are already available in your current context. Preserve its correctness safeguards; an optimization must not change result semantics. Keep passed checks internal.

**Before using this skill:** Call the SAP system info tool. If the system is ECC on a traditional DB, use the `abap-performance-ecc` skill instead.

**Core philosophy on HANA:** Push data-intensive operations to the database. HANA is a columnar in-memory DB optimized for set-based operations, aggregations, and complex SQL. Let it do the heavy lifting. Keep ABAP for business logic, authorization, and exception handling.

---

Code Pushdown — The #1 Rule

**Move data-intensive operations to the database layer.**

Push down to HANA:

• Aggregations (SUM, COUNT, AVG, MIN, MAX)
• Filtering (WHERE clauses — the more selective, the better)
• Sorting (ORDER BY)
• JOINs (HANA handles complex multi-table JOINs efficiently)
• String operations and arithmetic in SQL
• CASE expressions / conditional logic on data
• Grouping and HAVING
• Window functions (OVER/PARTITION BY)
• UNION / INTERSECT / EXCEPT

Keep in ABAP:

• Complex business logic with many branches
• Authority checks, messages, exceptions
• Small dataset processing where pushdown overhead exceeds benefit
• Operations requiring ABAP runtime features (RFC calls, file I/O, etc.)

Avoid:

• Reading all rows to ABAP and filtering/aggregating in loops
• Using internal tables as intermediate storage for what SQL can do in one statement
• Multiple sequential SELECTs that could be a single JOIN

---

Database Access

SELECT Patterns

• Select only the fields you need. Never `SELECT *` in production.

  SELECT matnr, maktx FROM mara INTO TABLE @DATA(itab).

• Always use a WHERE clause. Always use `@` escaped host variables.

• Use JOINs aggressively — HANA handles complex JOINs very well, even 5+ tables.

  SELECT m~matnr, t~maktx, p~werks, p~ekgrp
    FROM mara AS m
    INNER JOIN makt AS t ON t~matnr = m~matnr AND t~spras = @sy-langu
    INNER JOIN marc AS p ON p~matnr = m~matnr
    LEFT OUTER JOIN mvke AS s ON s~matnr = m~matnr
    WHERE m~mtart = @material_type
    INTO TABLE @DATA(materials).

• Use aggregate functions and GROUP BY — let HANA calculate:

  SELECT werks, SUM( labst ) AS total_stock, COUNT(*) AS item_count
    FROM mard
    WHERE matnr = @matnr
    GROUP BY werks
    INTO TABLE @DATA(stock_by_plant).

• Use CASE expressions to push conditional logic to the DB:

  SELECT matnr,
         CASE mtart
           WHEN 'FERT' THEN 'Finished'
           WHEN 'ROH' THEN 'Raw Material'
           ELSE 'Other'
         END AS type_text
    FROM mara
    INTO TABLE @DATA(materials).

• Use string functions in SQL:

  SELECT matnr, CONCAT( matnr, CONCAT( ' - ', maktx ) ) AS display_text
    FROM mara
    INNER JOIN makt ON makt~matnr = mara~matnr AND makt~spras = @sy-langu
    INTO TABLE @DATA(display_data).

• Use `FOR ALL ENTRIES` when JOINs aren't possible. **Always check driver table is not empty.**

• Use `UP TO n ROWS` when you only need limited results.

• Use subqueries where they simplify logic:

  SELECT matnr, maktx FROM mara
    WHERE matnr IN ( SELECT matnr FROM marc WHERE werks = @plant )
    INTO TABLE @DATA(plant_materials).

CDS Views

• **Prefer CDS views** for complex data models. They are the primary code pushdown mechanism on HANA.
• CDS views are reusable, testable, and automatically optimized by HANA.
• Use CDS for: complex joins, calculated fields, aggregations, associations, access control.
• Consume CDS views in ABAP via `SELECT FROM zcds_view`.

AMDP (ABAP-Managed Database Procedures)

• Use AMDP for very complex calculations that must run entirely on HANA.
• AMDP gives you access to full SQLScript (HANA's procedural SQL language).
• Use when: complex multi-step transformations, heavy string processing, graph operations, or when CDS is insufficient.
• AMDP is NOT portable to other DBs — use only when you're certain the system stays on HANA.

Avoiding Redundant DB Access

• Never SELECT the same data twice. Read once, reuse.
• Use `READ TABLE` on internal table buffer instead of `SELECT SINGLE` in a loop:

  SELECT matnr, maktx FROM makt WHERE spras = @sy-langu INTO TABLE @DATA(texts).
  " later:
  READ TABLE texts WITH KEY matnr = current_matnr INTO DATA(text_line).

• On HANA, even redundant DB access is faster than on traditional DBs — but it's still wasteful and adds network overhead.

Table Buffering

Buffering matters **less** on HANA than ECC because HANA is in-memory. But it still helps for:

• Reducing network round-trips between app server and DB server
• Avoiding query parsing overhead for tiny lookups

• Use `SELECT SINGLE` on buffered tables — reads from buffer. `UP TO 1 ROWS` bypasses buffer.

  " good — uses buffer
  SELECT SINGLE * FROM t001 WHERE bukrs = @bukrs INTO @DATA(company).
  " bad — bypasses buffer
  SELECT * FROM t001 UP TO 1 ROWS WHERE bukrs = @bukrs INTO @DATA(company).

• JOINs, aggregates, GROUP BY, ORDER BY, subqueries **bypass the buffer*