... END OF BLOCK`. --- ### 8. Program Events in Report Programs - **INITIALIZATION**: Executes first when opening a report program, used for initializing defaults. - **AT SELECTION-SCREEN**: Triggers when user interacts with or submits the selection screen, ideal for input validation. - **START-OF-SELECTION**: Kicks off upon pressing Execute (**F8**), containing core business processing and data queries. --- ### 9. Operations, Date/Time Arithmetic & System Variables - **Arithmetic Operations**: Uses standard operators (`+`, `-`, `*`, `/`), integer division (`DIV`), modulo (`MOD`), and square root (`SQRT`). - **Date (D) & Time (T) Calculations**: Automatically calculates date/time rollovers (e.g., adding 1 day to `20231231` yields `20240101`). Substring offset access uses `<var>+<offset>(<length>)`. - **Key System Variables (sy-)**: - `sy-subrc`: Return code of the previous statement (`0` = success, non-zero e.g., `4` = failure). - `sy-tabix`: Current line index inside an internal table loop (`LOOP AT`). - `sy-datum`: Current system date. - `sy-uzeit`: Current system time. - `sy-uname`: Logged-in user name. - `sy-langu`: Logged-in language. - `sy-tcode`: Current transaction code. - `sy-repid`: Current program ID. --- ### 10. Debugging Capabilities - **ABAP Debugger**: Allows setting breakpoints to step line-by-line (using **F6** to step over, **F8** to continue) to monitor real-time data transformations and diagnose runtime dumps or logic errors. 23:T800,ABAP Basic Statements 1. Basic Syntax Rules & Comments - Statement Termination: Every ABAP statement must end with a period (\\.\\). A statement can span across multiple lines until a period is encountered. - Case Insensitivity: ABAP code is case-insensitive; keywords, additions, and operands can be written in uppercase or lowercase. - Comments: - An asterisk (\) at the very first position of a line comments out the entire line. - A double quote (\\"\\) comments out everything from that position to the end of the line. - Chained Statements: Multiple statements repeating the same keyword can be chained using a colon (\\:\\) and separated by commas (\\,\\) (e.g., WRITE: var1, var2.). --- 2. Data Objects & Type Declarations - Data Objects: ABAP distinguishes between Variables (DATA), Constants (CONSTANTS), and Literals (text in '...', string in ... , or numbers). - Variable Declaration: Declared using DATA <variablename TYPE <datatype with an optional VALUE addition. To copy the type of an existing data object, use LIKE. - Local vs. Global Types: - Local Data Types (TYPES): Defined locally within a program. If a local type shares the same name as a global type, the local definition takes precedence. - Global Data Types: Created and managed system-wide via the ABAP Dictionary (transaction code SE11). - Predefined Data Types: - Complete Data Types (fixed length): D (Date - 8 characters YYYYMMDD), T (Time - 6 characters HHMMSS), I (Integer - 4 bytes, range -2^31 to +2^31), STRING (dynamic character string). - Incomplete Data Types (length required): C (Character), N (Numeric text), and P (Packed number - used for calculations/currencies with DECIMALS specification). - Internal Tables: Declared using DATA <tablename TYPE TABLE OF <linetype to hold lists of structured data. --- 3. Coding Convension - Custom Type: GT, GTS, GTT\ - Constant: GC\ - Global variables: GD\ - Work Area (Structure): GS\ - Internal Table: GT\ - Local variables: LD\ - Local work area: LS\ - Local internal table: LT\ - Selection-screen Parameter: P\24:T7f3,## ABAP Basic Statements ### 1. Basic Syntax Rules & Comments - **Statement Termination**: Every ABAP statement must end with a **period (\*\***.\***\*)**. A statement can span across multiple lines until a period is encountered. - **Case Insensitivity**: ABAP code is case-insensitive; keywords, additions, and operands can be written in uppercase or lowercase. - **Comments**: - An **asterisk** (\*) at the very first position of a line comments out the entire line. - A **double quote (\*\***"\***\*)** comments out everything from that position to the end of the line. - **Chained Statements**: Multiple statements repeating the same keyword can be chained using a **colon (\*\***:\***\*)** and separated by **commas (\*\***,\***\*)** (e.g., `WRITE: var1, var2.`). --- ### 2. Data Objects & Type Declarations - **Data Objects**: ABAP distinguishes between **Variables** (`DATA`), **Constants** (`CONSTANTS`), and **Literals** (text in `'...'`, string in `` `...` ``, or numbers). - **Variable Declaration**: Declared using `DATA <variable_name> TYPE <data_type>` with an optional `VALUE` addition. To copy the type of an existing data object, use `LIKE`. - **Local vs. Global Types**: - **Local Data Types** (`TYPES`): Defined locally within a program. If a local type shares the same name as a global type, the local definition takes **precedence**. - **Global Data Types**: Created and managed system-wide via the **ABAP Dictionary** (transaction code `SE11`). - **Predefined Data Types**: - **Complete Data Types** (fixed length): `D` (Date - 8 characters `YYYYMMDD`), `T` (Time - 6 characters `HHMMSS`), `I` (Integer - 4 bytes, range -2^31 to +2^31), `STRING` (dynamic character string). - **Incomplete Data Types** (length required): `C` (Character), `N` (Numeric text), and `P` (Packed number - used for calculations/currencies with `DECIMALS` specification). - **Internal Tables**: Declared using `DATA <table_name> TYPE TABLE OF <line_type>` to hold lists of structured data. --- ### 3. Coding Convension25:T22f5, ## 1. System Overview & Architecture The **ABAP Data Dictionary (DDIC)**, managed via Transaction Code **`SE11`**, is an integrated database management framework embedded within the SAP ABAP application server. It acts as a database abstraction layer positioned between SAP application programs and the underlying Relational Database Management System (RDBMS) such as Oracle or Microsoft SQL Server. ``` +-------------------------------------------------------+ | SAP Application Layer | | (ABAP Programs, SE38, SE80) | +-------------------------------------------------------+ | v +-------------------------------------------------------+ | ABAP Data Dictionary (SE11) | | (Domains, Data Elements, Structures, Tables, Views) | +-------------------------------------------------------+ | v (Auto-generated DDL / Objects) +-------------------------------------------------------+ | Underlying RDBMS Layer | | (Oracle, MS SQL Server, SAP HANA) | +-------------------------------------------------------+ ``` ### Key Functional Capabilities - **Database Independence**: Eliminates the requirement for developers to write platform-specific SQL Data Definition Language (DDL) scripts. - **Centralized Object Reuse**: Enables system-wide definition and reuse of global data types, database tables, views, and search helps. - **Active Runtime Catalog**: Database table structures defined in the DDIC are compiled directly into physical database objects upon activation. --- ## 2. Elementary Data Type Architecture: Domain vs. Data Element ![[../images/domain-data-element.png]] Data field definitions in the ABAP Dictionary decouple **technical parameters** from **business semantics** through a two-tier architecture comprising **Domains** and **Data Elements**. ![[../images/domain-data-element-1.png]] ### 2.1 Domain (Technical Attribute Layer) - **Definition**: Defines the physical and technical attributes of a data field. - **Technical Parameters**: - Built-in Data Type (e.g., `CHAR`, `NUMC`, `DEC`, `DATS`, `TIMS`). - Field Length and **Output Length** (accounts for formatting characters such as decimal points, currency signs, or negative indicators). - Case Sensitivity toggle (`Lower Case` / `Case Sensitive`). - **Value Restrictions**: - **Fixed Values (Value Range)**: Hardcoded valid single values or interval ranges enforced at domain level. - **Value Table**: Points to a master check table containing allowable key entries. ### 2.2 Data Element (Semantic Attribute Layer) - **Definition**: Defines the business meaning and contextual usage of a data object. - **Semantic Attributes**: - **UI Field Labels**: Defines Short, Medium, Long, and Heading labels displayed across screens and report columns. - **F1 Help Documentation**: Links to detailed documentation created via the documentation editor for end-user assistance. - **Relationship**: References a Domain to inherit technical attributes. A single Domain can be referenced by multiple Data Elements (e.g., Domain `S_CITY` referenced by Data Elements `S_FROMCIT` and `S_TOCITY`). - **Naming Conventions**: Domains and Data Elements reside in distinct object namespaces and can share identical names, though project guidelines typically utilize prefixes (e.g., `DO_` for domains, `DE_` for data elements). ### Example: ## ![[../images/domain-data-element-2.png]] ## 3. Composite Data Objects & Database Tables ### 3.1 Structures - **Definition**: Reusable, structured type definitions comprising a sequence of named components/fields. - **Behavior**: Structures do **not** persist data in the physical database. - **Applications**: - Used in ABAP programs to instantiate **Work Areas** (single-row structures). - Included directly within database table definitions via the **`INCLUDE`** statement to standardize field groups across multiple tables. ### 3.2 Data Categories in SAP 1. **Master Data**: Core entity records modified infrequently (e.g., Customer, Vendor, Material, Employee). 2. **Transactional Data**: High-volume operational transaction records (e.g., Sales Orders, Purchase Orders, Accounting Documents). 3. **Configuration Data**: System customization parameters established during project setup (e.g., Currency Codes, Payment Terms). 4. **System Data**: System administration and administrative runtime logs. ### 3.3 Database Table Types | Table Type | Description & Physical Mapping | | :-------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Transparent Table** | **1-to-1 Mapping**: Each transparent table defined in `SE11` corresponds to exactly one physical table in the database. | | **Pooled Table** | **N-to-1 Mapping**: Multiple logical pooled tables consolidated into a single physical table in the database; used primarily by system tables. | | **Cluster Table** | **N-to-1 Mapping**: Multiple logical cluster tables combined into a single database cluster table (e.g., `BSEG`); optimized for complex structural documents, considered legacy in SAP HANA. | | **Table Type** | **Global Memory Type**: A DDIC object defining internal table types used for ABAP program execution, containing no database persistence. | ### 3.4 Relational Features - **Primary Key**: Uniquely identifies each record in a database table. Key fields cannot be edited directly after record insertion. - **Client Dependency (`MANDT` / `CLIENT`)**: Automatic client separation is achieved by defining the primary key field `MANDT` (Data Element `MANDT`), ensuring data isolation per system client. - **Foreign Keys & Check Tables**: Foreign key field definitions map fields to a **Check Table** to maintain relational data integrity and auto-generate F4 input validation. --- ## 4. Database Views & Core Data Services (CDS) Views are logical definitions that join fields across one or more tables without duplicating physical data. ### 4.1 Classic DDIC Views (`SE11`) 1. **Database View**: Implements standard inner joins across database tables for read access. 2. **Maintenance View**: Configures table joins specifically to power Table Maintenance Generators (TMG) for administrative data entry. 3. **Projection View**: Selects a subset of fields from a single table to mask unwanted attributes. 4. **Help View**: Serves as the data selection foundation for Search Helps. ### 4.2 Core Data Services (CDS) Views - **Architecture**: Modern, code-based data modeling tool defined inside Eclipse ADT using SQL DDL syntax. - **Integration**: Automatically generates a underlying classic SQL View (limited to 16 characters) accessible via standard `SE11` and `SE16N` queries. --- ## 5. Input Assistance & Data Inspection ### 5.1 Search Help (F4 Help) Provides user assistance dialogs during UI field input. - **Elementary Search Help**: Defines a single search path, specifying the selection method (table/view), input/output parameters, and hit list layout. - **Collective Search Help**: Combines multiple Elementary Search Helps into a single tabbed dialog interface. ### 5.2 Data Inspection Utilities - **`SE16`**: Classic ABAP Workbench data browser utility; supports ALV Grid display via user parameter adjustments. - **`SE16N`**: Enhanced application data browser providing field filtering and record inspection capabilities. --- ## 6. Technical Settings & Performance Guidelines Every database table created in `SE11` requires technical settings configuration prior to activation: - **Delivery Class**: Specifies table data maintenance rules and client transport behavior (e.g., `A` for Application Master/Transaction data, `C` for Customizing). - **Data Class**: Determines physical database space allocation: - `APPL0`: Master Data. - `APPL1`: Transactional Data. - `USER`: User-specific datasets. - **Size Category**: Configures initial database extent allocation based on expected row count ranges. - **Buffering & Logging**: Enables application server memory caching for static tables or logs change operations. - **Secondary Indexes**: Additional index structures created on non-key columns to accelerate read performance; must be balanced against maintenance overhead during insert/update operations. ![[../images/domain-data-element-3.png]] 26:Ta28,1. System Overview & Architecture The ABAP Data Dictionary (DDIC), managed via Transaction Code SE11, is an integrated database management framework embedded within the SAP ABAP application server. It acts as a database abstraction layer positioned between SAP application programs and the underlying Relational Database Management System (RDBMS) such as Oracle or Microsoft SQL Server. +-------------------------------------------------------+ | SAP Application Layer | | (ABAP Programs, SE38, SE80) | +-------------------------------------------------------+ | v +-------------------------------------------------------+ | ABAP Data Dictionary (SE11) | | (Domains, Data Elements, Structures, Tables, Views) | +-------------------------------------------------------+ | v (Auto-generated DDL / Objects) +-------------------------------------------------------+ | Underlying RDBMS Layer | | (Oracle, MS SQL Server, SAP HANA) | +-------------------------------------------------------+ Key Functional Capabilities - Database Independence: Eliminates the requirement for developers to write platform-specific SQL Data Definition Language (DDL) scripts. - Centralized Object Reuse: Enables system-wide definition and reuse of global data types, database tables, views, and search helps. - Active Runtime Catalog: Database table structures defined in the DDIC are compiled directly into physical database objects upon activation. --- 2. Elementary Data Type Architecture: Domain vs. Data Element ![[../images/domain-data-element.png]] Data field definitions in the ABAP Dictionary decouple technical parameters from business semantics through a two-tier architecture comprising Domains and Data Elements. ![[../images/domain-data-element-1.png]] 2.1 Domain (Technical Attribute Layer) - Definition: Defines the physical and technical attributes of a data field. - Technical Parameters: - Built-in Data Type (e.g., CHAR, NUMC, DEC, DATS, TIMS). - Field Length and Output Length (accounts for formatting characters such as decimal points, currency signs, or negative indicators). - Case Sensitivity toggle (Lower Case / Case Sensitive). - Value Restrictions: - Fixed Values (Value Range): Hardcoded valid single values or interval ranges enforced at domain level. - Value Table: Points to a master check table containing allowable key entries. 2.2 Data Element (Semantic Attribute Layer) - Definition: Defines the business meaning and contextual usage of a data object. - Semantic Attributes: - UI Field Labels: Defines Short, Medium, Long, and Heading labels displayed across screens and report columns. -27:Tabf,## 1. System Overview & Architecture The **ABAP Data Dictionary (DDIC)**, managed via Transaction Code **`SE11`**, is an integrated database management framework embedded within the SAP ABAP application server. It acts as a database abstraction layer positioned between SAP application programs and the underlying Relational Database Management System (RDBMS) such as Oracle or Microsoft SQL Server. ``` +-------------------------------------------------------+ | SAP Application Layer | | (ABAP Programs, SE38, SE80) | +-------------------------------------------------------+ | v +-------------------------------------------------------+ | ABAP Data Dictionary (SE11) | | (Domains, Data Elements, Structures, Tables, Views) | +-------------------------------------------------------+ | v (Auto-generated DDL / Objects) +-------------------------------------------------------+ | Underlying RDBMS Layer | | (Oracle, MS SQL Server, SAP HANA) | +-------------------------------------------------------+ ``` ### Key Functional Capabilities - **Database Independence**: Eliminates the requirement for developers to write platform-specific SQL Data Definition Language (DDL) scripts. - **Centralized Object Reuse**: Enables system-wide definition and reuse of global data types, database tables, views, and search helps. - **Active Runtime Catalog**: Database table structures defined in the DDIC are compiled directly into physical database objects upon activation. --- ## 2. Elementary Data Type Architecture: Domain vs. Data Element ![[../images/domain-data-element.png]] Data field definitions in the ABAP Dictionary decouple **technical parameters** from **business semantics** through a two-tier architecture comprising **Domains** and **Data Elements**. ![[../images/domain-data-element-1.png]] ### 2.1 Domain (Technical Attribute Layer) - **Definition**: Defines the physical and technical attributes of a data field. - **Technical Parameters**: - Built-in Data Type (e.g., `CHAR`, `NUMC`, `DEC`, `DATS`, `TIMS`). - Field Length and **Output Length** (accounts for formatting characters such as decimal points, currency signs, or negative indicators). - Case Sensitivity toggle (`Lower Case` / `Case Sensitive`). - **Value Restrictions**: - **Fixed Values (Value Range)**: Hardcoded valid single values or interval ranges enforced at domain level. - **Value Table**: Points to a master check table containing allowable key entries. ### 2.2 Data Element (Semantic Attribute Layer)28:T201d, ## 1. Architecture & Execution Model **Open SQL** is an embedded subset of ANSI SQL fully integrated into the ABAP programming language. It acts as an abstraction layer between application programs and the underlying database management system (DBMS). ``` +-------------------------------------------------------+ | ABAP Application Layer | | (Open SQL Statements / SE38) | +-------------------------------------------------------+ | v (ABAP Syntax Check & Compilation) +-------------------------------------------------------+ | ABAP Database Interface | | (Translates Open SQL into Native SQL DML) | +-------------------------------------------------------+ | v (Database-Specific SQL Execution) +-------------------------------------------------------+ | Underlying RDBMS Layer | | (Oracle, MS SQL Server, SAP HANA) | +-------------------------------------------------------+ ``` ### 1.1 Key Architectural Properties - **Database Independence**: Open SQL statements are uniform across all supported database platforms. The **Database Interface** automatically converts Open SQL statements into the platform-specific **Native SQL** required by the underlying RDBMS (e.g., Oracle, MS SQL Server). - **Integrated Syntax Validation**: Because Open SQL is a native component of the ABAP language, the ABAP compiler validates SQL syntax directly during program compilation. - **Open SQL vs. Native SQL**: - **Open SQL**: Portable, database-agnostic, statically syntax-checked by the ABAP IDE, and automatically managed by the database interface. - **Native SQL**: Executes database-specific DML/DDL scripts directly. It bypasses the Database Interface, sacrificing portability and static compile-time syntax checks. - **Legacy Table Declarations**: The obsolete `TABLES <table>` statement implicitly creates a structure/work area sharing the table's name. Modern ABAP standards explicitly discourage this statement in favor of explicit type definitions. --- ## 2. Fundamental Query Syntax & Row Selection A standard Open SQL data retrieval statement consists of four core clauses: `SELECT`, `FROM`, `INTO`, and `WHERE`. ```abap SELECT <fields> FROM <table> INTO <target> WHERE <conditions>. ``` ### 2.1 Filtering & Evaluation (`WHERE`) - **Conditional Operators**: Supports standard comparison operators (`=`, `<`, `>`, `<=`, `>=`, `<>`), string pattern matching (`CP`, `CF`), range operators (`BETWEEN`, `IN`), and logical connectors (`AND`, `OR`, `NOT`). - **Selection Tables**: The `IN` operator evaluates field values against selection tables or range tables. ### 2.2 Row-Limiting Techniques - **`SELECT SINGLE`**: - Fetches a single record matching the query criteria. - **Best Practice**: Pass the complete primary key in the `WHERE` clause to guarantee deterministic behavior. - Does not open a database loop and does not require an `ENDSELECT` statement. - **`UP TO n ROWS`**: - Limits the result set to `n` rows. - **Best Practice**: Recommended over `SELECT SINGLE` when filtering on partial key fields. - Requires an `ENDSELECT` statement when selecting row-by-row into a work area. ### 2.3 Result Ordering & Deduplication - **`ORDER BY`**: Guarantees output row ordering. Can sort by `PRIMARY KEY` or by specific columns using `ASCENDING` or `DESCENDING` modifiers. - **`DISTINCT`**: Eliminates duplicate result rows prior to populating the target data object. ### 2.4 System Fields - **`sy-subrc`**: Returns `0` if the query successfully retrieves data, and `4` if no matching records are found. - **`sy-dbcnt`**: Contains the total count of records retrieved or processed by the query. --- ## 3. Aggregation & Grouping Open SQL provides built-in aggregation functions to perform calculations directly on the database engine prior to returning results. | Aggregation Function | Description | | :------------------------------ | :-------------------------------------------------------- | | `COUNT( * )` / `COUNT( field )` | Returns the total count of rows or non-null field values. | | `MAX( field )` | Identifies the maximum value in a column. | | `MIN( field )` | Identifies the minimum value in a column. | | `SUM( field )` | Calculates the total sum of a numeric column. | | `AVG( field )` | Computes the average value of a numeric column. | ### 3.1 Grouping Requirement (`GROUP BY`) When an Open SQL statement includes both scalar columns and aggregate functions in the `SELECT` clause, **all non-aggregated columns must be explicitly listed in the `GROUP BY` clause**. ```abap SELECT carrid, MAX( flytime ), MIN( flytime ) FROM spfli INTO (lv_carrid, lv_max_time, lv_min_time) GROUP BY carrid. ``` --- ## 4. Target Data Objects & Mapping Strategies Data retrieved via Open SQL can be mapped into single-row **Work Areas** or multi-row **Internal Tables**. ``` positional mapping (INTO TABLE): Database Columns: [ MANDT ] [ CARRID ] [ CONNID ] [ COUNTRYFR ] | | | | Target Structure: [ MANDT ] [ CARRID ] [ CONNID ] [ COUNTRYFR ] name-based mapping (INTO CORRESPONDING FIELDS OF TABLE): Database Columns: [ CARRID ] [ CONNID ] [ COUNTRYFR ] | | | +-----------+------------+ (Matches by Name) | Target Structure: [ STATUS ] [ CARRID ] [ CONNID ] [ COUNTRYFR ] ``` ### 4.1 Target Object Comparison | Feature | Work Area (`STRUCTURE`) | Internal Table (`INTERNAL TABLE`) | | :---------------- | :------------------------------------------------- | :---------------------------------------------- | | **Capacity** | Holds a single row of data at a time. | Holds multi-row datasets in application memory. | | **Access Syntax** | Direct field component selection (`<wa>-<field>`). | Iterated using `LOOP AT <itab> INTO <wa>`. | | **Target Clause** | `INTO <work_area>`. | `INTO TABLE <internal_table>`. | ### 4.2 Positional Mapping vs. Name-Based Mapping - **`INTO TABLE <itab>`**: Transfers column data sequentially based on field positions. If the target structure layout differs from the `SELECT` clause field order, data misalignment or truncation occurs. - **`INTO CORRESPONDING FIELDS OF TABLE <itab>`**: Matches database table columns to internal table fields strictly by **field name**, ignoring structural field sequence. Unmapped target fields remain set to their initial values. --- ## 5. Multi-Table Operations & Advanced Filtering ### 5.1 Relational Joins (`JOIN`) Joins combine records across multiple database tables within a single database request. Fields are qualified using tilde syntax (`<table>~<field>` or `<alias>~<field>`). - **`INNER JOIN`**: Returns combined records only when join conditions match in both left and right tables. - **`LEFT OUTER JOIN`**: Returns all rows from the left table. If no matching row exists in the right table, right-table fields are populated with type-specific initial values. ```abap SELECT header~vbeln, header~kunnr, item~posnr, item~matnr FROM vbak AS header INNER JOIN vbap AS item ON header~vbeln = item~vbeln INTO TABLE @DATA(lt_orders). ``` ### 5.2 Internal Table Filtering (`FOR ALL ENTRIES IN`) The `FOR ALL ENTRIES IN` clause evaluates an Open SQL query against all entries in a pre-populated driver internal table. - **Behavior**: Replaces large, complex database joins by using in-memory driver tables as filter criteria. - **Syntax**: ```abap SELECT doc_type, company_code, doc_num FROM bkpf INTO TABLE lt_headers FOR ALL ENTRIES IN lt_filter_tab WHERE doc_type = lt_filter_tab-doc_type. ``` --- 29:T9e1,1. Architecture & Execution Model Open SQL is an embedded subset of ANSI SQL fully integrated into the ABAP programming language. It acts as an abstraction layer between application programs and the underlying database management system (DBMS). +-------------------------------------------------------+ | ABAP Application Layer | | (Open SQL Statements / SE38) | +-------------------------------------------------------+ | v (ABAP Syntax Check & Compilation) +-------------------------------------------------------+ | ABAP Database Interface | | (Translates Open SQL into Native SQL DML) | +-------------------------------------------------------+ | v (Database-Specific SQL Execution) +-------------------------------------------------------+ | Underlying RDBMS Layer | | (Oracle, MS SQL Server, SAP HANA) | +-------------------------------------------------------+ 1.1 Key Architectural Properties - Database Independence: Open SQL statements are uniform across all supported database platforms. The Database Interface automatically converts Open SQL statements into the platform-specific Native SQL required by the underlying RDBMS (e.g., Oracle, MS SQL Server). - Integrated Syntax Validation: Because Open SQL is a native component of the ABAP language, the ABAP compiler validates SQL syntax directly during program compilation. - Open SQL vs. Native SQL: - Open SQL: Portable, database-agnostic, statically syntax-checked by the ABAP IDE, and automatically managed by the database interface. - Native SQL: Executes database-specific DML/DDL scripts directly. It bypasses the Database Interface, sacrificing portability and static compile-time syntax checks. - Legacy Table Declarations: The obsolete TABLES <table statement implicitly creates a structure/work area sharing the table's name. Modern ABAP standards explicitly discourage this statement in favor of explicit type definitions. --- 2. Fundamental Query Syntax & Row Selection A standard Open SQL data retrieval statement consists of four core clauses: SELECT, FROM, INTO, and WHERE. abap SELECT <fields FROM <table INTO <target WHERE <conditions. 2.1 Filtering & Evaluation (WHERE) - Conditional Operators: Supports standard comparison operators (=, <, , <=, =, <), string pattern matching (CP, CF), range operators (BETWEEN, IN), and logical connectors (AND, OR, NOT). - Selection Tables: The IN operator evaluates field values against selection tables or range tables. 2.2 Row-Limiting Techniques - SELECT SINGLE: - Fetches a single record matching the query2a:Tb38,## 1. Architecture & Execution Model **Open SQL** is an embedded subset of ANSI SQL fully integrated into the ABAP programming language. It acts as an abstraction layer between application programs and the underlying database management system (DBMS). ``` +-------------------------------------------------------+ | ABAP Application Layer | | (Open SQL Statements / SE38) | +-------------------------------------------------------+ | v (ABAP Syntax Check & Compilation) +-------------------------------------------------------+ | ABAP Database Interface | | (Translates Open SQL into Native SQL DML) | +-------------------------------------------------------+ | v (Database-Specific SQL Execution) +-------------------------------------------------------+ | Underlying RDBMS Layer | | (Oracle, MS SQL Server, SAP HANA) | +-------------------------------------------------------+ ``` ### 1.1 Key Architectural Properties - **Database Independence**: Open SQL statements are uniform across all supported database platforms. The **Database Interface** automatically converts Open SQL statements into the platform-specific **Native SQL** required by the underlying RDBMS (e.g., Oracle, MS SQL Server). - **Integrated Syntax Validation**: Because Open SQL is a native component of the ABAP language, the ABAP compiler validates SQL syntax directly during program compilation. - **Open SQL vs. Native SQL**: - **Open SQL**: Portable, database-agnostic, statically syntax-checked by the ABAP IDE, and automatically managed by the database interface. - **Native SQL**: Executes database-specific DML/DDL scripts directly. It bypasses the Database Interface, sacrificing portability and static compile-time syntax checks. - **Legacy Table Declarations**: The obsolete `TABLES <table>` statement implicitly creates a structure/work area sharing the table's name. Modern ABAP standards explicitly discourage this statement in favor of explicit type definitions. --- ## 2. Fundamental Query Syntax & Row Selection A standard Open SQL data retrieval statement consists of four core clauses: `SELECT`, `FROM`, `INTO`, and `WHERE`. ```abap SELECT <fields> FROM <table> INTO <target> WHERE <conditions>. ``` ### 2.1 Filtering & Evaluation (`WHERE`) - **Conditional Operators**: Supports standard comparison operators (`=`, `<`, `>`, `<=`, `>=`, `<>`), string pattern matching (`CP`, `CF`), range operators (`BETWEEN`, `IN`), and logical connectors (`AND`, `OR`, `NOT`). - **Selection Tables**: The `IN` operator evaluates field values against selection tables or range tables. ### 2.2 Row-Limiting Techniques2b:T6055, ## 1. Mental Model: Type, Structure, Work Area, and Internal Table Do not treat these as four equivalent objects. ```text TYPES declaration defines a type; it does not hold runtime values │ ├── DATA structure one structured data object │ └── may serve as a work area │ └── DATA internal table zero or more lines of one line type ``` ### 1.1 Structured type A structured type defines named components and their types. `TYPES` creates a type, not a runtime data object. ```abap TYPES: BEGIN OF ty_flight, carrier_id TYPE c LENGTH 3, connection_id TYPE n LENGTH 4, city_from TYPE c LENGTH 40, city_to TYPE c LENGTH 40, price TYPE p LENGTH 8 DECIMALS 2, currency TYPE c LENGTH 3, END OF ty_flight. ``` The type can be local, defined globally in a class/interface, or supplied by a released Dictionary/CDS artifact. `SE11` is a classic Dictionary maintenance tool, not the definition of the ABAP concept itself. ### 1.2 Structure data object `DATA` instantiates a data object and therefore allocates runtime state. ```abap DATA flight TYPE ty_flight. ``` The word **structure** can mean either a structured type or a structured data object, depending on context. Say which one you mean in technical explanations. ### 1.3 Work area A **work area** is a role played by a single data object when a table statement copies one line into it or reads a line from it. It is not a separate ABAP type category. ```abap DATA flight TYPE ty_flight. LOOP AT flights INTO flight. " flight is the work area for this loop ENDLOOP. ``` ### 1.4 Internal table An internal table is an in-memory ABAP data object containing zero or more lines. Its type is defined by: 1. line type; 2. table category; 3. primary table key; 4. optional secondary table keys. It is not a database table and is not persisted by `COMMIT WORK`. Its lifetime follows the lifetime and scope of its owning ABAP data object. ```abap TYPES ty_flights TYPE STANDARD TABLE OF ty_flight WITH EMPTY KEY. DATA flights TYPE ty_flights. ``` ### 1.5 Database boundary ```text Database table / CDS entity │ SELECT ▼ Internal table in ABAP application-server memory │ processing ▼ INSERT / UPDATE / MODIFY / DELETE or EML, when explicitly executed ``` Changing an internal-table line does not automatically update a database table or a RAP business object. --- ## 2. Complete, Reusable Example Types The examples below use explicit keys so their behavior is visible. ```abap TYPES: BEGIN OF ty_flight, carrier_id TYPE c LENGTH 3, connection_id TYPE n LENGTH 4, city_from TYPE c LENGTH 40, city_to TYPE c LENGTH 40, price TYPE p LENGTH 8 DECIMALS 2, currency TYPE c LENGTH 3, END OF ty_flight. TYPES ty_flights_seq TYPE STANDARD TABLE OF ty_flight WITH EMPTY KEY. TYPES ty_flights_sorted TYPE SORTED TABLE OF ty_flight WITH UNIQUE KEY primary_key COMPONENTS carrier_id connection_id. TYPES ty_flights_hashed TYPE HASHED TABLE OF ty_flight WITH UNIQUE KEY primary_key COMPONENTS carrier_id connection_id. DATA flights_seq TYPE ty_flights_seq. DATA flights_sorted TYPE ty_flights_sorted. DATA flights_hashed TYPE ty_flights_hashed. ``` `WITH EMPTY KEY` is a deliberate statement: the standard table is being used as a sequence, not as a keyed collection. --- ## 3. Table Categories Big-O values below are useful mental models, not promises about every kernel, row width, cache state, or access form. | Category | Primary organization | Primary-key uniqueness | Efficient access | Typical use | | ---------------- | ------------------------------------------ | ---------------------- | ----------------------------------------------------------- | ---------------------------------------------------- | | `STANDARD TABLE` | Primary index in insertion order | Non-unique or empty | Index access; sequential processing | Append-heavy lists, ordered processing, small tables | | `SORTED TABLE` | Primary index always sorted by primary key | Unique or non-unique | Left-aligned primary-key access, approximately `O(log n)` | Range reads and frequent ordered key access | | `HASHED TABLE` | Hash administration; no primary index | Must be unique | Complete primary-key equality, approximately `O(1)` average | Fast exact lookup by a unique key | ### 3.1 Standard table - Fast append and index access. - A normal key search is linear unless an appropriate secondary key or a valid binary-search pattern is used. - The primary key does not enforce uniqueness. - Prefer `WITH EMPTY KEY` when the table is intentionally only a sequence. ### 3.2 Sorted table - Lines are always maintained in ascending primary-key order. - The primary key may be unique or non-unique. - Optimized access requires the search components to form a usable left-aligned part of the sorted key. - It supports index access because it is an index table. For a key `(carrier_id, connection_id)`, searching by `carrier_id` can use the sorted prefix; searching only by `connection_id` cannot use that primary-key prefix efficiently. ### 3.3 Hashed table - The primary key must be unique. - Best for equality lookup using the complete hash key. - No primary index access such as `INDEX 1`. - Partial-key and range searches do not receive the main hash advantage. ### 3.4 Selection rule ```text Need stable index/insertion order or mostly append/loop? → STANDARD Need sorted traversal, ranges, or prefix-key lookup? → SORTED Need exact lookup by one complete unique key? → HASHED Need several access paths? → Add justified secondary keys; do not copy the table automatically ``` --- ## 4. Primary and Secondary Table Keys A table key is not merely documentation. It determines uniqueness, access optimization, ordering for sorted keys, and maintenance cost. ### 4.1 Secondary-key example ```abap TYPES ty_flights_multi TYPE STANDARD TABLE OF ty_flight WITH EMPTY KEY WITH UNIQUE HASHED KEY by_connection COMPONENTS carrier_id connection_id WITH NON-UNIQUE SORTED KEY by_route COMPONENTS city_from city_to. ``` ```abap READ TABLE flights_multi WITH TABLE KEY by_connection COMPONENTS carrier_id = 'LH' connection_id = '0400' INTO DATA(flight). LOOP AT flights_multi INTO DATA(route_flight) USING KEY by_route WHERE city_from = 'FRANKFURT'. " Uses the named sorted access path when the condition fits the key ENDLOOP. ``` ### 4.2 Secondary-key trade-off Secondary keys can make reads much faster, but they require extra memory and must be maintained when table content changes. Add one only for a demonstrated access pattern, not “for performance” in the abstract. --- ## 5. Assignment and Name-Based Mapping The original claim that normal assignment can silently “misalign” fields is too broad. ABAP checks assignment compatibility and applies the defined assignment rules. It does not simply scramble fields because their names differ. Use direct assignment when source and target types are compatible: ```abap target = source. ``` Use `CORRESPONDING` when the desired contract is name-based component mapping: ```abap DATA(target) = CORRESPONDING ty_target( source MAPPING target_id = source_id ). ``` Use the statement form when updating an existing target: ```abap MOVE-CORRESPONDING source TO target. ``` Unmatched target components keep or receive values according to the exact statement/operator variant. Check `BASE`, `MAPPING`, `EXCEPT`, and deep-mapping semantics when preservation matters. --- ## 6. Constructing and Adding Lines ### 6.1 Constructor expressions ```abap flights_seq = VALUE #( ( carrier_id = 'LH' connection_id = '0400' city_from = 'FRANKFURT' city_to = 'NEW YORK' price = '800.00' currency = 'EUR' ) ( carrier_id = 'SQ' connection_id = '0012' city_from = 'SINGAPORE' city_to = 'TOKYO' price = '650.00' currency = 'SGD' ) ). ``` ### 6.2 `APPEND` `APPEND` adds at the end of an index table. It is natural for a standard table. ```abap APPEND VALUE #( carrier_id = 'VN' connection_id = '0030' city_from = 'HO CHI MINH CITY' city_to = 'TOKYO' ) TO flights_seq. ``` Although `APPEND` is possible for sorted index tables, the new line must fit after the existing last line and obey key uniqueness. Otherwise the operation fails at runtime. Prefer semantic insertion for sorted tables. ### 6.3 `INSERT ... INTO TABLE` This key-based form works with all table categories and lets the table choose the physical position. ```abap INSERT VALUE #( carrier_id = 'LH' connection_id = '0400' ) INTO TABLE flights_sorted. IF sy-subrc = 4. " Duplicate unique key; no line inserted ENDIF. ``` For a standard table, use `INSERT ... INDEX index` only when position has business meaning. --- ## 7. Reading One Line Safely ### 7.1 `READ TABLE ... INTO`: copy the row ```abap READ TABLE flights_sorted WITH TABLE KEY primary_key COMPONENTS carrier_id = 'LH' connection_id = '0400' INTO DATA(flight). IF sy-subrc = 0. " flight is a copy ENDIF. ``` Modifying `flight` does not modify the table until it is written back. ### 7.2 `READ TABLE ... ASSIGNING`: alias the row ```abap READ TABLE flights_sorted WITH TABLE KEY primary_key COMPONENTS carrier_id = 'LH' connection_id = '0400' ASSIGNING FIELD-SYMBOL(<flight>). IF sy-subrc = 0. <flight>-price = '825.00'. " Changes the table line directly ENDIF. ``` A field symbol is an alias to an assigned data object, not a separately copied row. It must be assigned before dereferencing. ### 7.3 `REFERENCE INTO`: retain a data reference ```abap READ TABLE flights_sorted WITH TABLE KEY primary_key COMPONENTS carrier_id = 'LH' connection_id = '0400' REFERENCE INTO DATA(flight_ref). IF sy-subrc = 0. flight_ref->price = '825.00'. ENDIF. ``` ### 7.4 Table expressions ```abap TRY. DATA(lh_price) = flights_sorted[ carrier_id = 'LH' connection_id = '0400' ]-price. CATCH cx_sy_itab_line_not_found. " Handle the missing row ENDTRY. ``` A failed table expression normally raises `CX_SY_ITAB_LINE_NOT_FOUND`; it does not simply set `sy-subrc` like `READ TABLE`. For existence only: ```abap IF line_exists( flights_sorted[ carrier_id = 'LH' connection_id = '0400' ] ). " Do not perform a second lookup unless the row content is also needed ENDIF. ``` Use one `READ TABLE`, assignment, or reference when the next step needs the line; `line_exists` followed by a second read repeats the lookup. ### 7.5 System fields For common `READ TABLE` forms, `sy-subrc = 0` means a line was found and `sy-subrc = 4` commonly means no matching line was found. For index tables, `sy-tabix` can identify the affected or current primary/secondary index, but its meaning depends on the statement and key used. Hashed primary-key access has no primary table index. Table expressions do not generally set `sy-subrc` and do not generally update `sy-tabix`; use their expression/exception semantics instead. Never rely on a system field without tying it to the immediately preceding statement. --- ## 8. Iteration: Copy, Alias, or Reference | Form | Row handling | Use when | | ------------------------- | ------------------------------------------- | ------------------------------------------ | | `LOOP ... INTO` | Copies each row | Readability or independent copy is desired | | `LOOP ... ASSIGNING` | Assigns a field symbol to the current row | Direct mutation or avoiding row copies | | `LOOP ... REFERENCE INTO` | Returns a data reference to the current row | A reference must be passed or retained | ```abap LOOP AT flights_seq INTO DATA(flight_copy) WHERE city_from = 'FRANKFURT'. " Changes to flight_copy do not automatically change flights_seq ENDLOOP. LOOP AT flights_seq ASSIGNING FIELD-SYMBOL(<flight_row>) WHERE city_from = 'FRANKFURT'. <flight_row>-price += 25. " Direct table-line modification ENDLOOP. ``` `ASSIGNING` can avoid copying wide or deep rows, but do not claim it is always faster in a meaningful way. Choose it first for semantics—direct mutation—and measure performance where it matters. The primary-key components of sorted and hashed tables are protected from changes that would invalidate their administration. Delete and reinsert a line when its primary identity must change. --- ## 9. Modifying Lines ### 9.1 Modify by table key ```abap DATA changed_flight TYPE ty_flight. changed_flight-carrier_id = 'LH'. changed_flight-connection_id = '0400'. changed_flight-price = '850.00'. MODIFY TABLE flights_sorted FROM changed_flight. IF sy-subrc <> 0. " No row matched the primary key ENDIF. ``` ### 9.2 Modify selected components ```abap MODIFY flights_seq FROM VALUE #( price = '700.00' currency = 'EUR' ) TRANSPORTING price currency WHERE carrier_id = 'LH'. ``` ### 9.3 Modify by field symbol ```abap LOOP AT flights_seq ASSIGNING FIELD-SYMBOL(<flight>) WHERE carrier_id = 'LH'. <flight>-price *= '0.95'. ENDLOOP. ``` No `MODIFY` is needed in the last example because `<flight>` aliases the table line. By contrast, a changed work-area copy from `LOOP ... INTO` must be written back explicitly, normally with a clear key or index. --- ## 10. Deleting and Clearing ```abap DELETE flights_seq INDEX 1. DELETE flights_sorted USING KEY primary_key WHERE carrier_id = 'LH'. DELETE TABLE flights_hashed WITH TABLE KEY primary_key COMPONENTS carrier_id = 'LH' connection_id = '0400'. ``` ### 10.1 Remove duplicates `DELETE ADJACENT DUPLICATES` removes only neighboring duplicates according to the comparison. For a standard table, sort into the required adjacency first. ```abap SORT flights_seq BY city_from city_to. DELETE ADJACENT DUPLICATES FROM flights_seq COMPARING city_from city_to. ``` The sort fields and comparison fields must express the same intended identity. ### 10.2 `CLEAR` versus `FREE` ```abap CLEAR flights_seq. " Remove rows; retain initial allocation for reuse FREE flights_seq. " Remove rows and release the initial table allocation ``` Use `CLEAR` when the table will probably be filled again soon. Use `FREE` when releasing a large table's allocation is useful. The ABAP runtime still owns the details of dynamic memory management; do not assume an operating-system memory change at that exact statement. --- ## 11. Sorting and Binary Search ```abap SORT flights_seq BY carrier_id connection_id. READ TABLE flights_seq WITH KEY carrier_id = 'LH' connection_id = '0400' BINARY SEARCH INTO DATA(flight). ``` For `BINARY SEARCH` to be correct, the standard table must already be sorted in ascending order with a compatible leading field sequence. If later code changes the order, the search contract silently becomes fragile. Prefer a sorted table or named sorted secondary key when repeated optimized key access is part of the data model. Use one-off `SORT` plus `BINARY SEARCH` only when the local lifecycle makes the ordering invariant obvious. --- ## 12. Aggregation with `COLLECT` `COLLECT` finds a line using the internal table's **primary key**. If found, it adds the source's numeric non-key components to the existing line. If not found, it inserts the line. ```abap TYPES: BEGIN OF ty_route_total, city_from TYPE c LENGTH 40, city_to TYPE c LENGTH 40, revenue TYPE decfloat34, END OF ty_route_total. TYPES ty_route_totals TYPE HASHED TABLE OF ty_route_total WITH UNIQUE KEY primary_key COMPONENTS city_from city_to. DATA route_totals TYPE ty_route_totals. LOOP AT flights_seq INTO DATA(flight). COLLECT VALUE ty_route_total( city_from = flight-city_from city_to = flight-city_to revenue = flight-price ) INTO route_totals. ENDLOOP. ``` All components outside the primary key must be numeric for this aggregation form. An explicit sorted or hashed key makes the aggregation identity and lookup behavior clearer than relying on a standard table's implicit standard key. Do not confuse ABAP `COLLECT` with database aggregation. When a large dataset can be aggregated correctly by the database, prefer `SELECT ... GROUP BY` so fewer rows cross into application-server memory. --- ## 13. Modern Group Processing Prefer `LOOP AT ... GROUP BY` over legacy control-break processing when writing new code. Grouping is explicit and does not depend on physical component order or temporary masking of work-area fields. ```abap LOOP AT flights_seq INTO DATA(flight) GROUP BY ( carrier_id = flight-carrier_id members = GROUP SIZE ) ASSIGNING FIELD-SYMBOL(<carrier_group>). DATA(total_price) = REDUCE decfloat34( INIT total = CONV decfloat34( 0 ) FOR member IN GROUP <carrier_group> NEXT total += member-price ). " <carrier_group>-carrier_id, <carrier_group>-members, total_price ENDLOOP. ``` Grouping happens in two phases: ABAP assigns rows to group keys, then iterates over the groups. Member iteration uses `LOOP AT GROUP` or `FOR ... IN GROUP`. ### 13.1 Modern table transformations Constructor and iteration expressions can make pure transformations concise: ```abap DATA(lh_flights) = VALUE ty_flights_seq( FOR flight IN flights_seq WHERE ( carrier_id = 'LH' ) ( flight ) ). ``` Use expression syntax when it makes the transformation clearer. A conventional loop is still appropriate when error handling, tracing, or several side effects would make one expression difficult to understand. --- ## 14. Legacy Constructs You Must Recognize ### 14.1 Header lines ```abap " Obsolete — recognize it; do not introduce it DATA old_flights TYPE STANDARD TABLE OF ty_flight WITH HEADER LINE. ``` This declaration creates both: ```text old_flights implicit single-line header area old_flights[] internal table body ``` That name collision makes statements ambiguous: ```abap CLEAR old_flights. " Historically addresses the header line CLEAR old_flights[]. " Addresses the table body ``` Header-line declarations are obsolete and are not allowed in classes. Modern code uses an explicit table plus an explicit work area, inline declaration, or field symbol. ### 14.2 `AT NEW`, `AT END OF`, and `SUM` Legacy control-break events include: - `AT FIRST` - `AT NEW component` - `AT END OF component` - `AT LAST` They depend on the processing order and on the component order of the row structure. During classic control-break blocks, character-like components to the right of the break component can be represented by asterisks and other components can receive initial values temporarily. This behavior is one reason the code is difficult to maintain. When reading old code: 1. inspect the row-type component order; 2. inspect the table's actual processing order; 3. identify the exact break component; 4. check which values are valid inside the event block; 5. inspect any `SUM` behavior carefully. For new code, prefer explicit `GROUP BY` and `REDUCE`. --- ## 15. Database and RAP Boundaries ### 15.1 Avoid `SELECT` inside a loop ```abap " Avoid repeated database round trips LOOP AT requests INTO DATA(request). SELECT SINGLE ... WHERE request_uuid = @request-request_uuid ... ENDLOOP. ``` Prefer set-oriented retrieval using a join, association, subquery, range, or a carefully guarded `FOR ALL ENTRIES`, depending on the problem and release. When using `FOR ALL ENTRIES`: - guard against an initial driver table; - select only necessary columns; - understand duplicate elimination and key semantics; - measure against a join or other set-oriented alternative. ### 15.2 Internal table versus RAP transactional buffer RAP method parameters and EML results are represented using generated internal table types, but the RAP transactional buffer is a framework-managed business object state. It is not identical to one local variable such as `DATA(items)`. ```text Local internal table variable → ordinary ABAP runtime data RAP transactional buffer → framework-managed pending BO changes, addressed through EML ``` Changing a local EML result table does not change the business object. Use `MODIFY ENTITIES` when the BO state must change. --- ## 16. Performance Rules That Survive Interviews 1. **Choose the table category from access patterns.** Do not choose hashed only because the dataset is “large.” 2. **Use the key explicitly.** Optimized lookup depends on the key and search components actually used. 3. **Keep processing set-oriented.** Avoid repeated database access inside internal-table loops. 4. **Avoid unnecessary row copies.** Use `ASSIGNING` or `REFERENCE INTO` when direct access is the intended semantic, especially for wide/deep rows. 5. **Do not over-index.** Secondary keys consume memory and add mutation cost. 6. **Do not sort repeatedly.** If sorted access is a stable requirement, model it with a sorted table or secondary key. 7. **Push suitable filtering and aggregation to the database.** Internal tables are not a replacement for SQL execution on large persisted datasets. 8. **Measure material paths.** Runtime depends on row count, width, mutation frequency, selectivity, and release—not only theoretical complexity. --- ## 17. Common Failure Modes | Symptom | Likely cause | Correction | | ----------------------------------- | ----------------------------------------------------------- | ------------------------------------------------ | | Lookup is still slow | Search does not use a suitable primary/secondary key | Name the key and align the search components | | `BINARY SEARCH` misses a row | Standard table is not sorted compatibly | Sort correctly or model a sorted key | | Duplicate insert fails | Unique sorted/hashed key already exists | Handle `sy-subrc` or choose non-unique semantics | | Table expression dumps | Row is absent and exception/default was not handled | Use `TRY`, `OPTIONAL`, or `READ TABLE` | | Work-area change is lost | `LOOP ... INTO` created a copy | Write it back or use `ASSIGNING` intentionally | | Sorted/hashed key cannot be changed | Direct mutation would invalidate primary-key administration | Delete and reinsert with the new identity | | Duplicate deletion misses rows | Equal comparison values are not adjacent | Sort by the comparison identity first | | `COLLECT` groups unexpectedly | Primary table key does not match aggregation identity | Define an explicit unique key | | RAP BO did not change | Only a local result internal table was modified | Use EML `MODIFY ENTITIES` | --- ## 18. Compact Decision and Syntax Sheet ```text Declare a sequence STANDARD TABLE ... WITH EMPTY KEY Repeated ordered/range access SORTED TABLE ... WITH [NON-]UNIQUE KEY ... Exact unique lookup HASHED TABLE ... WITH UNIQUE KEY ... Read a copy READ TABLE ... INTO ... Read and mutate the row READ TABLE ... ASSIGNING ... Read with a durable reference READ TABLE ... REFERENCE INTO ... Expression lookup itab[ key = value ] Existence only line_exists( itab[ key = value ] ) Insert by table semantics INSERT line INTO TABLE itab Aggregate by explicit primary key COLLECT line INTO itab Group modern ABAP data LOOP AT itab ... GROUP BY ... ``` ### Useful whole-table operations ```abap " Value-copy one compatible table target_flights = source_flights. " Append all source lines APPEND LINES OF source_flights TO target_flights. " Current number of lines DATA(line_count) = lines( target_flights ). " Older statement form still encountered DESCRIBE TABLE target_flights LINES DATA(described_count). ``` 2c:T774,1. Mental Model: Type, Structure, Work Area, and Internal Table Do not treat these as four equivalent objects. text TYPES declaration defines a type; it does not hold runtime values │ ├── DATA structure one structured data object │ └── may serve as a work area │ └── DATA internal table zero or more lines of one line type 1.1 Structured type A structured type defines named components and their types. TYPES creates a type, not a runtime data object. abap TYPES: BEGIN OF tyflight, carrierid TYPE c LENGTH 3, connectionid TYPE n LENGTH 4, cityfrom TYPE c LENGTH 40, cityto TYPE c LENGTH 40, price TYPE p LENGTH 8 DECIMALS 2, currency TYPE c LENGTH 3, END OF tyflight. The type can be local, defined globally in a class/interface, or supplied by a released Dictionary/CDS artifact. SE11 is a classic Dictionary maintenance tool, not the definition of the ABAP concept itself. 1.2 Structure data object DATA instantiates a data object and therefore allocates runtime state. abap DATA flight TYPE tyflight. The word structure can mean either a structured type or a structured data object, depending on context. Say which one you mean in technical explanations. 1.3 Work area A work area is a role played by a single data object when a table statement copies one line into it or reads a line from it. It is not a separate ABAP type category. abap DATA flight TYPE tyflight. LOOP AT flights INTO flight. " flight is the work area for this loop ENDLOOP. 1.4 Internal table An internal table is an in-memory ABAP data object containing zero or more lines. Its type is defined by: 1. line type; 2. table category; 3. primary table key; 4. optional secondary table keys. It is not a database table and is not persisted by COMMIT WORK. Its lifetime follows the lifetime and scope of its owning ABAP data object. abap TYPES tyflights TYPE STANDARD TABLE OF tyflight WITH EMPTY KEY. DATA flights2d:T80f,## 1. Mental Model: Type, Structure, Work Area, and Internal Table Do not treat these as four equivalent objects. ```text TYPES declaration defines a type; it does not hold runtime values │ ├── DATA structure one structured data object │ └── may serve as a work area │ └── DATA internal table zero or more lines of one line type ``` ### 1.1 Structured type A structured type defines named components and their types. `TYPES` creates a type, not a runtime data object. ```abap TYPES: BEGIN OF ty_flight, carrier_id TYPE c LENGTH 3, connection_id TYPE n LENGTH 4, city_from TYPE c LENGTH 40, city_to TYPE c LENGTH 40, price TYPE p LENGTH 8 DECIMALS 2, currency TYPE c LENGTH 3, END OF ty_flight. ``` The type can be local, defined globally in a class/interface, or supplied by a released Dictionary/CDS artifact. `SE11` is a classic Dictionary maintenance tool, not the definition of the ABAP concept itself. ### 1.2 Structure data object `DATA` instantiates a data object and therefore allocates runtime state. ```abap DATA flight TYPE ty_flight. ``` The word **structure** can mean either a structured type or a structured data object, depending on context. Say which one you mean in technical explanations. ### 1.3 Work area A **work area** is a role played by a single data object when a table statement copies one line into it or reads a line from it. It is not a separate ABAP type category. ```abap DATA flight TYPE ty_flight. LOOP AT flights INTO flight. " flight is the work area for this loop ENDLOOP. ``` ### 1.4 Internal table An internal table is an in-memory ABAP data object containing zero or more lines. Its type is defined by: 1. line type; 2. table category; 3. primary table key; 4. optional secondary table keys. It is not a database table and is not persisted by `COMMIT WORK`. Its lifetime follows the lifetime and scope of its owning ABAP data object.2e:T809d, ## 1. The Four Levels of Modularization The word **module** is ambiguous. First identify what is being separated. ```text Repository / deployment organization Package and software component │ Architectural contract Class, interface, released API │ Callable processing block Method, function module, legacy FORM routine │ Source-text organization INCLUDE ``` | Level | Main question | Examples | | ---------------------- | --------------------------------------------------------------- | ------------------------------------- | | Package boundary | Which objects belong, depend on one another, and move together? | Package, software component | | Architectural boundary | What stable responsibility and contract are exposed? | Interface, global class, released API | | Procedure boundary | What inputs enter, what outputs leave, and what can fail? | Method, function module, `FORM` | | Source organization | In which source unit is this text maintained? | `INCLUDE` program | Splitting 2,000 lines into ten includes improves navigation, but does not by itself reduce shared state, coupling, side effects, or test difficulty. --- ## 2. Modern Decision Guide | Need | Preferred construct | Why | | -------------------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------- | | Business/domain logic in new development | Instance method behind an interface | Encapsulation, substitution, testing, dependency injection | | Stateless utility with no substitutable dependency | Static method, used selectively | Simple call without object state | | One calculated result | Functional method with `RETURNING` | Natural expression-oriented call | | Existing classic reusable API | Existing function module | Preserve the supported contract; wrap when useful | | RFC or update-task infrastructure that requires it | Appropriately configured function module | Function modules provide these classic runtime capabilities | | Organizing a large legacy program | Include program | Source separation only | | Reading old procedural code | `FORM`/`PERFORM` | Compatibility and controlled refactoring | | New RAP business logic | Behavior implementation method plus helper classes | Framework contract plus testable domain logic | Default rule for new code: ```text Interface → class → small cohesive methods ``` Do not introduce a function module or `FORM` merely because code must be reused. --- ## 3. Methods: The Primary Modern Procedure A method belongs to a class or interface. It has a statically known signature, visibility, parameter directions, typing, and exception contract. ### 3.1 Instance method ```abap INTERFACE zif_amount_calculator PUBLIC. METHODS calculate_net_amount IMPORTING quantity TYPE decfloat34 unit_price TYPE decfloat34 RETURNING VALUE(net_amount) TYPE decfloat34. ENDINTERFACE. CLASS zcl_amount_calculator DEFINITION PUBLIC FINAL CREATE PUBLIC. PUBLIC SECTION. INTERFACES zif_amount_calculator. ENDCLASS. CLASS zcl_amount_calculator IMPLEMENTATION. METHOD zif_amount_calculator~calculate_net_amount. net_amount = quantity * unit_price. ENDMETHOD. ENDCLASS. ``` Call: ```abap DATA(calculator) = NEW zcl_amount_calculator( ). DATA(net_amount) = calculator->zif_amount_calculator~calculate_net_amount( quantity = CONV decfloat34( '3' ) unit_price = CONV decfloat34( '12.50' ) ). ``` The interface expresses the consumer contract. The class expresses one implementation. Calling through the interface makes replacement and testing possible. ### 3.2 Static method ```abap CLASS-METHODS normalize_status IMPORTING raw_status TYPE string RETURNING VALUE(status) TYPE string. ``` Call: ```abap DATA(status) = zcl_status_helper=>normalize_status( raw_status ). ``` Static methods are suitable for genuinely stateless operations. Excessive static dependencies behave like globals: they are difficult to substitute and can make isolated tests harder. ### 3.3 Visibility | Visibility | Meaning | | ------------------- | ------------------------------------------- | | `PUBLIC SECTION` | Callable by external consumers | | `PROTECTED SECTION` | Accessible to the class and subclasses | | `PRIVATE SECTION` | Internal implementation detail of the class | Expose the smallest useful public contract. Test public behavior; do not make every helper public merely to call it from a test. ### 3.4 Functional methods A functional method has exactly one `RETURNING` parameter and can appear in an expression. ```abap METHODS calculate_total IMPORTING items TYPE ztt_order_item RETURNING VALUE(total) TYPE decfloat34. DATA(total) = calculator->calculate_total( items ). ``` The return value is completely typed and passed by value. Use `EXPORTING` or `CHANGING` parameters only when the procedure naturally produces several outputs or intentionally updates caller-owned state. --- ## 4. Method Interfaces and Parameter Directions Directions are named from the **callee's** perspective. | Formal parameter in method | Callee meaning | Caller clause | | -------------------------- | -------------------------------------------------- | ------------------------------------------------ | | `IMPORTING` | Method receives input | `EXPORTING` or omitted in functional call syntax | | `EXPORTING` | Method produces output | `IMPORTING` | | `CHANGING` | Method receives and returns the same logical value | `CHANGING` | | `RETURNING` | Functional result | Operand position or `RECEIVING` | Example: ```abap METHODS determine_status IMPORTING current_quantity TYPE i EXPORTING reason TYPE string CHANGING status TYPE string. service->determine_status( EXPORTING current_quantity = quantity IMPORTING reason = DATA(reason) CHANGING status = status ). ``` The caller's keywords are not an arbitrary “inversion.” Both sides describe the same flow from their own perspective. ### 4.1 Optional and default parameters Method input and changing parameters can be optional or have defaults where the language permits. ```abap METHODS format_amount IMPORTING amount TYPE decfloat34 currency TYPE c LENGTH 3 DEFAULT 'EUR' show_currency TYPE abap_bool OPTIONAL RETURNING VALUE(text) TYPE string. ``` Inside a procedure, `IS SUPPLIED` distinguishes an omitted optional parameter from one supplied with its type-initial value. Use optional parameters carefully. Too many independent options often indicate that the method has several responsibilities or needs a parameter object. --- ## 5. Parameter Passing: Reference, Value, and Value-Result Parameter direction and parameter passing are different dimensions. ```text Direction: IMPORTING / EXPORTING / CHANGING / RETURNING Passing: by reference / by value / value-result behavior ``` ### 5.1 Pass by reference The formal parameter refers to the actual parameter. No independent parameter copy is created for the procedure contract. - Changes through an output-capable reference parameter affect the caller. - Aliasing can create side effects when the same object is reachable through several paths. - Input parameters should be treated as inputs according to their contract. ### 5.2 Pass by value `VALUE(parameter)` creates a local formal parameter. Input values are copied in; output-capable values are copied back only when procedure processing completes successfully. For large or deep data, do not assume an immediate physical copy of every byte: the ABAP runtime can optimize copying internally. Choose semantics first and measure important paths. ### 5.3 Value-result For an output-capable `VALUE(...)` parameter, the procedure works on a local value and transfers the result to the caller at successful completion. If an exception ends the procedure before successful completion, that copy-back does not occur. ### 5.4 Prefer intention-revealing interfaces ```text Input only → IMPORTING One new result → RETURNING Several new results → EXPORTING or a result structure Intentional in/out → CHANGING ``` Do not use `CHANGING` as a convenient substitute for designing a result. --- ## 6. Class-Based Exceptions Declare failures that the caller can reasonably handle. ```abap METHODS submit_request IMPORTING request_uuid TYPE sysuuid_x16 RAISING zcx_request_invalid zcx_request_unauthorized. ``` ```abap TRY. service->submit_request( request_uuid ). CATCH zcx_request_invalid INTO DATA(invalid_error). DATA(message) = invalid_error->get_text( ). CATCH zcx_request_unauthorized INTO DATA(auth_error). message = auth_error->get_text( ). ENDTRY. ``` Use class-based exceptions for exceptional failure paths. Do not return a Boolean plus an unrelated global message when the caller needs structured error information. In RAP behavior methods, follow the generated `FAILED` and `REPORTED` contract for business-operation failures instead of replacing it with an arbitrary exception design. --- ## 7. Includes: Source Organization, Not Encapsulation An include program is an ABAP repository source object that cannot be compiled independently. `INCLUDE name.` incorporates its source into the compilation unit of the including program. ```abap REPORT zorder_report. INCLUDE zorder_report_top. " declarations INCLUDE zorder_report_sel. " selection screen INCLUDE zorder_report_cls. " local classes ``` Conceptually: ```text Main source + included source units ↓ activation/compilation One compilation unit ``` ### 7.1 What an include does - Splits a large source into separately maintained source units. - Participates in the including program's compilation and syntax context. - Can organize declarations, procedural blocks, local classes, or event logic. - Cannot execute independently. ### 7.2 What an include does not do - It does not define a callable interface merely by being an include. - It does not create a runtime call or stack frame. - It does not isolate global variables from the including program. - It does not make logic reusable in the architectural sense. - It does not automatically improve unit testability. Declarations in an include have the visibility and scope produced by their position in the combined program. Source order therefore matters. ### 7.3 Parameters An include itself has no parameter interface. A method or legacy `FORM` written inside an include can have parameters because that procedure—not the include— defines the call boundary. ### 7.4 Activation An include must be syntax-checked in a compilation-unit context. When it changes, activate the include and affected owning repository objects as a consistent change set. Do not claim that an include is independently compiled or that every include change always requires a manual activation of every main program; tooling and dependency handling vary by development environment. ### 7.5 Reuse warning SAP recommends assigning an include program to one compilation unit. Reusing the same include across unrelated programs creates hidden dependencies on global declarations, program type, source order, and event context. Extract a class or interface when reuse is the real requirement. --- ## 8. Subroutines: Legacy `FORM` and `PERFORM` SAP classifies subroutines as obsolete. You must recognize and safely maintain them in classic code, but use methods for new designs. ```abap PERFORM calculate_net USING quantity unit_price CHANGING net_amount. FORM calculate_net USING quantity TYPE decfloat34 unit_price TYPE decfloat34 CHANGING net_amount TYPE decfloat34. net_amount = quantity * unit_price. ENDFORM. ``` At `PERFORM`, control enters the `FORM`, executes it, and returns after the call. ### 8.1 Scope - A subroutine is implemented outside classes. - It normally belongs to its program's procedural context. - It can directly access that program's global data, which creates hidden input and output channels. - Data declared inside the `FORM` is local to a call; `STATICS` data persists across calls in the relevant internal session. `PERFORM ... IN PROGRAM` can call a subroutine in another program, but creates a fragile cross-program dependency. Do not use it as a modern public API. ### 8.2 Subroutine parameter passing | Declaration | Passing behavior | Caller effect | | ------------------- | -------------------- | ---------------------------------------------------------------- | | `USING p` | Reference by default | A write can affect caller state, despite the input-oriented name | | `USING VALUE(p)` | Value | Local copy; caller is not changed | | `CHANGING p` | Reference by default | Writes immediately affect caller state | | `CHANGING VALUE(p)` | Value-result | Local value copied back after successful completion | `USING` and `CHANGING` communicate intent; `VALUE(...)` determines value passing. A reference-passed `USING` parameter is not protected from writes by the language in the same way a strong immutable contract would be, so treat it as read-only by convention. ### 8.3 Typing Without explicit typing, a subroutine formal parameter is generically typed as `any`. This defers useful checks and allows failures to appear at runtime. ```abap " Avoid in maintained code FORM process USING input. " Better legacy form FORM process USING input TYPE ty_request. ``` Subroutines do not support modern optional/default parameter interfaces. Static calls should pass the declared parameter sequence exactly. Dynamic subroutine calls weaken static checks further and introduce injection risk if an external value controls the procedure/program name. ### 8.4 Obsolete `TABLES` parameters ```abap " Obsolete — recognize, do not introduce FORM process TABLES rows STRUCTURE zs_row. ``` Use typed `USING` or `CHANGING` parameters while maintaining a `FORM`, and use a class method when refactoring the design. ```abap TYPES ty_requests TYPE STANDARD TABLE OF ty_request WITH EMPTY KEY. FORM process USING requests TYPE ty_requests. " Read-only by convention ENDFORM. ``` --- ## 9. Function Modules A function module is a globally named procedure implemented inside a function group. Classic maintenance uses transaction `SE37`; function groups can be inspected with `SE80` or ADT tooling, depending on the environment. ```text Function group (function pool) ├── global data shared by its function modules ├── generated and developer-managed includes ├── Function Module A └── Function Module B ``` The function module has a public interface. The function group's global data is shared state within the loaded function pool and can make behavior order- dependent if misused. ### 9.1 Call direction Consider an illustrative custom function module whose interface imports an ID and exports a result: ```abap CALL FUNCTION 'Z_READ_REQUEST_STATUS' EXPORTING request_uuid = request_uuid IMPORTING status = status EXCEPTIONS not_found = 1 OTHERS = 2. IF sy-subrc <> 0. " Handle classic exception result ENDIF. ``` | Function-module interface | Caller uses | Flow | | ------------------------- | ------------------------------ | ------------------------ | | `IMPORTING request_uuid` | `EXPORTING request_uuid = ...` | Caller → function module | | `EXPORTING status` | `IMPORTING status = ...` | Function module → caller | | `CHANGING data` | `CHANGING data = ...` | Both directions | This is the same callee/caller perspective used for method calls. ### 9.2 Interface typing and runtime checks Function module names and interfaces are resolved at runtime by `CALL FUNCTION`, even when the name is a literal. Incorrect names, missing parameters, unknown parameters, length conflicts, and type conflicts therefore lead to dynamic-call exceptions or runtime errors such as: - `CALL_FUNCTION_NOT_FOUND` - `CALL_FUNCTION_PARM_MISSING` - `CALL_FUNCTION_PARM_UNKNOWN` - `CALL_FUNCTION_CONFLICT_TYPE` - `CALL_FUNCTION_CONFLICT_LENG` The sample's generic `ILLEGAL_TYPE_PARAM` label is not the useful diagnostic name for ordinary function-module parameter mismatches. Read the actual short dump and identify the formal and actual parameter types. ### 9.3 Optional parameters Unlike `FORM` routines, function module importing and changing parameters can be optional or have default values. Exporting parameters are optional to the caller. The function module can use `parameter IS SUPPLIED` where supported to distinguish omission from an initial value. ### 9.4 Exceptions #### Classic non-class-based exception ```abap CALL FUNCTION 'Z_READ_REQUEST_STATUS' EXPORTING request_uuid = request_uuid IMPORTING status = status EXCEPTIONS not_found = 1 OTHERS = 2. CASE sy-subrc. WHEN 0. " Success WHEN 1. " NOT_FOUND WHEN OTHERS. " Another mapped exception ENDCASE. ``` The numeric values are assigned by the caller. `sy-subrc = 1` has meaning only because this particular call maps `not_found = 1`. #### Class-based exception If the function module declares class-based exceptions, handle them with `TRY ... CATCH` according to its interface. ```abap TRY. CALL FUNCTION 'Z_READ_REQUEST_STATUS_NEW' EXPORTING request_uuid = request_uuid IMPORTING status = status. CATCH zcx_request_not_found INTO DATA(error). DATA(message) = error->get_text( ). ENDTRY. ``` SAP considers non-class-based exceptions a compatibility mechanism. Do not define them for new general-purpose APIs when a class-based contract is available and supported by the invocation type. ### 9.5 Obsolete `TABLES` interface parameters The `TABLES` parameter style is legacy and reference-based. New interfaces use typed importing, exporting, changing, or returning parameters. Be especially careful with RFC restrictions: remote-enabled interfaces have serialization and type constraints beyond local calls. --- ## 10. Specialized Function-Module Runtime Modes Function modules remain important where the platform explicitly requires their runtime capabilities. ### 10.1 Remote-enabled function module (RFC) ```abap CALL FUNCTION 'Z_REMOTE_OPERATION' DESTINATION destination EXPORTING input = input IMPORTING output = output EXCEPTIONS system_failure = 1 MESSAGE system_message communication_failure = 2 MESSAGE communication_message OTHERS = 3. ``` RFC introduces a serialization and communication boundary. Never pass an untrusted external string directly as a dynamic function or destination name. Validate allowlisted values and use supported communication configuration. ### 10.2 Update function module ```abap CALL FUNCTION 'Z_WRITE_AUDIT' IN UPDATE TASK EXPORTING audit_entry = audit_entry. ``` An update function module registers work for update processing associated with the SAP LUW. It has strict interface and execution rules. Do not replace an ordinary method call with `IN UPDATE TASK` merely to make it asynchronous. ### 10.3 Background/asynchronous mechanisms Classic asynchronous RFC, background tasks, bgRFC, qRFC, application jobs, and events solve different reliability and sequencing problems. “Function module” alone does not imply remote, asynchronous, or transactional behavior; the call variant and module attributes matter. --- ## 11. Other Legacy Processing Blocks ### 11.1 Macros ```abap DEFINE set_status. &1-status = &2. END-OF-DEFINITION. ``` Macros are source-level substitution constructs with positional placeholders, not typed procedures. They can obscure control flow and tooling. Recognize them in old code; prefer methods for new logic. ### 11.2 Dialog modules ```abap MODULE validate_screen_input INPUT. " Classic dynpro PAI logic ENDMODULE. ``` `MODULE ... ENDMODULE` processing blocks are called by classic screen flow logic (`PBO`/`PAI`). They are relevant to dynpro maintenance, not a preferred general-purpose reuse mechanism. ### 11.3 Event blocks Blocks such as `START-OF-SELECTION` define framework-driven program events. They are entry points, not reusable APIs. Keep them thin and delegate coherent logic to methods. --- ## 12. Scope and State | Location | Typical lifetime/visibility | Main risk | | -------------------------- | -------------------------------- | ------------------------------------------- | | Method local `DATA` | One invocation | Low; explicit local state | | Instance attribute | Object lifetime | Hidden mutation if responsibility is broad | | Static/class attribute | Internal-session/class lifetime | Global-style coupling and test interference | | Program global data | Program/internal-session context | Hidden inputs and outputs across procedures | | Function-group global data | Loaded function-pool context | Calls depend on prior calls/state | | `STATICS` local data | Retained across procedure calls | Surprising state and test-order dependence | The phrase “local data is freed immediately on exit” is an oversimplification. Local names leave scope at procedure exit, but referenced objects, shared data, runtime optimizations, and garbage collection determine physical memory lifetime. Prefer explicit parameters and returned results over procedure access to global state. --- ## 13. Refactoring a `FORM` into a Class ### 13.1 Legacy form ```abap DATA orders TYPE ztt_order. DATA total TYPE decfloat34. FORM calculate_total. LOOP AT orders INTO DATA(order). total += order-net_amount. ENDLOOP. ENDFORM. ``` Hidden contract: ```text Input: global orders Output: global total Failure: undocumented ``` ### 13.2 First safe step: expose the contract ```abap FORM calculate_total USING orders TYPE ztt_order CHANGING total TYPE decfloat34. CLEAR total. LOOP AT orders INTO DATA(order). total += order-net_amount. ENDLOOP. ENDFORM. ``` ### 13.3 Modern result: functional method ```abap METHODS calculate_total IMPORTING orders TYPE ztt_order RETURNING VALUE(total) TYPE decfloat34. METHOD calculate_total. total = REDUCE decfloat34( INIT sum = CONV decfloat34( 0 ) FOR order IN orders NEXT sum += order-net_amount ). ENDMETHOD. ``` The improvement is not the shorter syntax. The method has an explicit input, one explicit result, no dependency on program global state, and a contract that can live behind an interface. --- ## 14. Testable Modular Design Merely extracting code into a method does not make it testable. A method that calls the database, system date, authorization, external service, and output UI directly still has many hidden dependencies. ```text Application service ├── zif_order_repository ├── zif_authorization ├── zif_clock └── pure amount/status policy ``` Inject dependencies through a constructor or factory-visible seam: ```abap METHODS constructor IMPORTING repository TYPE REF TO zif_order_repository authorization TYPE REF TO zif_order_authorization. ``` Then ABAP Unit tests can supply doubles implementing those interfaces. ### Design properties - **High cohesion:** one module owns one closely related responsibility. - **Low coupling:** consumers depend on small contracts, not implementation globals. - **Explicit dependencies:** database, time, authorization, and external calls are visible. - **Explicit effects:** mutation and persistence are not hidden in a “helper.” - **Stable abstraction:** names express business intent, not implementation steps such as `do_processing_2`. --- ## 15. Transaction Ownership A reusable procedure should not issue `COMMIT WORK` or `ROLLBACK WORK` unless its documented contract truly owns the complete SAP LUW. Otherwise it can prematurely commit changes made by its caller. ```text Caller/application boundary starts orchestration ├── validate ├── calculate ├── persist/register changes └── decide transaction completion ``` This is especially important when wrapping legacy function modules: inspect whether the called API performs commits, registers update tasks, sends messages, or mutates function-group global state. --- ## 16. Modularization in RAP ### 16.1 Framework entry points A RAP behavior pool is an ABAP class pool. The framework calls generated handler/saver method signatures based on the behavior definition. ```text Behavior definition declares operation/action/validation/determination ↓ RAP runtime invokes generated behavior-handler method ↓ Behavior method orchestrates EML and domain helpers ``` Do not rename generated method parameters or invent an unrelated callable name; the framework contract determines the signature. ### 16.2 Keep behavior methods thin enough ```abap METHOD validate_customer. " 1. Read required BO state with EML " 2. Delegate pure/customer-existence decision where useful " 3. Fill FAILED and REPORTED according to RAP contract ENDMETHOD. ``` Good extraction candidates include: - deterministic calculations; - state-transition policies; - message construction; - adapters around released external APIs; - repository/query logic with a test seam. Keep `%tky`, `%cid`, `%is_draft`, `FAILED`, `MAPPED`, and `REPORTED` handling at the RAP boundary unless a dedicated helper abstraction genuinely improves it. ### 16.3 Transaction rule Do not execute `COMMIT WORK` inside RAP behavior implementation. RAP owns the save sequence and transaction boundary. A legacy function module that commits internally is therefore dangerous to call from a RAP interaction/save flow. ### 16.4 Local mode is not modularization `IN LOCAL MODE` changes EML authorization/feature-control handling inside the current BO implementation context. It does not make the called logic a separate module and does not bypass validations or the transactional buffer. --- ## 17. ABAP Cloud and Clean-Core Boundary ABAP Cloud uses a restricted language version and released APIs to provide lifecycle-stable development. For new cloud-ready code: - use classes, interfaces, and methods; - use ADT as the development environment; - depend only on objects released for the required contract; - check API State, not merely whether an object exists; - avoid obsolete syntax such as `FORM`/`PERFORM`; - do not call an unreleased classic function module directly from clean-core code; - wrap permitted classic dependencies only within an intentional migration tier in applicable private/on-premise scenarios. A function module is not automatically forbidden because it is old, and a class is not automatically clean-core because it is object-oriented. The decisive questions are release state, allowed language version, and stability contract. --- ## 18. Naming Guidance Prefixes such as `iv_`, `ev_`, `cv_`, `lt_`, and `gt_` are team conventions, not ABAP language requirements. Use names that expose intent: ```abap METHODS calculate_total IMPORTING items TYPE ztt_order_item RETURNING VALUE(total) TYPE decfloat34. ``` This is usually clearer than encoding every implementation detail: ```abap METHODS calc IMPORTING it_data TYPE ztt_order_item RETURNING VALUE(rv_val) TYPE decfloat34. ``` Follow the project's agreed style consistently, but do not mistake prefixes for encapsulation or type safety. --- ## 19. Common Failure Modes | Symptom | Likely cause | Diagnostic direction | | ----------------------------------------- | ------------------------------------------------------------------- | -------------------------------------------------------------- | | Changing an include breaks several places | Shared source depends on different globals/contexts | Use where-used list; establish each compilation-unit contract | | `PERFORM` call dumps or behaves strangely | Parameter sequence/type mismatch or hidden globals | Compare caller/callee order and explicit types | | Function module call dumps | Missing, unknown, length-conflicting, or type-conflicting parameter | Read ST22 dump and compare SE37 interface with actual values | | `sy-subrc` handling is wrong | Caller mapped classic exceptions differently or checked too late | Read the exact `EXCEPTIONS` mapping immediately after the call | | Unit test depends on execution order | Static, global, `STATICS`, or function-group state | Reset/extract state; inject dependency | | Helper unexpectedly commits data | Procedure owns hidden transaction control | Inspect `COMMIT WORK`, update-task, RFC, and called APIs | | RAP transaction becomes inconsistent | Legacy call commits or bypasses BO contract | Keep transaction under RAP and use released/compatible APIs | | “Reusable” method cannot be reused | It reads globals, UI state, or database implicitly | Make inputs, outputs, effects, and dependencies explicit | | Static utility is impossible to fake | Consumer depends directly on static implementation | Introduce a small interface and instance collaborator | --- ## 20. Technical Review Workflow When reviewing a modularization problem: 1. **Identify the construct:** include, method, function module, `FORM`, macro, screen module, or event block. 2. **Identify the owner:** program, class, interface, function group, package, or framework. 3. **Write the real contract:** inputs, outputs, exceptions/messages, database effects, global state, commits, and external calls. 4. **Check call resolution:** static method, dynamic method, local/external `PERFORM`, local FM, RFC, update task, or framework callback. 5. **Check typing and parameter passing:** direction, reference/value, optional parameters, table types, and aliasing. 6. **Check lifecycle:** local invocation, object state, class/global state, function-group state, or internal session. 7. **Check test seam:** can dependencies be substituted without a real database, clock, authorization, or remote system? 8. **Check transaction ownership:** who is allowed to save, commit, or roll back? 9. **Check release contract:** is the dependency permitted in the target ABAP language version and API contract? 10. **Refactor by risk:** first expose hidden parameters and effects, then move behavior behind a method/interface. --- ## 21. Compact Syntax Sheet ```text Instance method object->method( ... ) Static method class=>method( ... ) Functional result DATA(result) = object->method( input ) Class-based failure TRY ... CATCH cx_... ENDTRY Include source INCLUDE source_name. Legacy subroutine PERFORM routine USING ... CHANGING ... FORM routine USING ... CHANGING ... ENDFORM. Function module CALL FUNCTION 'NAME' EXPORTING ... IMPORTING ... CHANGING ... EXCEPTIONS ... Remote function call CALL FUNCTION 'NAME' DESTINATION destination ... Update registration CALL FUNCTION 'NAME' IN UPDATE TASK ... ``` 2f:T93e,1. The Four Levels of Modularization The word module is ambiguous. First identify what is being separated. text Repository / deployment organization Package and software component │ Architectural contract Class, interface, released API │ Callable processing block Method, function module, legacy FORM routine │ Source-text organization INCLUDE | Level | Main question | Examples | | ---------------------- | --------------------------------------------------------------- | ------------------------------------- | | Package boundary | Which objects belong, depend on one another, and move together? | Package, software component | | Architectural boundary | What stable responsibility and contract are exposed? | Interface, global class, released API | | Procedure boundary | What inputs enter, what outputs leave, and what can fail? | Method, function module, FORM | | Source organization | In which source unit is this text maintained? | INCLUDE program | Splitting 2,000 lines into ten includes improves navigation, but does not by itself reduce shared state, coupling, side effects, or test difficulty. --- 2. Modern Decision Guide | Need | Preferred construct | Why | | -------------------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------- | | Business/domain logic in new development | Instance method behind an interface | Encapsulation, substitution, testing, dependency injection | | Stateless utility with no substitutable dependency | Static method, used selectively | Simple call without object state | | One calculated result | Functional method with RETURNING | Natural expression-oriented call | | Existing classic reusable API | Existing function module | Preserve the supported contract; wrap when useful | | RFC or update-task infrastructure that requires it | Appropriately configured function module | Function modules provide these classic runtime capabilities | | Organizing a large legacy program | Include program | Source separation only | | Reading old procedural code | FORM/PERFORM | Compatibility and controlled refactoring | | New RAP business logic | Behavior implementation method plus helper classes | Framework contract plus testable domain logic | Default rule for new code: text Interface → class → small cohesive methods Do30:Tc2b,## 1. The Four Levels of Modularization The word **module** is ambiguous. First identify what is being separated. ```text Repository / deployment organization Package and software component │ Architectural contract Class, interface, released API │ Callable processing block Method, function module, legacy FORM routine │ Source-text organization INCLUDE ``` | Level | Main question | Examples | | ---------------------- | --------------------------------------------------------------- | ------------------------------------- | | Package boundary | Which objects belong, depend on one another, and move together? | Package, software component | | Architectural boundary | What stable responsibility and contract are exposed? | Interface, global class, released API | | Procedure boundary | What inputs enter, what outputs leave, and what can fail? | Method, function module, `FORM` | | Source organization | In which source unit is this text maintained? | `INCLUDE` program | Splitting 2,000 lines into ten includes improves navigation, but does not by itself reduce shared state, coupling, side effects, or test difficulty. --- ## 2. Modern Decision Guide | Need | Preferred construct | Why | | -------------------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------- | | Business/domain logic in new development | Instance method behind an interface | Encapsulation, substitution, testing, dependency injection | | Stateless utility with no substitutable dependency | Static method, used selectively | Simple call without object state | | One calculated result | Functional method with `RETURNING` | Natural expression-oriented call | | Existing classic reusable API | Existing function module | Preserve the supported contract; wrap when useful | | RFC or update-task infrastructure that requires it | Appropriately configured function module | Function modules provide these classic runtime capabilities | | Organizing a large legacy program | Include program | Source separation only | | Reading old procedural code | `FORM`/`PERFORM` | Compatibility and controlled refactoring | | New RAP business logic | Behavior implementation method plus helper classes | Framework contract plus testable domain logic | Default rule for new code:31:T7fb5, ## 1. The Correct Overall Mental Model A classic executable report is **event-driven**. Source-code position does not mean that ABAP simply executes every line from top to bottom. The ABAP runtime framework raises events and calls the matching event blocks. The selection screen also creates a loop: ```text Program requested │ ▼ Program loaded into internal session, if not already loaded │ ├─ global/static initialization performed by runtime └─ LOAD-OF-PROGRAM event block, if defined │ ▼ INITIALIZATION │ ▼ AT SELECTION-SCREEN OUTPUT selection-screen PBO │ ▼ Selection screen displayed │ ▼ User action │ ├─ F4 help ───────────────► ON VALUE-REQUEST FOR field │ │ │ └─ redisplay loop │ ├─ F1 help ───────────────► ON HELP-REQUEST FOR field │ │ │ └─ redisplay loop │ ├─ Enter / pushbutton / │ radio USER-COMMAND ────► selection-screen PAI events │ │ │ └─ AT SELECTION-SCREEN OUTPUT │ → redisplay │ └─ Execute F8 ─────────────► selection-screen PAI validation │ ├─ validation error │ └─ OUTPUT → redisplay │ └─ validation succeeds └─ START-OF-SELECTION │ ├─ report application logic ├─ END-OF-SELECTION, if defined └─ output/list processing ``` The straight-line version from the initial draft omitted the redisplay cycle. `AT SELECTION-SCREEN OUTPUT` can run many times; `INITIALIZATION` normally runs once for that report execution before the standard selection screen first appears. --- ## 2. Report Source Layout Versus Runtime Order A maintainable report can be arranged like this: ```abap REPORT zsales_order_report. " Global declarations and selection-screen definition TABLES sscrfields. PARAMETERS: p_open RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND mode, p_all RADIOBUTTON GROUP mode. SELECT-OPTIONS s_order FOR vbak-vbeln. CLASS lcl_application DEFINITION FINAL. PUBLIC SECTION. CLASS-METHODS run. ENDCLASS. CLASS lcl_application IMPLEMENTATION. METHOD run. " Application orchestration ENDMETHOD. ENDCLASS. INITIALIZATION. " One-time selection defaults AT SELECTION-SCREEN OUTPUT. " Dynamic screen attributes before each display AT SELECTION-SCREEN. " Cross-field/action validation START-OF-SELECTION. lcl_application=>run( ). ``` The physical order improves readability, but runtime execution is determined by events. Each event block begins with an event keyword and ends at the next processing block or the end of the program; there is no `END-...` statement. Keep event blocks thin and delegate application logic to methods. This prevents the report framework, selection-screen state, database logic, and output logic from becoming one inseparable procedure. ### 2.1 Declaration-scope trap Most event blocks are not ordinary procedures. Declarations written inside them belong to the compilation unit's global declarations and remain visible in subsequent processing blocks. Selection-screen and logical-database event blocks are special runtime implementations that can allow local declarations, but a consistent design should still put working data inside called methods. ```abap START-OF-SELECTION. DATA result TYPE string. " Do not assume method-local lifecycle semantics lcl_application=>run( ). ``` The safe architectural rule is not “declare globals inside an event.” It is “use the event as a thin framework adapter and work locally inside methods.” --- ## 3. Phase 1 — Program Load ### 3.1 What “load” means When the executable program is first needed in an internal session, its load is made available and its global data context is initialized. Programs already loaded in the same internal session need not be loaded again simply because a procedure is called again. Do not confuse: ```text Repository activation/generation creates or updates executable program load Runtime loading brings the program into an internal session for execution ``` ### 3.2 `LOAD-OF-PROGRAM` Contrary to the draft statement, this is a definable event block: ```abap LOAD-OF-PROGRAM. " Rarely needed in an ordinary report ``` It is the program constructor event and occurs when the program is loaded into an internal session. It is not the normal place for user defaults or report business processing. Typical guidance: - Use declaration-time initialization for simple constants/default state. - Use `INITIALIZATION` for initial selection-screen values. - Use constructors for object initialization. - Avoid database updates, user interaction, commits, or large queries in `LOAD-OF-PROGRAM`. ### 3.3 Why it may run less often than expected `LOAD-OF-PROGRAM` is associated with loading the program, not every selection-screen redisplay. If the program remains loaded in the internal session, repeated calls or interactions do not imply repeated program-load events. --- ## 4. Phase 2 — `INITIALIZATION` `INITIALIZATION` occurs before the standard selection screen is first processed for the report execution. ```abap PARAMETERS p_date TYPE sy-datum. INITIALIZATION. p_date = sy-datum. ``` Good uses: - calculate initial date ranges; - choose a sensible initial radio button; - initialize selection-screen texts or pushbutton labels; - supply lightweight defaults that should occur once. Avoid: - repeatedly controlling whether a field is visible or editable; - expensive report data selection; - changing database state; - authorization enforcement that must also protect background execution or non-screen entry points. ### 4.1 `DEFAULT` versus `INITIALIZATION` ```abap PARAMETERS p_status TYPE c LENGTH 1 DEFAULT 'O'. ``` Use declaration `DEFAULT` for a static initial value. Use `INITIALIZATION` when the starting value requires runtime calculation. ### 4.2 Why not put dynamic screen logic here? `INITIALIZATION` does not run on every redisplay. If screen input readiness depends on the currently selected radio button, use `AT SELECTION-SCREEN OUTPUT`. Also distinguish an initial proposal from the effective runtime selection. Selection variants, SPA/GPA memory values, `SUBMIT` parameters, or previous user input can influence values later in the screen lifecycle. When debugging, inspect the value at `AT SELECTION-SCREEN OUTPUT` and again in PAI instead of assuming the value assigned during `INITIALIZATION` is still effective. --- ## 5. Phase 3 — Selection-Screen PBO `AT SELECTION-SCREEN OUTPUT` is the Process Before Output event of the selection screen. It runs directly before the screen is displayed and can run repeatedly. ```abap PARAMETERS: p_file RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND mode, p_order RADIOBUTTON GROUP mode, p_path TYPE string LOWER CASE MODIF ID fil, p_vbeln TYPE vbak-vbeln MODIF ID ord. AT SELECTION-SCREEN OUTPUT. LOOP AT SCREEN. CASE screen-group1. WHEN 'FIL'. screen-active = xsdbool( p_file = abap_true ). WHEN 'ORD'. screen-active = xsdbool( p_order = abap_true ). ENDCASE. MODIFY SCREEN. ENDLOOP. ``` `MODIF ID fil` is represented in `SCREEN-GROUP1` as uppercase `FIL`. ### 5.1 Common `SCREEN` fields | Field | Purpose | | --------------------------------------- | ----------------------------------------- | | `SCREEN-GROUP1` | Modification group from `MODIF ID` | | `SCREEN-ACTIVE` | Combined active/inactive control | | `SCREEN-INPUT` | Input enabled/disabled | | `SCREEN-INVISIBLE` | Visible/hidden behavior | | `SCREEN-REQUIRED` | Visual/required-state control | | `SCREEN-DISPLAY_3D` or other attributes | Release/UI-specific presentation controls | Always execute `MODIFY SCREEN` for a changed row of the special `SCREEN` table. ### 5.2 Idempotence rule Implement output logic so the correct screen state is recalculated from the current selection values on every PBO. Do not rely on the event running only once or on the previous display state. --- ## 6. Phase 4 — Screen Display and User Action After PBO, the selection screen is sent to the presentation layer. The user can enter values, request help, choose a command, press Enter, or execute. The action determines the next event path. “User does something” is therefore not one event. | User action | Important event path | | ------------------------------------------ | ------------------------------------------------------------- | | Press F4 on a field | `ON VALUE-REQUEST FOR field` | | Press F1 on a field | `ON HELP-REQUEST FOR field` | | Change radio/checkbox with `USER-COMMAND` | Selection-screen PAI; then redisplay | | Press a custom selection-screen pushbutton | Selection-screen PAI; then usually redisplay | | Press Enter | Selection-screen PAI; then redisplay | | Press Execute F8 | Selection-screen PAI; if valid, leave screen and start report | | Press Back/Exit/Cancel | Exit-command handling and screen termination path | --- ## 7. F4 Value Help: `ON VALUE-REQUEST` Use a custom value-request event only when Dictionary/search-help behavior does not already provide the correct F4 help. ```abap AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_path. p_path = lcl_file_dialog=>choose_file( ). ``` Flow: ```text User presses F4 on p_path → AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_path → custom logic proposes/sets a value → selection screen is displayed again ``` This is not the report's business validation event and does not proceed to `START-OF-SELECTION`. ### 7.1 Prefer metadata-driven value help If the parameter refers to a DDIC field with a search help, check table, or fixed domain values, the runtime can often supply value help automatically. Do not replace correct metadata with unnecessary custom F4 code. ### 7.2 Security rule Value help narrows or proposes input; it is not authorization enforcement and does not guarantee that submitted input is valid. Validate the final value and perform authorization checks at the execution boundary. --- ## 8. F1 Help: `ON HELP-REQUEST` ```abap AT SELECTION-SCREEN ON HELP-REQUEST FOR p_path. lcl_help=>show_path_explanation( ). ``` Use this only when standard field/documentation help is insufficient. Like F4, it is a help request, not successful report execution. --- ## 9. Radio Buttons and `USER-COMMAND` Changing a radio button does **not** necessarily cause an immediate server round trip. Associate a function code when the selection should trigger dynamic screen modification: ```abap PARAMETERS: p_file RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND mode, p_order RADIOBUTTON GROUP mode. ``` The command is assigned to the group through the first declared radio button. On selection: ```text Radio selection changes → function code MODE is sent → selection-screen PAI events run → AT SELECTION-SCREEN OUTPUT recalculates field state → screen is redisplayed ``` Access the function code through `SSCRFIELDS-UCOMM` in classic code: ```abap TABLES sscrfields. AT SELECTION-SCREEN. CASE sscrfields-ucomm. WHEN 'MODE'. " Usually no business execution here; allow redisplay ENDCASE. ``` Radio-button user commands are well suited to screen adaptation, not to running the main report. F8 remains the normal transition to report execution. --- ## 10. Phase 5 — Selection-Screen PAI and Validation PAI transfers input from the screen and raises the relevant `AT SELECTION-SCREEN` events. Think of validation as layers from narrow to broad. ```text Field or selection-criterion checks → end-of-multiple-selection checks → radio-button-group checks → block checks → generic AT SELECTION-SCREEN command/cross-field check ``` The exact triggered subset depends on the screen fields and user action. ### 10.1 Validate one parameter ```abap AT SELECTION-SCREEN ON p_vbeln. IF p_order = abap_true AND p_vbeln IS INITIAL. MESSAGE e001(zreport) WITH 'Enter a sales order'. ENDIF. ``` Use for a rule local to that field. A radio-button field is validated with the group event rather than an individual field event. ### 10.2 Validate a radio-button group ```abap AT SELECTION-SCREEN ON RADIOBUTTON GROUP mode. IF p_file = abap_false AND p_order = abap_false. MESSAGE e002(zreport) WITH 'Choose a mode'. ENDIF. ``` ### 10.3 Validate a block ```abap SELECTION-SCREEN BEGIN OF BLOCK criteria WITH FRAME TITLE text-t01. PARAMETERS p_vbeln TYPE vbak-vbeln. SELECT-OPTIONS s_date FOR sy-datum. SELECTION-SCREEN END OF BLOCK criteria. AT SELECTION-SCREEN ON BLOCK criteria. IF p_vbeln IS INITIAL AND s_date[] IS INITIAL. MESSAGE e003(zreport) WITH 'Enter an order or date range'. ENDIF. ``` ### 10.4 Validate a complete `SELECT-OPTIONS` criterion ```abap AT SELECTION-SCREEN ON END OF s_date. LOOP AT s_date ASSIGNING FIELD-SYMBOL(<date_range>). IF <date_range>-option = 'BT' AND <date_range>-low > <date_range>-high. MESSAGE e004(zreport) WITH 'Invalid date interval'. ENDIF. ENDLOOP. ``` The selection criterion is a range-like table containing `SIGN`, `OPTION`, `LOW`, and `HIGH`. Validate the whole selection table when intervals or multiple rows interact. ### 10.5 Generic `AT SELECTION-SCREEN` ```abap AT SELECTION-SCREEN. CASE sscrfields-ucomm. WHEN 'ONLI'. " Common Execute function code; verify in target context lcl_selection_validator=>validate( file_mode = p_file path = p_path order = p_vbeln ). WHEN 'MODE'. " Dynamic mode switch; return to screen ENDCASE. ``` Use the generic event for cross-field validation and command handling. Do not hard-code a function code without confirming the actual selection-screen context. --- ## 11. Validation Failure and Redisplay An error message during selection-screen validation prevents the transition to `START-OF-SELECTION` and returns control to the selection screen. ```text Execute F8 → PAI validation → MESSAGE E → validation stops → AT SELECTION-SCREEN OUTPUT → corrected screen displayed ``` This is why `AT SELECTION-SCREEN OUTPUT` must tolerate repeated execution. `OBLIGATORY` provides basic required-input checking, but it does not replace cross-field business validation, existence checks, or authorization checks. ### 11.1 Message types are context-sensitive `MESSAGE E`, `W`, `I`, `S`, `A`, and `X` do not have one universal control-flow meaning independent of their processing context. In selection-screen PAI, error messages can return the user to input. In other report phases, the same message type can have a different runtime consequence. Diagnose the event and dialog context, not only the letter. --- ## 12. Exit Commands Back, Exit, and Cancel are exit-type commands. Use the specialized event only when cleanup or confirmation is genuinely necessary: ```abap AT SELECTION-SCREEN ON EXIT-COMMAND. " Avoid validation that traps the user on a screen they are leaving ``` This event is designed to handle exit commands before ordinary selection-screen validation prevents leaving because of invalid field content. Do not perform report business processing here. --- ## 13. Phase 6 — `START-OF-SELECTION` After the user chooses Execute and selection-screen processing succeeds, the runtime raises `START-OF-SELECTION`. ```abap START-OF-SELECTION. lcl_application=>run( ). ``` This is the report's standard processing block and should usually be its thin application entry point. Typical application flow: ```text START-OF-SELECTION → create application/service objects → enforce execution authorization → convert selection-screen globals into an input structure → read data set-wise → apply business rules → prepare result model → render output ``` ### 13.1 Implicit `START-OF-SELECTION` Executable statements written before the first explicit processing block are assigned to an implicit `START-OF-SELECTION` block. If no explicit event blocks exist, all functional statements form the implicit standard event. Avoid this confusing layout: ```abap REPORT zbad_layout. DATA value TYPE i. value = 10. " Implicit START-OF-SELECTION START-OF-SELECTION. value += 1. " A separate explicit event block ``` Prefer an explicit event keyword and a thin method call so runtime placement is obvious. --- ## 14. `END-OF-SELECTION` Historically, `END-OF-SELECTION` marks processing after a logical database has finished supplying rows through `GET` events. ```abap END-OF-SELECTION. " Final processing after logical-database selection ``` Without a logical database, it follows standard selection processing but often adds no useful architectural boundary. Do not use it simply because its name sounds like the required end of every report. A modern report can orchestrate its complete flow from a method called at `START-OF-SELECTION`. --- ## 15. Logical-Database Events Older reports can be linked to a logical database and receive node data through events such as: ```abap GET node. " Process one logical-database node instance GET node LATE. " Process after subordinate nodes ``` Conceptual runtime: ```text START-OF-SELECTION → logical database reads nodes → GET parent → GET child → GET parent LATE → END-OF-SELECTION ``` Recognize this in legacy reports. For new data access, prefer explicit Open SQL, CDS entities, and released APIs according to the target development model. --- ## 16. Output and List Events ### 16.1 Simple/classic list `WRITE` produces classic list output. Page/list processing can raise events such as: - `TOP-OF-PAGE` - `END-OF-PAGE` - `AT LINE-SELECTION` - `AT USER-COMMAND` Interactive list events happen after initial report processing, in response to the user acting on the displayed list. They are not part of the selection- screen validation sequence. ### 16.2 ALV/SALV For tabular results, ALV/SALV typically provides sorting, filtering, totals, layout variants, and event callbacks. Keep retrieval and business logic independent from the chosen renderer so they can be tested without a GUI. ```text Selection model → application service → result table → ALV adapter ``` --- ## 17. Complete Worked Flow ```abap REPORT zorder_extract. TABLES sscrfields. PARAMETERS: p_order RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND mode, p_file RADIOBUTTON GROUP mode, p_vbeln TYPE vbak-vbeln MODIF ID ord, p_path TYPE string LOWER CASE MODIF ID fil. INITIALIZATION. p_order = abap_true. AT SELECTION-SCREEN OUTPUT. LOOP AT SCREEN. CASE screen-group1. WHEN 'ORD'. screen-active = xsdbool( p_order = abap_true ). WHEN 'FIL'. screen-active = xsdbool( p_file = abap_true ). ENDCASE. MODIFY SCREEN. ENDLOOP. AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_path. p_path = lcl_file_dialog=>choose_file( ). AT SELECTION-SCREEN. IF sscrfields-ucomm = 'ONLI'. IF p_order = abap_true AND p_vbeln IS INITIAL. MESSAGE e001(zreport) WITH 'Enter a sales order'. ENDIF. IF p_file = abap_true AND p_path IS INITIAL. MESSAGE e002(zreport) WITH 'Choose a file'. ENDIF. ENDIF. START-OF-SELECTION. lcl_application=>run( order_mode = p_order order = p_vbeln file_mode = p_file path = p_path ). ``` ### 17.1 Initial display ```text Program begins → INITIALIZATION selects order mode → OUTPUT activates p_vbeln and deactivates p_path → screen displayed ``` ### 17.2 User selects file mode ```text USER-COMMAND MODE → AT SELECTION-SCREEN handles round trip → OUTPUT deactivates p_vbeln and activates p_path → screen displayed again ``` ### 17.3 User presses F4 on path ```text F4 → ON VALUE-REQUEST FOR p_path → dialog result assigned → screen displayed again ``` ### 17.4 User presses Execute without a path ```text F8 / ONLI → AT SELECTION-SCREEN → MESSAGE E → START-OF-SELECTION does not run → OUTPUT → screen displayed for correction ``` ### 17.5 User presses Execute with valid input ```text F8 / ONLI → AT SELECTION-SCREEN validation succeeds → START-OF-SELECTION → lcl_application=>run( ) → result output ``` --- ## 18. Dialog, Background, and `SUBMIT` Are Different Entry Modes The main diagram describes an interactive SAP GUI execution. Reports can also run through a background job or `SUBMIT`. ### 18.1 Background job A job normally receives saved selection values through a variant and has no interactive user available for F4 help, popups, or correction dialogs. ```abap IF sy-batch = abap_true. " Use background-safe logging/output; never require a frontend file dialog ENDIF. ``` Selection-screen UI convenience is therefore not a reliable business-security boundary. Validate the effective execution input and authorization in a background-safe application layer. ### 18.2 `SUBMIT` ```abap SUBMIT ztarget_report WITH p_vbeln = order AND RETURN. ``` `SUBMIT` starts an executable program and supplies selection values. Additions such as `VIA SELECTION-SCREEN`, `USING SELECTION-SET`, background-job options, and list export change the invocation behavior. Dynamic report names are a security risk when they originate externally. Use an allowlist and proper authorization checks. ### 18.3 Design consequence Do not place core business rules only in F4 handlers, screen PBO, or GUI-only validation. Extract an application service that can receive the same input from dialog, job, test, or another allowed entry point. --- ## 19. Selection Screen Versus Application Validation | Concern | Selection-screen layer | Application/domain layer | | --------------------------- | -------------------------- | ---------------------------------------- | | Enable/disable a field | Yes | No | | Show F4 help | Yes | No | | Basic cross-field usability | Yes | Often repeated as invariant if important | | Authorization to read order | May provide early feedback | Must enforce before protected access | | Business invariant | Helpful early feedback | Must be authoritative | | Database consistency | No | Persistence/transaction boundary | | Background-safe execution | Not guaranteed | Required | This parallels RAP: UI metadata and value help improve interaction, while the backend business object must still enforce invariants and authorization. --- ## 20. Program Structure Recommendation ```text Executable report ├── selection-screen declarations ├── INITIALIZATION initial UI defaults ├── AT SELECTION-SCREEN OUTPUT dynamic UI state ├── AT SELECTION-SCREEN ... early input feedback └── START-OF-SELECTION thin application entry │ ▼ Application class ├── authorization ├── input validation ├── query/repository ├── domain transformation └── output adapter ``` Use includes only for source organization when necessary. They do not replace the method/class boundaries described in the [ABAP Modularization reference](./abap-modularization-technical-reference.md). Use explicit internal-table types and access patterns from the [ABAP Internal Tables reference](./abap-internal-tables-technical-reference.md). --- ## 21. Transaction and Side-Effect Rules - Do not update persistent business data during `INITIALIZATION` or screen PBO. - F4/F1 handlers should provide help, not perform commits. - Separate report/query output from update transactions where possible. - If the report performs updates, document authorization, locking, validation, update API, commit ownership, restart behavior, and audit logging. - Do not call `COMMIT WORK` inside a reusable helper that does not own the whole SAP LUW. - A report that calls a BAPI/function module must inspect whether that API performs commits or expects the caller to commit. - For RAP business objects, use EML and allow RAP to own its transaction model; do not reproduce RAP save behavior in a classic report. --- ## 22. Debugging and Operations Map | Need | Classic tool/transaction | Evidence | | --------------------------- | ------------------------------------------------------- | ------------------------------------------- | | Execute/test report | `SE38` or `SA38` | Selection values, event behavior, output | | Repository navigation | `SE80` or ADT | Program, includes, classes, where-used | | Debug event sequence | ADT/SAP GUI debugger | Breakpoints in each event block; call stack | | Analyze short dump | `ST22` | Runtime error, source position, call stack | | Runtime performance | `SAT` | Call hierarchy and ABAP runtime cost | | SQL trace | `ST05` | SQL statements, executions, rows, duration | | System-wide SQL aggregation | `SQLM` where available | Repeated SQL workload evidence | | Background execution | `SM37` | Job step, variant, spool, status, job log | | Authorization failure | `SU53` immediately after failure; trace when authorized | Failed authorization objects/fields | | Application log | `SLG1` when the report writes application logs | Durable business/technical messages | ### 22.1 Event-flow debugging sequence 1. Set breakpoints in `LOAD-OF-PROGRAM`, `INITIALIZATION`, `AT SELECTION-SCREEN OUTPUT`, the relevant field/value-help event, generic `AT SELECTION-SCREEN`, and `START-OF-SELECTION`. 2. Start a new execution context and record which breakpoints occur. 3. Trigger a radio-button user command and observe the PAI → PBO redisplay loop. 4. Trigger F4 and distinguish its request path. 5. Execute once with invalid input and prove that `START-OF-SELECTION` is not reached. 6. Execute with valid input and inspect the transition to the application method. 7. Repeat in background only after removing GUI-dependent assumptions. --- ## 23. Common Misinterpretations | Misinterpretation | Correction | | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | “ABAP executes a report top to bottom.” | The runtime invokes event blocks according to the report and screen lifecycle. | | “`LOAD-OF-PROGRAM` is implicit and cannot be defined.” | It is a definable program-constructor event, though rarely needed in an ordinary report. | | “`INITIALIZATION` runs before every display.” | It initializes before the first standard-screen processing; PBO can repeat. | | “Changing any radio button immediately triggers an event.” | Immediate round trip requires an associated `USER-COMMAND` or another screen command. | | “F4 executes `AT SELECTION-SCREEN` like F8.” | Custom F4 uses `ON VALUE-REQUEST`; it does not start report execution. | | “`OUTPUT` means report result output.” | `AT SELECTION-SCREEN OUTPUT` is selection-screen PBO before display. | | “Every `AT SELECTION-SCREEN` event always runs.” | The triggered variants depend on fields and the user's action. | | “F8 directly calls `START-OF-SELECTION`.” | Selection-screen PAI and validation must succeed first. | | “`END-OF-SELECTION` is mandatory.” | It is especially meaningful with logical databases and is not required for every report. | | “A required screen field enforces the business rule everywhere.” | Screen checks do not replace application authorization and invariants. | | “Report event blocks are local procedures.” | Most event blocks work with compilation-unit global data; keep them thin. | | “The same interactive flow occurs in background.” | Background processing has no user-driven F4 or correction loop. | --- ## 24. Compact Event Reference | Event | Frequency/trigger | Main responsibility | | -------------------------------- | ------------------------------------------------- | -------------------------------------- | | `LOAD-OF-PROGRAM` | When program is loaded into internal session | Rare program-constructor logic | | `INITIALIZATION` | Before first standard selection-screen processing | Initial selection defaults | | `AT SELECTION-SCREEN OUTPUT` | Before every relevant display | Dynamic screen attributes | | `... ON VALUE-REQUEST FOR field` | User presses F4 | Custom value help | | `... ON HELP-REQUEST FOR field` | User presses F1 | Custom field help | | `... ON field` | Selection-screen PAI for field | Field validation | | `... ON END OF selcrit` | Whole selection criterion available | Multiple/range validation | | `... ON RADIOBUTTON GROUP group` | Radio group processed in PAI | Group validation | | `... ON BLOCK block` | Block processed in PAI | Related-field validation | | `AT SELECTION-SCREEN` | General PAI event | Command and cross-field validation | | `... ON EXIT-COMMAND` | Exit-type command | Safe leave/cleanup behavior | | `START-OF-SELECTION` | Selection processing succeeded | Main application entry | | `GET node` | Logical database provides node | Legacy logical-database row processing | | `END-OF-SELECTION` | Selection/logical DB processing completes | Legacy/final report processing | | List events | User/page activity on classic list | Classic output interaction | --- 32:T9dd,1. The Correct Overall Mental Model A classic executable report is event-driven. Source-code position does not mean that ABAP simply executes every line from top to bottom. The ABAP runtime framework raises events and calls the matching event blocks. The selection screen also creates a loop: text Program requested │ ▼ Program loaded into internal session, if not already loaded │ ├─ global/static initialization performed by runtime └─ LOAD-OF-PROGRAM event block, if defined │ ▼ INITIALIZATION │ ▼ AT SELECTION-SCREEN OUTPUT selection-screen PBO │ ▼ Selection screen displayed │ ▼ User action │ ├─ F4 help ───────────────► ON VALUE-REQUEST FOR field │ │ │ └─ redisplay loop │ ├─ F1 help ───────────────► ON HELP-REQUEST FOR field │ │ │ └─ redisplay loop │ ├─ Enter / pushbutton / │ radio USER-COMMAND ────► selection-screen PAI events │ │ │ └─ AT SELECTION-SCREEN OUTPUT │ → redisplay │ └─ Execute F8 ─────────────► selection-screen PAI validation │ ├─ validation error │ └─ OUTPUT → redisplay │ └─ validation succeeds └─ START-OF-SELECTION │ ├─ report application logic ├─ END-OF-SELECTION, if defined └─ output/list processing The straight-line version from the initial draft omitted the redisplay cycle. AT SELECTION-SCREEN OUTPUT can run many times; INITIALIZATION normally runs once for that report execution before the standard selection screen first appears. --- 2. Report Source Layout Versus Runtime Order A maintainable report can be arranged like this: abap REPORT zsalesorderreport. " Global declarations and selection-screen definition TABLES sscrfields. PARAMETERS: popen RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND mode, pall RADIOBUTTON GROUP mode. SELECT-OPTIONS sorder FOR vbak-vbeln. CLASS lclapplication DEFINITION FINAL. PUBLIC SECTION. CLASS-METHODS run. ENDCLASS. CLASS lclapplication IMPLEMENTATION. METHOD run. " Application orchestration ENDMETHOD. ENDCLASS. INITIALIZATION. " One-time selection defaults AT SELECTION-SCREEN OUTPUT. " Dynamic screen attributes before each display AT SELECTION-SCREEN. " Cross-field/action validation START-OF-SELECTION. lclapplication=run( ). The physical order improves readability, but runtime execution is determined by events. Each event block begins with an event keyword and ends at the next processing block or the end of33:Tc52,## 1. The Correct Overall Mental Model A classic executable report is **event-driven**. Source-code position does not mean that ABAP simply executes every line from top to bottom. The ABAP runtime framework raises events and calls the matching event blocks. The selection screen also creates a loop: ```text Program requested │ ▼ Program loaded into internal session, if not already loaded │ ├─ global/static initialization performed by runtime └─ LOAD-OF-PROGRAM event block, if defined │ ▼ INITIALIZATION │ ▼ AT SELECTION-SCREEN OUTPUT selection-screen PBO │ ▼ Selection screen displayed │ ▼ User action │ ├─ F4 help ───────────────► ON VALUE-REQUEST FOR field │ │ │ └─ redisplay loop │ ├─ F1 help ───────────────► ON HELP-REQUEST FOR field │ │ │ └─ redisplay loop │ ├─ Enter / pushbutton / │ radio USER-COMMAND ────► selection-screen PAI events │ │ │ └─ AT SELECTION-SCREEN OUTPUT │ → redisplay │ └─ Execute F8 ─────────────► selection-screen PAI validation │ ├─ validation error │ └─ OUTPUT → redisplay │ └─ validation succeeds └─ START-OF-SELECTION │ ├─ report application logic ├─ END-OF-SELECTION, if defined └─ output/list processing ``` The straight-line version from the initial draft omitted the redisplay cycle. `AT SELECTION-SCREEN OUTPUT` can run many times; `INITIALIZATION` normally runs once for that report execution before the standard selection screen first appears. --- ## 2. Report Source Layout Versus Runtime Order A maintainable report can be arranged like this: ```abap REPORT zsales_order_report. " Global declarations and selection-screen definition TABLES sscrfields. PARAMETERS: p_open RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND mode, p_all RADIOBUTTON GROUP mode. SELECT-OPTIONS s_order FOR vbak-vbeln. CLASS lcl_application DEFINITION FINAL. PUBLIC SECTION. CLASS-METHODS run. ENDCLASS. CLASS lcl_application IMPLEMENTATION. METHOD run. " Application orchestration ENDMETHOD. ENDCLASS. INITIALIZATION. " One-time selection defaults AT SELECTION-SCREEN OUTPUT. " Dynamic screen attributes before each display AT SELECTION-SCREEN. " Cross-field/action validation START-OF-SELECTION. lcl_application=>run( ). ```34:T7d7b, ## 1. What ALV Is — and Is Not ALV, the SAP List Viewer, is a presentation framework for structured datasets. It can supply standard user functions such as sorting, filtering, totals, subtotals, layouts, printing, and export. ```text Database / CDS / released API │ ▼ Application reads, authorizes, and derives data │ ▼ Internal table = report output model │ ▼ ALV renders List, Grid, or Tree │ ▼ User sorts, filters, selects, navigates, or edits ``` ALV does **not** by itself: - read the correct business data; - authorize a user to see or change that data; - enforce business invariants; - persist edited cells; - fix duplicate rows caused by an incorrect SQL join; - turn a classic report into a Fiori or RAP application. Think of ALV as the report's **view and interaction adapter**. The internal table is its input model; application methods own the business behavior. --- ## 2. End-to-End Runtime Flow For a read-only executable report using SALV: ```text Program/report starts │ ▼ Selection-screen lifecycle │ defaults → dynamic PBO → user input → validation ▼ START-OF-SELECTION │ ├─ authorize requested scope ├─ read through an appropriate CDS view/API/Open SQL ├─ calculate and map the output model └─ return an internal table │ ▼ CL_SALV_TABLE=>FACTORY │ ├─ configure functions, columns, sorts, layout, events └─ DISPLAY │ ▼ User sorts/filters/totals/exports or triggers navigation ``` For an editable GUI grid, the display is only half the workflow: ```text Application internal table │ ▼ CL_GUI_ALV_GRID display │ ▼ User edits a frontend cell │ ├─ REGISTER_EDIT_EVENT / DATA_CHANGED └─ CHECK_CHANGED_DATA transfers/checks pending frontend changes │ ▼ Application validates values and authorization │ ├─ invalid → protocol/message; do not save └─ valid → released update API / BAPI / application service / EML │ ▼ transaction owner commits │ ▼ refresh application data and ALV ``` The decisive point is: **an editable cell is not a database update**. `CHECK_CHANGED_DATA` is part of synchronizing/validating the grid state; it is not persistence. --- ## 3. The Three Presentation Shapes People often say “ALV list, grid, and tree.” These are presentation shapes, not three levels of the same report. | Shape | Data relationship | Best fit | Typical technology | | -------- | ------------------------------------------------ | ---------------------------------------- | -------------------------------------------------------------------------- | | **List** | Flat rows or classic two-level sequential output | Printing, spool, legacy reports | Classic ALV list; `CL_SALV_HIERSEQ_TABLE` for two-level header/item output | | **Grid** | Flat two-dimensional table | Interactive analysis; optionally editing | `CL_SALV_TABLE` or `CL_GUI_ALV_GRID` | | **Tree** | Nodes with explicit parent/child relationships | Hierarchy navigation | `CL_SALV_TREE` or `CL_GUI_ALV_TREE` | SAP's ALV object model names the core structural forms more precisely: - `CL_SALV_TABLE`: simple, two-dimensional table; - `CL_SALV_HIERSEQ_TABLE`: hierarchical-sequential header/item list; - `CL_SALV_TREE`: arbitrary tree structure. Therefore, “list versus grid” can also describe the **rendering technology** of a simple table, while table versus hierarchy describes the **data shape**. Ask which meaning a colleague intends before choosing a class. ### 3.1 List view A list-oriented result is appropriate when printable sequential output matters more than rich cell interaction. It is also the conceptually safer direction for a background job that must create spool output. For the SALV simple-table model, the factory's `LIST_DISPLAY` choice selects a classic list-style rendering instead of the normal fullscreen grid rendering: ```abap cl_salv_table=>factory( EXPORTING list_display = abap_true IMPORTING r_salv_table = DATA(alv) CHANGING t_table = output ). alv->display( ). ``` This is an important distinction: `CL_SALV_TABLE` identifies the simple two-dimensional **data model**; `LIST_DISPLAY` influences its **display mode**. Always test printing and background behavior on the target release rather than inferring it only from the class name. Classic APIs such as `REUSE_ALV_LIST_DISPLAY` and `REUSE_ALV_GRID_DISPLAY_LVC` still appear in existing systems. Their `SLIS_*` and `LVC_*` metadata must be understood for maintenance, but new OO-oriented code should normally consider the ALV object model first when its capabilities fit. ### 3.2 Grid view A grid displays a flat table with columns and rows. Choose: - `CL_SALV_TABLE` for concise, mostly read-only reporting; - `CL_GUI_ALV_GRID` when you need editable cells, detailed grid events, a custom toolbar, or precise embedding in a screen/container. ### 3.3 Tree view A tree represents real hierarchy. Each node has identity and a relationship to a parent node. Sorting a flat table and indenting text does not create a sound tree model. Examples: ```text Sales Order 50000123 ├─ Item 10 │ ├─ Schedule line 1 │ └─ Schedule line 2 └─ Item 20 └─ Schedule line 1 ``` Use `CL_SALV_TREE` for a high-level tree display and `CL_GUI_ALV_TREE` when the application needs lower-level control. Use `CL_SALV_HIERSEQ_TABLE` when the model is exactly two sequential levels, such as header and items, rather than an arbitrary-depth tree. --- ## 4. Selection Guide | Requirement | Recommended starting point | Reason | | --------------------------------------- | -------------------------------------------- | ---------------------------------------- | | Quick read-only flat report | `CL_SALV_TABLE` | Minimal setup and standard ALV functions | | Editable cells | `CL_GUI_ALV_GRID` | Supported grid edit/event lifecycle | | Custom toolbar and fine-grained events | `CL_GUI_ALV_GRID` | Direct Control Framework integration | | Arbitrary parent/child hierarchy | `CL_SALV_TREE` | Node-oriented hierarchy model | | Highly customized hierarchy control | `CL_GUI_ALV_TREE` | Lower-level tree behavior | | Exactly header + item sequential levels | `CL_SALV_HIERSEQ_TABLE` | Matches the two-level data shape | | Background/spool-oriented output | List/spool-safe design | GUI controls require a frontend | | Very large HANA-backed result | Consider ALV with IDA, if available/released | Pushes paging/filtering toward HANA | Do not choose `CL_GUI_ALV_GRID` merely because it is more powerful. Its screen, container, frontend-state, event, and lifetime responsibilities are real complexity. --- ## 5. The Output Internal Table Is a View Model Do not send a persistence table to ALV merely because it already has fields. Define the output grain and only expose columns that serve the report. ```abap TYPES: BEGIN OF ty_order_output, sales_order TYPE vbak-vbeln, sold_to_party TYPE vbak-kunnr, overall_status TYPE c LENGTH 1, net_amount TYPE p LENGTH 15 DECIMALS 2, currency TYPE waers, END OF ty_order_output, ty_order_output_tab TYPE STANDARD TABLE OF ty_order_output WITH EMPTY KEY. ``` The model should contain: - the business key needed for navigation or update; - display values at one explicitly chosen grain; - currency/unit reference fields for amounts and quantities; - optional technical style/color fields required by an editable grid; - no sensitive fields merely “hidden” from the initial layout. Hiding a field with `NO_OUT` or a saved layout is presentation, not security. Protect the read before building the output table, and assume export/layout features can reveal any field supplied to the frontend. ### 5.1 Preserve the grain If one order header is joined to ten items and the header amount repeats ten times, ALV totals will correctly total the rows it received—and produce the wrong business answer. Fix the query/output grain rather than blaming ALV. --- ## 6. `CL_SALV_TABLE`: Read-Only Table with Minimal Ceremony `CL_SALV_TABLE` is the normal first choice for a flat display-only report. The factory receives the output internal table, creates the ALV model, and returns the main SALV object. ```abap CLASS lcl_output DEFINITION FINAL. PUBLIC SECTION. CLASS-METHODS display CHANGING orders TYPE ty_order_output_tab. ENDCLASS. CLASS lcl_output IMPLEMENTATION. METHOD display. TRY. cl_salv_table=>factory( IMPORTING r_salv_table = DATA(alv) CHANGING t_table = orders ). alv->get_functions( )->set_all( abap_true ). alv->get_columns( )->set_optimize( abap_true ). alv->get_display_settings( )->set_striped_pattern( abap_true ). alv->display( ). CATCH cx_salv_msg INTO DATA(error). MESSAGE error->get_text( ) TYPE 'E'. ENDTRY. ENDMETHOD. ENDCLASS. ``` Typical caller: ```abap START-OF-SELECTION. DATA(orders) = lcl_order_query=>execute( sales_orders = s_vbeln[] ). lcl_output=>display( CHANGING orders = orders ). ``` ### 6.1 What SALV owns SALV offers subobjects for configuration: ```text CL_SALV_TABLE ├─ GET_FUNCTIONS( ) standard toolbar functions ├─ GET_COLUMNS( ) column collection ├─ GET_SORTS( ) initial sorting ├─ GET_AGGREGATIONS( ) totals/aggregations ├─ GET_SELECTIONS( ) selection behavior/state ├─ GET_DISPLAY_SETTINGS( ) general appearance ├─ GET_LAYOUT( ) layout variants └─ GET_EVENT( ) SALV events ``` ### 6.2 Configure one column ```abap TRY. DATA(columns) = alv->get_columns( ). DATA(column) = columns->get_column( 'NET_AMOUNT' ). column->set_short_text( 'Net' ). column->set_medium_text( 'Net Amount' ). column->set_long_text( 'Sales Order Net Amount' ). CATCH cx_salv_not_found. " Programming/configuration mismatch: field is not in the output model ENDTRY. ``` Names passed to SALV refer to the ABAP component names in the output line type, usually interpreted in uppercase. A DDIC-backed component lets ALV reuse field labels, conversion exits, value help, and type semantics more reliably than an unrelated primitive type. ### 6.3 SALV editing boundary The supported `CL_SALV_TABLE` public model is display-oriented. Do not rely on release-dependent or unsupported tricks that extract an underlying GUI grid to make SALV editable. If editing is a real requirement, choose `CL_GUI_ALV_GRID` and implement the complete edit, validation, authorization, and persistence lifecycle explicitly. --- ## 7. SALV Events: Navigation, Not Business Trust A SALV double-click can navigate to an order detail, but the row number is only presentation state. After users sort and filter, row position is not a stable business identity. Conceptual event-handler shape: ```abap CLASS lcl_salv_handler DEFINITION FINAL. PUBLIC SECTION. METHODS on_double_click FOR EVENT double_click OF cl_salv_events_table IMPORTING row column. ENDCLASS. ``` Registration: ```abap DATA(events) = alv->get_event( ). DATA(handler) = NEW lcl_salv_handler( ). SET HANDLER handler->on_double_click FOR events. ``` Keep the handler object alive for as long as the ALV can raise events. In the handler: 1. resolve the selected row against the current output model; 2. extract its business key; 3. recheck authorization and current state; 4. call an application navigation/action method. Never treat “the user could see or select row 5” as authorization to update the business object represented by row 5. --- ## 8. `CL_GUI_ALV_GRID`: Control-Based Grid Architecture `CL_GUI_ALV_GRID` is a SAP GUI Control Framework control. It requires a parent container and therefore participates in a dynpro's PBO/PAI lifecycle. ```text Executable report │ └─ CALL SCREEN 0100 │ ├─ PBO: create custom container once │ create grid once │ register handlers once │ first display once │ ├─ SAP GUI: user interacts with grid │ └─ PAI: synchronize changes and process command then return to PBO for refresh ``` Screen 0100 normally contains a Custom Control element named, for example, `ALV_CONTAINER`. ### 8.1 Persistent controller attributes The grid, container, event handler, and output table must outlive a single PBO method call. Keep them as suitable program-global references or, preferably, attributes of a screen-controller object. ```abap DATA: container TYPE REF TO cl_gui_custom_container, grid TYPE REF TO cl_gui_alv_grid, output TYPE ty_order_output_tab, field_catalog TYPE lvc_t_fcat, layout TYPE lvc_s_layo. ``` ### 8.2 PBO: create once, refresh later ```abap MODULE status_0100 OUTPUT. SET PF-STATUS 'MAIN'. IF grid IS INITIAL. container = NEW cl_gui_custom_container( container_name = 'ALV_CONTAINER' ). grid = NEW cl_gui_alv_grid( i_parent = container ). " Register event handlers here, before user interaction grid->set_table_for_first_display( EXPORTING is_layout = layout CHANGING it_outtab = output it_fieldcatalog = field_catalog ). ELSE. grid->refresh_table_display( is_stable = VALUE lvc_s_stbl( row = abap_true col = abap_true ) ). ENDIF. ENDMODULE. ``` SAP documents `SET_TABLE_FOR_FIRST_DISPLAY` as the initial binding operation. Call `REFRESH_TABLE_DISPLAY` when only the data changes. Repeat the initial call only when the output structure changes. ### 8.3 PAI: process commands ```abap MODULE user_command_0100 INPUT. CASE sy-ucomm. WHEN 'SAVE'. lcl_screen_controller=>save( ). WHEN 'BACK' OR 'EXIT' OR 'CANC'. LEAVE TO SCREEN 0. ENDCASE. ENDMODULE. ``` The GUI status decides which function codes exist. The ALV grid can also raise toolbar and `USER_COMMAND` events for grid-specific functions. --- ## 9. Field Catalog: Structural and UI Metadata `CL_GUI_ALV_GRID` commonly uses `LVC_T_FCAT`, whose line type is `LVC_S_FCAT`. Important fields include: | Field | Meaning | | -------------------------- | ------------------------------------------------ | | `FIELDNAME` | Component in the output line type | | `COLTEXT`, `SCRTEXT_S/M/L` | Column labels | | `KEY` | Visually identifies a key column | | `NO_OUT` | Initially hides a column; not a security control | | `EDIT` | Makes a cell/column input-enabled in the grid | | `HOTSPOT` | Enables hotspot interaction | | `CHECKBOX` | Displays a checkbox-compatible field | | `DO_SUM` | Requests totals where supported | | `REF_TABLE`, `REF_FIELD` | Reuses DDIC metadata | | `CFIELDNAME` | Currency-reference component for an amount | | `QFIELDNAME` | Unit-reference component for a quantity | You can let the grid derive metadata from a single DDIC structure by passing `I_STRUCTURE_NAME`, or pass an explicit field catalog for a local/mixed output type and custom UI behavior. Example helper: ```abap APPEND VALUE lvc_s_fcat( fieldname = 'NET_AMOUNT' coltext = 'Net Amount' cfieldname = 'CURRENCY' do_sum = abap_true ) TO field_catalog. ``` Metadata names must match the actual output structure. A field catalog does not map database fields into differently named ABAP components; build that mapping when selecting or transforming the output model. --- ## 10. Editable Grid Lifecycle Setting `EDIT = abap_true` only changes the frontend interaction. A complete edit flow has five separate responsibilities. ### 10.1 Enable and register ```abap grid->register_edit_event( i_event_id = cl_gui_alv_grid=>mc_evt_modified ). SET HANDLER handler->on_data_changed FOR grid. ``` Common grid events include `DATA_CHANGED`, `DATA_CHANGED_FINISHED`, `DOUBLE_CLICK`, `HOTSPOT_CLICK`, `TOOLBAR`, and `USER_COMMAND`. ### 10.2 Validate pending changes Before a Save command uses the output table, synchronize pending frontend edits: ```abap DATA valid TYPE abap_bool. grid->check_changed_data( IMPORTING e_valid = valid ). CHECK valid = abap_true. ``` This is especially important when a user types into a cell and immediately presses Save without first leaving the cell or pressing Enter. ### 10.3 Separate UI checks from business checks The `DATA_CHANGED` handler can give immediate feedback about syntax, domains, or cross-cell relationships. The application service must still enforce: - current authorization; - optimistic-lock/version rules; - business invariants; - current database state; - transactional consistency. Client-side or ALV-event validation is not a security boundary. ### 10.4 Persist explicitly Use the system's supported change contract: for example a released API, BAPI, application service, or EML for a RAP BO. Do not perform an arbitrary direct table update simply because the grid output resembles the table. The transaction owner decides the commit/rollback boundary. Reusable methods should not casually issue `COMMIT WORK` when their caller owns the larger unit of work. ### 10.5 Re-read and refresh After successful persistence, re-read authoritative state when calculations, status changes, locks, or other users may have changed the record. Then refresh the grid while preserving row/column stability where appropriate. --- ## 11. Row Index Versus Business Identity ALV selection APIs frequently return display row indexes. Sorting and filtering can change what an index refers to. ```text Unsafe assumption: selected index 3 = database record originally loaded at index 3 Safe flow: current selected index → current output row → immutable business key → fresh authorization/state check → business operation ``` For SD-style data, carry `VBELN`, `POSNR`, and `ETENR` at the appropriate grain even if some technical key columns are not initially prominent. For a RAP BO, carry its actual entity key; an ALV row number is not `%tky`. --- ## 12. List and Background Processing `CL_GUI_ALV_GRID` needs the SAP GUI Control Framework and a frontend container. It is not a background-processing output mechanism. For a report that also runs as a job, design output behind an interface: ```text Application produces typed result table │ ├─ dialog renderer → SALV/grid ├─ job renderer → spool/list or file └─ test renderer → assertions on result table ``` In background: - there is no user-driven grid interaction; - frontend-dependent controls are unavailable; - selection variants supply input; - operational evidence belongs in job log, spool, application log, or a deliberately produced file. Do not assume that a SALV call automatically provides the exact background spool behavior the business needs. Test the chosen display mode in the target release and execution environment. --- ## 13. Tree Data Modeling A tree has two distinct concerns: ```text Hierarchy model Display data ------------------------------ -------------------------- node key node text parent/related node key amount/status/attributes relationship type icons and column values ``` With `CL_SALV_TREE`, the application creates nodes individually, relates each node to a parent or sibling, and assigns the node's data row. Node keys are ALV technical identities; keep business keys separately for navigation. Choose a tree only when users need to reason about containment or dependency. If they mainly compare amounts across many orders, a flat grid grouped and sorted by order is usually easier to scan. ### Tree risks - one cyclic or missing parent breaks hierarchy construction; - eager expansion of a huge tree overwhelms users and memory; - totals across levels can double count parent and child values; - a selected node key is still not authorization; - loading every deep child before it is expanded can be unnecessarily costly. --- ## 14. Currency, Quantity, Totals, and Semantics An amount without its currency and a quantity without its unit are incomplete business values. For a grid field catalog, connect amount/quantity components to the output components holding currency/unit via `CFIELDNAME` and `QFIELDNAME`. Prefer DDIC reference fields where available. Do not total values across different currencies merely because ALV permits a numeric total. Either: - group/subtotal by currency; - convert using an explicit business rule and date/rate type; - suppress a meaningless grand total. The same principle applies to incompatible quantity units. --- ## 15. Layout Variants ALV layouts can store presentation preferences such as column order, width, visibility, sorting, filtering, and totals. Variant identity is commonly described using `DISVARIANT` values such as report and handle, with save scope controlled by the ALV API. Keep three ideas separate: ```text Selection variant → input parameters and select-options ALV layout variant → result presentation Business variant → domain-specific configuration, if any ``` An ALV layout filter does not reduce the database query or replace read authorization. The data may already have reached the frontend before the user hides it. When changing an output structure, test existing saved layouts. Renamed or removed columns can make old variants behave unexpectedly. --- ## 16. Performance Model ALV can sort and filter its supplied dataset, but it cannot undo an over-fetching query. ```text Best order of responsibility: 1. database/API restricts rows and columns 2. application derives the exact report grain 3. ALV provides interactive presentation operations ``` For performance diagnosis: 1. measure the data-access phase separately from rendering; 2. inspect SQL with SQL Monitor/ST05 when appropriate; 3. check row count and output width; 4. look for joins that multiply rows; 5. avoid expensive per-row database queries; 6. consider HANA-oriented ALV with IDA for supported large-data scenarios; 7. test frontend rendering and export separately. `CL_SALV_GUI_TABLE_IDA` can support database-oriented paging/filtering on HANA in systems where the class and data source are suitable. It is not a drop-in reason to ignore data authorization, released-object rules, or the target system's API state. --- ## 17. Authorization and Data Protection Apply authorization before sensitive data enters the ALV output model. ```text Wrong boundary: SELECT everything → send to ALV → hide unauthorized column Correct boundary: authorize scope → select allowed data/fields → build output → display ``` For an action or save, authorize again against the current record and requested operation. Read authorization does not imply update, delete, approve, or export authorization. Also consider: - spreadsheet/local-file export; - print/spool access; - saved layout variants; - personal data displayed in diagnostic columns; - transaction navigation from double-click/hotspot events. --- ## 18. Error and Message Design Handle errors at the layer that understands them: | Error | Owning layer | Example response | | ------------------------------ | ---------------------------------- | ------------------------------------------ | | Invalid selection interval | Selection-screen/application input | Field/cross-field message | | User cannot read company code | Authorization/application service | Reject before output | | SALV column not found | ALV configuration | Developer-facing handling/log | | Invalid edited amount | Grid handler + business service | Cell protocol and no save | | Record changed by another user | Persistence/business API | Conflict message and refresh | | Database/API failure | Data-access layer | Logged technical cause + safe user message | An empty result is not always an error. Distinguish “no matching authorized records” from a broken query or swallowed exception. --- ## 19. Common Failure Patterns | Symptom | Likely cause | Diagnostic move | | ----------------------------------- | -------------------------------------- | --------------------------------------------- | | Empty ALV | Query/filter/auth produced no rows | Inspect result table before display | | Wrong/missing columns | Field catalog and line type disagree | Compare `FIELDNAME` with actual components | | Amount displayed without currency | Missing DDIC/currency reference | Set reference metadata/`CFIELDNAME` | | Total is multiplied | Header repeated by item/schedule join | Reconstruct result grain before ALV | | Edit disappears on Save | Pending frontend edit not synchronized | Call `CHECK_CHANGED_DATA` and inspect handler | | Edit appears saved but DB unchanged | Only output internal table changed | Trace explicit persistence call/transaction | | Grid resets on every action | Grid recreated in every PBO | Create once; refresh subsequently | | Handler stops firing | Handler reference went out of scope | Keep handler alive with the control | | Wrong record opened after sort | Original index treated as identity | Resolve current row and use business key | | Background job fails | GUI control requires frontend | Use a background-safe renderer | | Hidden data appears in export | UI hiding treated as security | Do not send unauthorized fields | | Refresh jumps/loses context | Unstable refresh | Use stable row/column options where suitable | --- ## 20. Classic ALV APIs Versus Modern Direction | Technology | Status/use | Main concern | | ------------------------------ | ---------------------------------------------- | ------------------------------------------ | | `REUSE_ALV_LIST_DISPLAY` | Common legacy list reports | Procedural callback and `SLIS_*` patterns | | `REUSE_ALV_GRID_DISPLAY(_LVC)` | Common legacy grid reports | Function-module callbacks and global state | | `CL_SALV_TABLE` | Preferred concise OO display where it fits | Read-only/public display model | | `CL_GUI_ALV_GRID` | Appropriate for rich classic GUI control needs | More lifecycle and event responsibility | | RAP + Fiori elements | Service/UI architecture, not ALV | CDS/behavior/OData/UI annotation lifecycle | When maintaining a legacy report, improve boundaries without rewriting solely for fashion. Extract authorization, query, transformation, and update logic from callbacks first. Then the renderer can be replaced independently if the business case justifies it. --- ## 21. SD Technical-Consultant Example Suppose a report shows sales-order schedule fulfillment. ### Output grain One row per sales order item schedule line: ```text VBELN + POSNR + ETENR ``` ### Flow ```text Selection: sales org, document/date range, status │ ├─ authorize organizational scope ├─ read released CDS/API or appropriate classic source ├─ construct one row per schedule line ├─ preserve order/item/schedule keys ├─ derive open quantity without mixing units └─ render read-only with CL_SALV_TABLE ``` A double-click can navigate to display the business document after a fresh authorization check. If the requirement becomes “mass-change requested dates,” that is not just `EDIT = X`: choose `CL_GUI_ALV_GRID`, capture changes, validate SD rules, call a supported sales-order change contract, handle conflicts and messages, and refresh authoritative results. In clean-core design, prefer released CDS views/APIs and verify API State in the target release. Directly updating `VBAK`, `VBAP`, or `VBEP` is not a valid business update mechanism. --- ## 22. Tools and Debugging Landmarks | Tool/object | Use | | ------------------------------ | --------------------------------------------------- | | `SE38` / `SA38` | Execute or inspect classic reports, where available | | ADT debugger | Break before display, handlers, and save service | | `SE24` | Inspect class interfaces in classic systems | | `DWDM`, `SE83`, `BCALV*` demos | Explore installed Control Framework examples | | `ST22` | Analyze runtime dumps | | `SAT` | Separate query/transformation/rendering time | | `ST05`, SQL Monitor | Diagnose data access, not ALV formatting | | `SU53` / authorization trace | Diagnose authorization failure appropriately | | `SM37` and `SP01` | Background job and spool evidence | Availability and recommended tools vary by edition and authorization. A demo program illustrates an API; it is not automatically a production architecture. --- ## 23. Implementation Checklist ### Before coding - What is one output row? - Is the result flat, exactly two-level, or an arbitrary hierarchy? - Is it read-only or genuinely transactional? - Must it run in background? - Which fields and rows may the user read/export? - What is the supported data/change API in this system edition? ### For `CL_SALV_TABLE` - Build a typed, authorized result table. - Call `FACTORY`, configure subobjects, then `DISPLAY`. - Keep event handlers alive. - Resolve navigation through business keys, not row indexes. - Do not use unsupported SALV-edit hacks. ### For `CL_GUI_ALV_GRID` - Create a custom screen and parent container. - Keep container, grid, handler, and output alive. - Call `SET_TABLE_FOR_FIRST_DISPLAY` once. - Register required events. - Synchronize pending edits before Save. - Validate and authorize in the business layer. - Persist through the supported contract. - Re-read and call `REFRESH_TABLE_DISPLAY`. - Provide a separate output path for background processing. --- 35:T850,1. What ALV Is — and Is Not ALV, the SAP List Viewer, is a presentation framework for structured datasets. It can supply standard user functions such as sorting, filtering, totals, subtotals, layouts, printing, and export. text Database / CDS / released API │ ▼ Application reads, authorizes, and derives data │ ▼ Internal table = report output model │ ▼ ALV renders List, Grid, or Tree │ ▼ User sorts, filters, selects, navigates, or edits ALV does not by itself: - read the correct business data; - authorize a user to see or change that data; - enforce business invariants; - persist edited cells; - fix duplicate rows caused by an incorrect SQL join; - turn a classic report into a Fiori or RAP application. Think of ALV as the report's view and interaction adapter. The internal table is its input model; application methods own the business behavior. --- 2. End-to-End Runtime Flow For a read-only executable report using SALV: text Program/report starts │ ▼ Selection-screen lifecycle │ defaults → dynamic PBO → user input → validation ▼ START-OF-SELECTION │ ├─ authorize requested scope ├─ read through an appropriate CDS view/API/Open SQL ├─ calculate and map the output model └─ return an internal table │ ▼ CLSALVTABLE=FACTORY │ ├─ configure functions, columns, sorts, layout, events └─ DISPLAY │ ▼ User sorts/filters/totals/exports or triggers navigation For an editable GUI grid, the display is only half the workflow: text Application internal table │ ▼ CLGUIALVGRID display │ ▼ User edits a frontend cell │ ├─ REGISTEREDITEVENT / DATACHANGED └─ CHECKCHANGEDDATA transfers/checks pending frontend changes │ ▼ Application validates values and authorization │ ├─ invalid → protocol/message; do not save └─ valid → released update API / BAPI / application service / EML │ ▼ transaction owner commits │ ▼ refresh application data and ALV The decisive point is: an editable cell is not a database update. CHECKCHANGEDDATA is part of synchronizing/validating the grid state; it is not persistence. --- 3. The36:T92f,## 1. What ALV Is — and Is Not ALV, the SAP List Viewer, is a presentation framework for structured datasets. It can supply standard user functions such as sorting, filtering, totals, subtotals, layouts, printing, and export. ```text Database / CDS / released API │ ▼ Application reads, authorizes, and derives data │ ▼ Internal table = report output model │ ▼ ALV renders List, Grid, or Tree │ ▼ User sorts, filters, selects, navigates, or edits ``` ALV does **not** by itself: - read the correct business data; - authorize a user to see or change that data; - enforce business invariants; - persist edited cells; - fix duplicate rows caused by an incorrect SQL join; - turn a classic report into a Fiori or RAP application. Think of ALV as the report's **view and interaction adapter**. The internal table is its input model; application methods own the business behavior. --- ## 2. End-to-End Runtime Flow For a read-only executable report using SALV: ```text Program/report starts │ ▼ Selection-screen lifecycle │ defaults → dynamic PBO → user input → validation ▼ START-OF-SELECTION │ ├─ authorize requested scope ├─ read through an appropriate CDS view/API/Open SQL ├─ calculate and map the output model └─ return an internal table │ ▼ CL_SALV_TABLE=>FACTORY │ ├─ configure functions, columns, sorts, layout, events └─ DISPLAY │ ▼ User sorts/filters/totals/exports or triggers navigation ``` For an editable GUI grid, the display is only half the workflow: ```text Application internal table │ ▼ CL_GUI_ALV_GRID display │ ▼ User edits a frontend cell │ ├─ REGISTER_EDIT_EVENT / DATA_CHANGED └─ CHECK_CHANGED_DATA transfers/checks pending frontend changes │ ▼ Application validates values and authorization │ ├─ invalid → protocol/message; do not save └─ valid → released update API / BAPI / application service / EML │ ▼ transaction owner commits │ ▼ refresh application data and ALV ```5:["$","main",null,{"className":"blog-module__JsT-Oq__blogRoot","children":[["$","$Lf",null,{}],["$","$L10",null,{"documents":[{"slug":"hello-world","language":"vi","title":"Chương 1. Hello World! Tôi đang học cách cảm nhận lại thế giới","part":"Part 1. Hello World","summary":"Tôi đã mất cả tỷ lần trì hoãn chỉ để đắn đo về việc xây dựng một khoảng lặng cho riêng mình. Thì bây giờ đây, chính là nó, JusteeSpace - một không gian, nơi tôi thoải mái ghi lại những câu chuyện, những trải nghiệm sống, là nơi lưu trữ, vừa mang tính cá nhân, vừa mang tính hệ thống. Một quyển nhật ký dành cho tôi ở phiên bản tương lai có thể xem lại những suy nghĩ, bài học mà tôi học được ở hiện tại.","category":"Personal","tags":["introduction"],"publishedAt":"2026-05-09","updatedAt":"$undefined","draft":false,"content":"$11","excerpt":"$12","previewContent":"## Điều gì đã thôi thúc tôi bắt đầu viết blog này?\n\nTôi vốn là một người không giỏi trong việc thể hiện cảm xúc, không giỏi trong việc diễn đạt và trình bày ý tưởng. Và nhìn lại quá khứ, điều đó đã cản trở tôi có thể dấn thân vào làm một việc gì đó hết mình. Những ngày tháng ngồi ở giảng đường Đại học, nếu như Giảng viên không trực tiếp gọi tôi thì có lẽ tôi cũng chả bao giờ phát biểu ý kiến, có lẽ là do sợ sai hay bị chê cười… haha… đúng là đần, mình là người trả tiền sử dụng dịch vụ mà, sợ cái đ’ gì chứ.\n\nCuộc sống của tôi cứ trôi qua êm đềm như vậy. Đến ngày tốt nghiệp, rồi cũng đi thực tập và may mắn có được công việc mà ở đó đã xây dựng lên nền tảng khá vững cho tôi. Bạn đã nghĩ cuộc sống của tôi như vậy là ổn, không có gì để chê đúng không, tốt nghiệp trường top (Bách Khoa), lại công việc ổn định. Cứ thế mà an nhàn đi, suy nghĩ làm gì.","connections":["who-am-i"],"readingMinutes":7,"languages":["vi"],"backlinks":[],"unresolvedReferences":[]},{"slug":"who-am-i","language":"vi","title":"Chương 2. Tôi là ai giữa thế giới này","part":"Part 1. Hello World","summary":"Tôi không định nghĩa bản thân bằng chức danh công việc, bằng những công nghệ mình thành thạo, hay bằng những con số vô hình trên màn hình máy tính. Bản thể của tôi là con người đã được hình thành dựa trên trải nghiệm sống, cách tôi phản ứng với những rào cản, hoài nghi của chính mình.","category":"Personal","tags":["introduction"],"publishedAt":"2026-05-12","updatedAt":"$undefined","draft":false,"content":"$13","excerpt":"$14","previewContent":"## Những thứ định nghĩa sự tồn tại của tôi\n\nMọi người thường nghĩ Dev bọn tôi chỉ biết có màn hình đen và những dòng code khô khan đúng không. Nhưng sau giờ làm, tôi lại ôm đàn, cầm máy ảnh đi lang thang, hoặc ngồi dựng một thước phim ngắn. Tôi còn chả biết có ai giống mình như vậy không. Blog này sinh ra vì tôi không muốn những mảnh ghép đó bị tách rời.\n\nTôi là một cựu sinh viên Bách Khoa K18, chuyên ngành Khoa học máy tính. Vâng, sau 5 năm trầy trật trên giảng đường, cuối cùng tôi cũng có thể tự tin giới thiệu mình là một Kỹ sư máy tính. Nhưng quay ngược thời gian vào thời điểm chọn ngành, bản thân tôi còn chả định nghĩa được 'kỹ sư' là gì. Tôi chỉ biết là xung quanh mọi người ca ngợi nó lắm, nào là ra trường lương nghìn đô, nào là tạo ra nhiều đột phá công nghệ. Năm đó, tôi cũng là một trong số ít học sinh của trường đỗ vào Bách Khoa, cảm giác bước đi mặt vênh lên trời, 'oách xà lách' vô cùng, và cái niềm tự hào âm ỉ ấy tôi vẫn giữ mãi cho đến tận bây giờ.","connections":["nothing-change-if-nothing-change"],"readingMinutes":6,"languages":["vi"],"backlinks":["hello-world"],"unresolvedReferences":[]},{"slug":"nothing-change-if-nothing-change","language":"vi","title":"Chương 3. Không có gì thay đổi nếu không có gì thay đổi","part":"Part 1. Hello World","summary":"Ai trong chúng ta cũng mong muốn trở thành phiên bản tốt hơn của chính mình, nhưng ít ai sẵn sàng thay đổi","category":"Personal","tags":["motivation"],"publishedAt":"2026-05-15","updatedAt":"$undefined","draft":false,"content":"$15","excerpt":"$16","previewContent":"## Chúng ta đang quá tham lam\n\nMạng xã hội ngày nay dựng lên những khung cảnh quá hoàn hảo: một đứa trẻ phát âm tiếng Anh chuẩn bản xứ, những người trẻ chưa đầy ba mươi đã sở hữu nhà riêng, xe sang hay tự do tài chính. Chúng ta lướt qua những lát cắt ấy mỗi ngày và vô tình rơi vào một cái bẫy tâm lý nguy hiểm: nhìn vào kết quả của người khác và gán nó làm tiêu chuẩn cho bản thân.\n\nNhưng sự thật là, những gì bạn thấy chưa chắc đã là 100% sự thật, có những bí mật đằng sau mà bạn chưa nhìn rõ, mọi trạng thái ở hiện tại đều có nguyên do của nó.\nĐằng sau một đứa trẻ nói tiếng Anh lưu khoát có thể là một gia đình có điều kiện, được đầu tư học trường quốc tế và tiếp xúc với ngoại ngữ từ lúc còn chưa sõi tiếng mẹ đẻ. Đằng sau một sự thành công sớm là những nguồn lực ngầm về tài chính, mối quan hệ hoặc xuất phát điểm vượt trội. Tất nhiên vẫn sẽ tồn tại vài trường hợp xuất chúng, nhưng tỷ lệ là dưới 1%.","connections":[],"readingMinutes":6,"languages":["vi"],"backlinks":["who-am-i"],"unresolvedReferences":[]},{"slug":"sap-switching","language":"vi","title":"Chương 1. Từ Kỹ Sư Phần Mềm Đến Hành Trình Mới Với SAP","part":"Part 2. Cú chuyển mình trong sự nghiệp","summary":"Từ 1 software engineer với kỹ năng Database Optimizing và Blockchain, vì sao tôi lại muốn bắt đầu hành trình mới với SAP","category":"Personal","tags":["sap"],"publishedAt":"2026-05-20","updatedAt":"$undefined","draft":false,"content":"$17","excerpt":"$18","previewContent":"## Bước đi chập chững từ các công ty khởi nghiệp\n\nTôi có nhiều năm làm việc với các công ty start up và may mắn được cọ xát với nhiều công nghệ mới, được nhúng tay khá sâu vào các dự án, như là trực tiếp sửa đổi / thiết kế lại hệ thống database của một ứng dụng đang chạy production và kết quả được cải thiện tương đối chỉ với vài kỹ năng cơ bản về Index và partitioning.","connections":["sap-foundation"],"readingMinutes":5,"languages":["vi"],"backlinks":[],"unresolvedReferences":[]},{"slug":"sap-foundation","language":"vi","title":"Chương 2. Đặt nền móng","part":"Part 2. Cú chuyển mình trong sự nghiệp","summary":"Định nghĩa tư duy, lên kế hoạch học tập để xây dựng nền móng vững chắc","category":"Personal","tags":["sap","foundation"],"publishedAt":"2026-05-27","updatedAt":"$undefined","draft":false,"content":"$19","excerpt":"$1a","previewContent":"$1b","connections":["sap-concepts"],"readingMinutes":7,"languages":["vi"],"backlinks":["sap-switching"],"unresolvedReferences":[]},{"slug":"sap-concepts","language":"vi","title":"Chương 3. Hiểu rõ hơn về các khái niệm trong SAP","part":"Part 2. Cú chuyển mình trong sự nghiệp","summary":"Cái nhìn toàn diện về hệ sinh thái SAP, từ tính năng cốt lõi, ngôn ngữ lập trình, hệ thống phân hệ đến cơ chế vận hành chi tiết của kiến trúc 3 lớp R/3 và Application Server.","category":"Personal","tags":["sap","foundation"],"publishedAt":"2026-06-01","updatedAt":"$undefined","draft":false,"content":"$1c","excerpt":"$1d","previewContent":"$1e","connections":["sap-abap"],"readingMinutes":3,"languages":["vi"],"backlinks":["sap-foundation"],"unresolvedReferences":[]},{"slug":"sap-abap","language":"vi","title":"Chương 4. ABAP Fundamentals: Bước Chân Vào Tầng Xử Lý Logic","part":"Part 2. Cú chuyển mình trong sự nghiệp","summary":"Những bài học đầu tiên về Technical trong SAP","category":"Personal","tags":["sap","foundation","abap"],"publishedAt":"2026-06-07","updatedAt":"$undefined","draft":false,"content":"$1f","excerpt":"$20","previewContent":"$21","connections":["sap-abap-1","sap-abap-2","sap-abap-3","sap-abap-4","sap-abap-5","sap-abap-6","sap-abap-7"],"readingMinutes":2,"languages":["vi"],"backlinks":["sap-concepts"],"unresolvedReferences":[]},{"slug":"sap-abap-1","language":"en","title":"ABAP BASIC Statements","part":"ABAP","summary":"ABAP Basic Statements","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-06-10","updatedAt":"$undefined","draft":false,"content":"$22","excerpt":"$23","previewContent":"$24","connections":[],"readingMinutes":5,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]},{"slug":"sap-abap-2","language":"en","title":"ABAP Data Dictionary","part":"ABAP","summary":"ABAP Data Dictionary","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-06-17","updatedAt":"$undefined","draft":false,"content":"$25","excerpt":"$26","previewContent":"$27","connections":[],"readingMinutes":5,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]},{"slug":"sap-abap-3","language":"en","title":"ABAP Open SQL","part":"ABAP","summary":"ABAP Open SQL","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-06-24","updatedAt":"$undefined","draft":false,"content":"$28","excerpt":"$29","previewContent":"$2a","connections":[],"readingMinutes":5,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]},{"slug":"sap-abap-4","language":"en","title":"ABAP Internal Table","part":"ABAP","summary":"ABAP Internal Table","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-06-28","updatedAt":"$undefined","draft":false,"content":"$2b","excerpt":"$2c","previewContent":"$2d","connections":[],"readingMinutes":16,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]},{"slug":"sap-abap-5","language":"en","title":"SAP ABAP Modularization","part":"ABAP","summary":"SAP ABAP Modularization","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-07-06","updatedAt":"$undefined","draft":false,"content":"$2e","excerpt":"$2f","previewContent":"$30","connections":[],"readingMinutes":19,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]},{"slug":"sap-abap-6","language":"en","title":"SAP ABAP Classical Report","part":"ABAP","summary":"SAP ABAP Classical Report","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-07-13","updatedAt":"$undefined","draft":false,"content":"$31","excerpt":"$32","previewContent":"$33","connections":[],"readingMinutes":18,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]},{"slug":"sap-abap-7","language":"en","title":"SAP ABAP ALV Report","part":"ABAP","summary":"SAP ABAP ALV Report","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-07-21","updatedAt":"$undefined","draft":false,"content":"$34","excerpt":"$35","previewContent":"$36","connections":[],"readingMinutes":19,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]}],"initialDocument":"$undefined","language":"vi"}]]}] b:[["$","meta","0",{"charSet":"utf-8"}],["$","meta","1",{"name":"viewport","content":"width=device-width, initial-scale=1"}]] 37:I[27201,["/_next/static/immutable/chunks/33v8uwkv4wy50.js"],"IconMark"] 8:null d:[["$","title","0",{"children":"Graph | Thanh's Blog"}],["$","meta","1",{"name":"description","content":"Explore connections between technical and personal documents."}],["$","link","2",{"rel":"shortcut icon","href":"/images/favicon.webp"}],["$","link","3",{"rel":"icon","href":"/images/favicon.webp"}],["$","link","4",{"rel":"apple-touch-icon","href":"/images/favicon.webp"}],["$","$L37","5",{}]] </article></body></html>

1:"$Sreact.fragment" 2:I[39756,["/_next/static/immutable/chunks/33v8uwkv4wy50.js"],"default"] 3:I[37457,["/_next/static/immutable/chunks/33v8uwkv4wy50.js"],"default"] 4:I[2355,["/_next/static/immutable/chunks/33v8uwkv4wy50.js"],"Analytics"] 6:I[97367,["/_next/static/immutable/chunks/33v8uwkv4wy50.js"],"OutletBoundary"] 7:"$Sreact.suspense" a:I[97367,["/_next/static/immutable/chunks/33v8uwkv4wy50.js"],"ViewportBoundary"] c:I[97367,["/_next/static/immutable/chunks/33v8uwkv4wy50.js"],"MetadataBoundary"] e:I[68027,["/_next/static/immutable/chunks/33v8uwkv4wy50.js"],"default",1] :HL["/_next/static/immutable/chunks/1svp_ktb3lglv.css","style"] :HL["/_next/static/immutable/media/3e185f0c9c3d9cda-s.p.034pt8qm9y03o.woff2","font",{"crossOrigin":"","type":"font/woff2"}] :HL["/_next/static/immutable/media/43cf86ead64c3be9-s.p.1_u0d4buat6wq.woff2","font",{"crossOrigin":"","type":"font/woff2"}] :HL["/_next/static/immutable/chunks/0_zxaas-0s6_u.css","style"] 9:X 0:{"P":null,"c":["","blog","graph"],"q":"","i":false,"f":[[["",{"children":["blog",{"children":["graph",{"children":["__PAGE__",{},"$undefined","$undefined",4096]},"$undefined","$undefined",4096]},"$undefined","$undefined",4096]},"$undefined","$undefined",4112],[["$","$1","c",{"children":[[["$","link","0",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/1svp_ktb3lglv.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}],["$","script","script-0",{"src":"/_next/static/immutable/chunks/33v8uwkv4wy50.js","async":true,"nonce":"$undefined"}]],["$","html",null,{"className":"alegreya_a702697e-module__PsVypa__variable","lang":"en","children":["$","body",null,{"children":[["$","$L2",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L3",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":[[["$","title",null,{"children":"404: This page could not be found."}],["$","div",null,{"style":{"fontFamily":"system-ui,\"Segoe UI\",Roboto,Helvetica,Arial,sans-serif,\"Apple Color Emoji\",\"Segoe UI Emoji\"","height":"100vh","textAlign":"center","display":"flex","flexDirection":"column","alignItems":"center","justifyContent":"center"},"children":["$","div",null,{"children":[["$","style",null,{"dangerouslySetInnerHTML":{"__html":"body{color:#000;background:#fff;margin:0}.next-error-h1{border-right:1px solid rgba(0,0,0,.3)}@media (prefers-color-scheme:dark){body{color:#fff;background:#000}.next-error-h1{border-right:1px solid rgba(255,255,255,.3)}}"}}],["$","h1",null,{"className":"next-error-h1","style":{"display":"inline-block","margin":"0 20px 0 0","padding":"0 23px 0 0","fontSize":24,"fontWeight":500,"verticalAlign":"top","lineHeight":"49px"},"children":404}],["$","div",null,{"style":{"display":"inline-block"},"children":["$","h2",null,{"style":{"fontSize":14,"fontWeight":400,"lineHeight":"49px","margin":0},"children":"This page could not be found."}]}]]}]}]],[]],"forbidden":"$undefined","unauthorized":"$undefined"}],["$","$L4",null,{}]]}]}]]}],{"children":[["$","$1","c",{"children":[null,["$","$L2",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L3",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":"$undefined","forbidden":"$undefined","unauthorized":"$undefined"}]]}],{"children":[["$","$1","c",{"children":[null,["$","$L2",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L3",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":"$undefined","forbidden":"$undefined","unauthorized":"$undefined"}]]}],{"children":[["$","$1","c",{"children":["$L5",[["$","link","0",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/0_zxaas-0s6_u.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}],["$","script","script-0",{"src":"/_next/static/immutable/chunks/2-8k3lz2s-o_5.js","async":true,"nonce":"$undefined"}],["$","script","script-1",{"src":"/_next/static/immutable/chunks/1m5f2czk4h9b6.js","async":true,"nonce":"$undefined"}],["$","script","script-2",{"src":"/_next/static/immutable/chunks/3pmii6-qqyemr.js","async":true,"nonce":"$undefined"}]],["$","$L6",null,{"children":["$","$7",null,{"name":"Next.MetadataOutlet","children":"$@8"}]}]]}],{},null,false,null]},null,false,"$9"]},null,false,"$9"]},null,false,null],["$","$1","h",{"children":[null,["$","$La",null,{"children":"$Lb"}],["$","div",null,{"hidden":true,"children":["$","$Lc",null,{"children":["$","$7",null,{"name":"Next.Metadata","children":"$Ld"}]}]}],["$","meta",null,{"name":"next-size-adjust","content":""}]]}],false]],"m":"$undefined","G":["$e",[["$","link","0",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/1svp_ktb3lglv.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}]]],"S":false,"h":null,"r":"$undefined","s":"$undefined","a":"$undefined","l":"$undefined","p":"$undefined","d":"$undefined","b":"tL7cnZXe905TG_nzUpOI4"} f:I[93963,["/_next/static/immutable/chunks/33v8uwkv4wy50.js","/_next/static/immutable/chunks/2-8k3lz2s-o_5.js","/_next/static/immutable/chunks/1m5f2czk4h9b6.js","/_next/static/immutable/chunks/3pmii6-qqyemr.js"],"Header"] 10:I[20586,["/_next/static/immutable/chunks/33v8uwkv4wy50.js","/_next/static/immutable/chunks/2-8k3lz2s-o_5.js","/_next/static/immutable/chunks/1m5f2czk4h9b6.js","/_next/static/immutable/chunks/3pmii6-qqyemr.js"],"GraphExplorer"] 9:C 11:T1f34, ## Điều gì đã thôi thúc tôi bắt đầu viết blog này? Tôi vốn là một người không giỏi trong việc thể hiện cảm xúc, không giỏi trong việc diễn đạt và trình bày ý tưởng. Và nhìn lại quá khứ, điều đó đã cản trở tôi có thể dấn thân vào làm một việc gì đó hết mình. Những ngày tháng ngồi ở giảng đường Đại học, nếu như Giảng viên không trực tiếp gọi tôi thì có lẽ tôi cũng chả bao giờ phát biểu ý kiến, có lẽ là do sợ sai hay bị chê cười… haha… đúng là đần, mình là người trả tiền sử dụng dịch vụ mà, sợ cái đ’ gì chứ. Cuộc sống của tôi cứ trôi qua êm đềm như vậy. Đến ngày tốt nghiệp, rồi cũng đi thực tập và may mắn có được công việc mà ở đó đã xây dựng lên nền tảng khá vững cho tôi. Bạn đã nghĩ cuộc sống của tôi như vậy là ổn, không có gì để chê đúng không, tốt nghiệp trường top (Bách Khoa), lại công việc ổn định. Cứ thế mà an nhàn đi, suy nghĩ làm gì. Sản phẩm ở công ty đầu tiên mà tôi làm việc, cuối cùng cũng đến được giai đoạn production, tôi hào hứng ở lại công ty ngồi countdown, ăn mừng vì app đã lên được App store. Nhưng những ngày sau đó lại là chuỗi ngày tát thẳng vào sự vui mừng ban đầu. Khi mà số lượng users sử dụng app tăng lên quá chậm, phần lớn còn vào vì chiến dịch give away… Chuỗi ngày fix bug gấp gáp trên production, hay gắn nhanh thêm nhiều tính năng vào để team sale có cái mà đi chào hàng, cố chạy đua mà không rõ đích đến. Mặc dù rất buồn nhưng tôi quyết định phải đi tìm bến đỗ mới để kết thúc chuỗi ngày vô nghĩa này, và khi ngồi xuống để viết lại CV, tôi rất khó để có thể viết portfolio mà không mở lại code để xem. Đấy là lúc tôi nhận ra kỹ năng viết không hề dễ, nếu không được rèn luyện, bạn sẽ rất khó để trình bày lại ý tưởng một cách súc tích mà vẫn thể hiện đầy đủ thông tin. Tính cách của developer thì phần lớn là hướng nội, chúng ta cứ âm thầm làm, nói thứ ngôn ngữ chỉ người trong ngành hiểu, và đôi khi bạn chỉ nói chuyện với những người ở trong circle của bạn. Sẽ có lúc bạn nhìn thấy những người có kỹ năng kém hơn bạn, nhưng họ lại có nhiều job hơn, lương cao hơn. Không nói ra nhưng trong lòng bạn vẫn thấy có điều gì đó sai trái, không công bằng. Không phải là do thế giới bất công đâu (à, có một chút). Tuy nhiên có một cái mà bạn không nhìn ra đó là họ giỏi hơn bạn về kỹ năng bán hàng, về kỹ năng trình bày vấn đề, họ giúp khách hàng hiểu giá trị công việc họ mang lại, hiểu rõ hơn về những gì họ đang làm. Và dĩ nhiên cơ hội tìm đến họ sẽ là cao hơn bạn. Khi bạn không biết giải thích, trình bày portfolio một cách rõ ràng, chả ai hiểu bạn đang làm gì cả. ## Cảm xúc và câu chuyện: Thứ AI không thể viết thay tôi Tốc độ phát triển AI 1-2 năm trở lại đây thật kinh khủng. việc nó gợi ý code để tôi ấn "Tab... Tab" hoàn thành một function đã thấy viễn tưởng lắm rồi. Vậy mà bây giờ, chỉ cần gõ một câu prompt ngắn, AI có thể hoàn thành cả một chương trình đơn giản, hay viết đầy đủ function, testcase trong module. Tôi không muốn bản thân mình phụ thuộc AI, nhưng số lượng task thì tăng dần và deadline ngày càng gần, khiến việc nếu không dùng AI nhiều thì không thể hoàn thành được. Một nghịch lý khi sử dụng AI là, tôi có thể làm được rất nhiều việc trong thời gian ngắn, tuy nhiên cảm giác tự tin của tôi thì giảm dần khi phản xạ đầu tiên của tôi khi nhận được task bây giờ là... gõ prompt. Đối với trải nghiệm cá nhân tôi, thì AI chỉ đang phóng đại khả năng hiện tại của bạn, chứ không thay bạn làm gì cả. Bằng chứng là đối với các task tôi đã nắm được cách làm, chỉ cần gõ vài prompt, lên plan thì AI làm xong rất nhanh, còn những task mà tôi không nắm rõ cách làm, tôi còn chả chắc chắn giải pháp mà AI đưa ra có thật sự là tốt không, mà cứ đọc xuôi tai là accept hết, tất nhiên đối với những task này thì thời gian hoàn thành lâu hơn hẳn những task trước. Nhưng có một điều không thể chối cãi là AI đã xoá bỏ kha khá những rào cản về mặt tiếp cận công nghệ. Trong thời đại AI, người thắng không phải là người chỉ có kỹ năng, người thắng sẽ là người biết cách học nhanh, nghĩ rõ và trình bày giá trị của bản thân ra ngoài. Và viết là kỹ năng giúp chúng ta thực hiện được cả 3 điều đấy. AI có thể tạo thông tin, nhưng không thể có trải nghiệm hay cảm xúc thực tế. Viết là cách duy nhất để gửi gắm cá tính, tư duy và trải nghiệm cá nhân. Kỹ thuật tốt giúp tạo ra sản phẩm, nhưng khả năng nói chuyện (storytelling) và truyền tải giá trị qua ngôn từ mới là thứ giúp khách hàng thực sự thấu hiểu, trân trọng và nhìn thấy giá trị của sản phẩm/dịch vụ đó. Viết chính là quá trình sắp xếp lại suy nghĩ, giúp tư duy mạch lạc và sắc bén hơn. ## Cấu trúc không gian - cách tôi phân bổ nội dung blog bằng 2 ngôn ngữ. Tôi sẽ cố gắng để các bài viết có đầy đủ cả hai ngôn ngữ: Tiếng Việt và Tiếng Anh. Cách viết là tôi sẽ viết một bài trên một ngôn ngữ gốc, sau đó dịch sang ngôn ngữ còn lại. Việc này giúp tôi review lại bài viết thêm một lần và chỉnh sửa lại những lỗ hỏng. Đối với các bài viết về Nhật ký, tôi sẽ viết bằng Tiếng Việt vì ngôn ngữ mẹ đẻ sẽ giúp tôi diễn đạt trọn vẹn sự tự nhiên, sâu sắc và cứ để cảm xúc dẫn mình đi mà không bị giới hạn bởi từ vựng. Vậy tại sao lại có chuyện viết bằng Tiếng Anh rồi dịch lại tiếng Việt ? Không phải vì tôi sính ngoại đâu. Do phần lớn các kiến thức tôi đều đọc bản gốc bằng Tiếng Anh, việc diễn giải thẳng bằng thuật ngữ kỹ thuật quốc tế sẽ chuẩn xác, dễ tra cứu và dễ trình bày suy nghĩ kỹ thuật một cách ngắn gọn. Với lại tôi có khả năng viết Tiếng Anh mà, tại sao không chứ…hehe. Các bài viết cũng sẽ không đứng đơn lẻ một mình, những thuật ngữ hay những bài viết liên quan sẽ tạo nên một liên kết cực kỳ bền vững, bạn có thể xem ở tab “Graph View” ## Những dòng chữ đầu tiên cho một chặng đường dài Hoàn thành luôn tốt hơn hoàn hảo. Việc nhấn nút _Publish_ cho bài viết này là bước đi đầu tiên giúp tôi bước ra khỏi sự trì hoãn của chính mình. Cảm ơn bạn đã đọc đến những dòng cuối cùng này. Hành trình viết và lưu trữ chính thức bắt đầu từ hôm nay. Chặng đường phía trước vẫn còn rất nhiều kiến trúc cần dựng và nhiều câu chuyện cần kể. [Đọc tiếp: Chương 2. Tôi là ai giữa thế giới này →](/blog/who-am-i) 12:T7a0,Điều gì đã thôi thúc tôi bắt đầu viết blog này? Tôi vốn là một người không giỏi trong việc thể hiện cảm xúc, không giỏi trong việc diễn đạt và trình bày ý tưởng. Và nhìn lại quá khứ, điều đó đã cản trở tôi có thể dấn thân vào làm một việc gì đó hết mình. Những ngày tháng ngồi ở giảng đường Đại học, nếu như Giảng viên không trực tiếp gọi tôi thì có lẽ tôi cũng chả bao giờ phát biểu ý kiến, có lẽ là do sợ sai hay bị chê cười… haha… đúng là đần, mình là người trả tiền sử dụng dịch vụ mà, sợ cái đ’ gì chứ. Cuộc sống của tôi cứ trôi qua êm đềm như vậy. Đến ngày tốt nghiệp, rồi cũng đi thực tập và may mắn có được công việc mà ở đó đã xây dựng lên nền tảng khá vững cho tôi. Bạn đã nghĩ cuộc sống của tôi như vậy là ổn, không có gì để chê đúng không, tốt nghiệp trường top (Bách Khoa), lại công việc ổn định. Cứ thế mà an nhàn đi, suy nghĩ làm gì. Sản phẩm ở công ty đầu tiên mà tôi làm việc, cuối cùng cũng đến được giai đoạn production, tôi hào hứng ở lại công ty ngồi countdown, ăn mừng vì app đã lên được App store. Nhưng những ngày sau đó lại là chuỗi ngày tát thẳng vào sự vui mừng ban đầu. Khi mà số lượng users sử dụng app tăng lên quá chậm, phần lớn còn vào vì chiến dịch give away… Chuỗi ngày fix bug gấp gáp trên production, hay gắn nhanh thêm nhiều tính năng vào để team sale có cái mà đi chào hàng, cố chạy đua mà không rõ đích đến. Mặc dù rất buồn nhưng tôi quyết định phải đi tìm bến đỗ mới để kết thúc chuỗi ngày vô nghĩa này, và khi ngồi xuống13:T1a0a, ## Những thứ định nghĩa sự tồn tại của tôi Mọi người thường nghĩ Dev bọn tôi chỉ biết có màn hình đen và những dòng code khô khan đúng không. Nhưng sau giờ làm, tôi lại ôm đàn, cầm máy ảnh đi lang thang, hoặc ngồi dựng một thước phim ngắn. Tôi còn chả biết có ai giống mình như vậy không. Blog này sinh ra vì tôi không muốn những mảnh ghép đó bị tách rời. Tôi là một cựu sinh viên Bách Khoa K18, chuyên ngành Khoa học máy tính. Vâng, sau 5 năm trầy trật trên giảng đường, cuối cùng tôi cũng có thể tự tin giới thiệu mình là một Kỹ sư máy tính. Nhưng quay ngược thời gian vào thời điểm chọn ngành, bản thân tôi còn chả định nghĩa được 'kỹ sư' là gì. Tôi chỉ biết là xung quanh mọi người ca ngợi nó lắm, nào là ra trường lương nghìn đô, nào là tạo ra nhiều đột phá công nghệ. Năm đó, tôi cũng là một trong số ít học sinh của trường đỗ vào Bách Khoa, cảm giác bước đi mặt vênh lên trời, 'oách xà lách' vô cùng, và cái niềm tự hào âm ỉ ấy tôi vẫn giữ mãi cho đến tận bây giờ. Thế nhưng, bước chân vào đại học chưa vui được bao lâu, cuộc đời đã vã cho tôi đôm đốp. Vốn xuất thân từ trường làng, tôi không đủ điều kiện tiếng Anh đầu vào của chương trình (IELTS 6.0) và bị xếp ngay vào lớp Pre-University. Thế giới của tôi lúc ấy bỗng chốc tối đen, vì đó là lần đầu tiên trong đời tôi thấm thía cảm giác thất bại. Cú sốc chưa dừng lại ở đó khi tôi bước vào phòng ký túc xá. Những đứa bạn bằng tuổi chung phòng toàn là 'quái vật': đứa thì giải Lý quốc gia, đứa thì IELTS 7.5 ôm bảng điểm sáng chói. Còn tôi? Chiếc IELTS 4.0 tròn trĩnh và một vốn tiếng Anh không thốt nổi một câu nên hồn. Nghĩ lại, vào thời điểm đó, cũng may là tôi có biết chút ít kỹ năng chơi đàn, việc kết bạn của mình đã trở nên dễ thở hơn. Tôi tự tập guitar từ năm tôi 15 tuổi, chỉ là lúc đấy nghỉ hè và không có gì làm nên tôi bảo ba mẹ là muốn học đàn, tôi muốn học piano, cơ mà số tiền tôi dành dụm được chỉ đủ mua guitar mà thôi (nghèo -\_-). Thế là tôi nghĩ thôi cũng được, đưa số tiền tích góp của mình cho anh hai mua về một cây guitar, giá của nó là 980k, không quá đắt nhưng vẫn là khoảng lớn dưới lăng kính của ba mẹ tôi (đến bây giờ tôi vẫn chưa thoải mái với việc chia sẻ giá trị thật những món đồ tôi sở hữu cho ba mẹ biết, có lẽ là khoảng cách thế hệ chăng, thời của bố mẹ, ăn no mặc ấm đã là hạnh phúc, làm sao hiểu được những mộng mơ nghệ thuật của tụi mình). Ngày nhận được cây đàn, tôi hào hứng gảy thử, để rồi nhận về một gáo nước lạnh: chả đánh được gì, cũng chả hiểu gì cả. Tại sao nó lại có 6 dây? Dây đầu tiên sao không phải nốt Đồ? Đã vậy bấm vào còn đau điếng cả tay. Tôi bất lực buông đàn, lòng thầm nghĩ: Có khi ngày xưa chọn piano lại đỡ khổ hơn..." Nhưng cũng may, 980k ngày ấy là một số tiền quá lớn đối với một đứa nhóc. Chính cái sự 'tiếc tiền' đó đã buộc tôi phải lì lợm ngồi lại với cây đàn. Tôi bắt đầu những chuỗi ngày nghiền ngẫm từng video hướng dẫn trên YouTube rồi lầm lũi thực hành. Từ những hợp âm bập bẹ đầu tiên, những bài nhạc đơn giản nhất, cho đến cả những kỹ thuật phức tạp sau này... tôi đều tự mình đi qua. Nghĩ lại, đó có lẽ là cột mốc đánh dấu thành quả tự học đầu tiên trong cuộc đời của tôi. Cho đến tận bây giờ, dù đã tốt nghiệp từ một ngôi trường đại học danh giá, tôi vẫn luôn tin rằng: Khả năng tự học mới chính là kỹ năng đáng giá nhất trong cuộc sống hiện đại, chứ không phải tấm bằng đại học. Tự học là thứ duy nhất cho bạn sự tự tin để tìm ra lời giải trong mọi tình huống, và quan trọng hơn cả, nó không bao giờ đặt ra giới hạn cho chính bản thân bạn. ## Nhãn dán nào cho tôi ? Tôi là ai giữa thế giới _Công nghệ_ và _Nghệ thuật_ ? Thật ra, bản thân tôi chưa bao giờ nghĩ quá nhiều về điều đó. Tôi chỉ đơn giản là làm những gì mình thích và thấy nên làm. Tôi đam mê công nghệ, thích đối mặt và giải quyết những bài toán hóc búa, và nó mang lại thu nhập cho tôi, giúp tôi mua được những món đồ tôi thích. Nhưng bên cạnh đó, tôi cũng yêu cái đẹp, yêu sự lãng mạn và bay bổng mà nghệ thuật mang lại. Đó cũng là lý do vì sao tôi ngồi xuống và bắt đầu gõ những dòng chữ này. Ngôn từ, suy cho cùng, có một sức mạnh to lớn hơn chúng ta tưởng tượng rất nhiều. Chúng ta thường có thói quen đóng khung giá trị của mình vào một cái nghề mỗi khi giới thiệu bản thân với ai đó. Nhưng hãy thử tưởng tượng, nếu một ngày vị trí đó không còn, cái nghề đó bỗng chốc biến mất, hoặc đơn giản là bạn đặt chân đến một vùng đất xa lạ nơi công việc ấy chưa từng tồn tại... lúc đó bạn sẽ định nghĩa bản thân mình như thế nào? Hay nói cách khác: Khi lột bỏ hết những danh xưng nghề nghiệp, bạn thực sự là ai? Đi qua nhiều lĩnh vực, tôi hiểu rằng mọi trải nghiệm đều bình đẳng như nhau. Gõ một dòng code hay bào một miếng gỗ phẳng, gảy một nhịp đàn hay bắt lấy một khung hình đẹp... mỗi khoảnh khắc đều mang lại cho tôi những rung động khác biệt. Tôi chọn không giới hạn mình trong bất kỳ định nghĩa nào, chỉ chọn tận hưởng cuộc đời này bằng mọi giác quan. Vì thế, cứ gọi tôi là Thanh – vậy là đủ. [Đọc tiếp: Chương 3. Không có gì thay đổi nếu không có gì thay đội →](/blog/nothing-change-if-nothing-change) 14:T7b0,Những thứ định nghĩa sự tồn tại của tôi Mọi người thường nghĩ Dev bọn tôi chỉ biết có màn hình đen và những dòng code khô khan đúng không. Nhưng sau giờ làm, tôi lại ôm đàn, cầm máy ảnh đi lang thang, hoặc ngồi dựng một thước phim ngắn. Tôi còn chả biết có ai giống mình như vậy không. Blog này sinh ra vì tôi không muốn những mảnh ghép đó bị tách rời. Tôi là một cựu sinh viên Bách Khoa K18, chuyên ngành Khoa học máy tính. Vâng, sau 5 năm trầy trật trên giảng đường, cuối cùng tôi cũng có thể tự tin giới thiệu mình là một Kỹ sư máy tính. Nhưng quay ngược thời gian vào thời điểm chọn ngành, bản thân tôi còn chả định nghĩa được 'kỹ sư' là gì. Tôi chỉ biết là xung quanh mọi người ca ngợi nó lắm, nào là ra trường lương nghìn đô, nào là tạo ra nhiều đột phá công nghệ. Năm đó, tôi cũng là một trong số ít học sinh của trường đỗ vào Bách Khoa, cảm giác bước đi mặt vênh lên trời, 'oách xà lách' vô cùng, và cái niềm tự hào âm ỉ ấy tôi vẫn giữ mãi cho đến tận bây giờ. Thế nhưng, bước chân vào đại học chưa vui được bao lâu, cuộc đời đã vã cho tôi đôm đốp. Vốn xuất thân từ trường làng, tôi không đủ điều kiện tiếng Anh đầu vào của chương trình (IELTS 6.0) và bị xếp ngay vào lớp Pre-University. Thế giới của tôi lúc ấy bỗng chốc tối đen, vì đó là lần đầu tiên trong đời tôi thấm thía cảm giác thất bại. Cú sốc chưa dừng lại ở đó khi tôi bước vào phòng ký túc xá. Những đứa bạn bằng tuổi chung phòng toàn là 'quái vật': đứa thì giải Lý quốc gia, đứa thì IELTS 7.5 ôm bảng điểm sáng chói. Còn tôi?15:T1a0c, ## Chúng ta đang quá tham lam Mạng xã hội ngày nay dựng lên những khung cảnh quá hoàn hảo: một đứa trẻ phát âm tiếng Anh chuẩn bản xứ, những người trẻ chưa đầy ba mươi đã sở hữu nhà riêng, xe sang hay tự do tài chính. Chúng ta lướt qua những lát cắt ấy mỗi ngày và vô tình rơi vào một cái bẫy tâm lý nguy hiểm: nhìn vào kết quả của người khác và gán nó làm tiêu chuẩn cho bản thân. Nhưng sự thật là, những gì bạn thấy chưa chắc đã là 100% sự thật, có những bí mật đằng sau mà bạn chưa nhìn rõ, mọi trạng thái ở hiện tại đều có nguyên do của nó. Đằng sau một đứa trẻ nói tiếng Anh lưu khoát có thể là một gia đình có điều kiện, được đầu tư học trường quốc tế và tiếp xúc với ngoại ngữ từ lúc còn chưa sõi tiếng mẹ đẻ. Đằng sau một sự thành công sớm là những nguồn lực ngầm về tài chính, mối quan hệ hoặc xuất phát điểm vượt trội. Tất nhiên vẫn sẽ tồn tại vài trường hợp xuất chúng, nhưng tỷ lệ là dưới 1%. Bạn cảm giác ghen tị với thành công của họ. Nhưng hành động của bạn là dành hàng giờ đồng hồ mỗi ngày chỉ để tiêu thụ nội dung và tiếp tục than vãn về cuộc sống hiện tại. Đợt rồi tôi có dịp được gặp lại những người bạn cũ thời cấp 3, cuộc trò chuyện đang rất vui vẻ thì đột nhiên có đứa bảo, "Chán quá tụi bây, tao làm ở chỗ đó mấy năm rồi mà chả thấy lên lương gì nhiều". Tôi mới hỏi lại nó là vậy công việc mày dạo này khó hơn trước à. Thì nó bảo, đâu vẫn thế thôi, mà tao làm được 4 năm rồi. Đoạn này tôi nghĩ thầm trong bụng thôi chứ cũng không nói ra, bro ở hiện tại làm việc y chang bro của 4 năm trước, vậy lý do gì mà người ta phải lên lương cho bro. Tôi dám cá là nếu tôi yêu cầu bạn liệt kê ra lợi ích của việc học tiếng anh, bạn sẽ kể ra được ít nhất là 10 đầu mục. Hay bạn biết rõ kiên trì tập gym sẽ được body đẹp hơn. Nhưng phần lớn chúng ta đều không làm những việc này. Không có quá nhiều người sẵn sàng trả giá để đạt được những gì họ thật sự muốn. ## Từ Nhận Thức Đến Hành Động: Kịch Bản Cho Sự Thay Đổi Chỉ ra sự thật phũ phàng này không phải để bạn chấp nhận số phận hay bỏ cuộc. Ý tôi là, mọi thứ trong cuộc sống này đều có thể thay đổi, chỉ là quy luật trao đổi luôn tồn tại. Nếu bạn không thể đầu tư bằng rất nhiều tiền của như người khác, bạn bắt buộc phải đầu tư bằng công sức và thời gian. Tiền bạc giúp rút ngắn chặng đường, nhưng sự kiên trì và kỷ luật cùng với sự toàn tâm mới là thứ có thể giúp bạn đạt được điều bạn muốn. Nếu thực sự muốn viết lại quy luật của chính mình, bạn phải bắt đầu thay đổi hành vi ngay từ hôm nay qua bốn bước chuyển biến rõ rệt. Đầu tiên, hãy phác thảo một hình mẫu cực kỳ cụ thể về phiên bản bạn muốn trở thành thay vì những ước muốn mơ hồ như "giỏi tiếng Anh" hay "có nhiều tiền". Hãy hình dung rõ bạn của phiên bản tưởng tượng đó làm công việc gì, giao tiếp ra sao và đối mặt với áp lực bằng thái độ thế nào. Tiếp theo, hãy biến mục tiêu khổng lồ đó thành một bài toán vận hành bằng cách xẻ nhỏ nó thành từng cột mốc theo năm, tháng, tuần và khép lại bằng những công việc cần hoàn thành mỗi ngày để tránh cảm giác bị ngợp. Khi đã có lộ trình, hãy dồn toàn bộ năng lượng để tập trung tuyệt đối vào hành động, ngừng tiêu thụ nội dung vô bổ của người khác cũng như ngừng than vãn về xuất phát điểm để hoàn thành trọn vẹn từng checklist nhỏ đã đề ra. Cuối cùng, hãy kiên trì theo đuổi mục tiêu trong âm thầm, bởi sự bứt phá chưa bao giờ đến sau một đêm mà là quả ngọt của vô số hành động đúng đắn được lặp đi lặp lại bền bỉ. Đừng kỳ vọng mọi thứ sẽ diễn ra tuyệt đối như những gì bạn đề ra, vì điều đó không xảy ra đâu. Mọi thứ đều có sai số, kế hoạch của bạn sẽ có những điều phi lý, hay có một biến số nào đó xuất hiện và làm mọi thứ rối tung. Nhưng không sao, chỉ cần bạn hành động, xem xét lại và sửa chữa, bạn sẽ tiến lên. ## Tự Viết Lại Kịch Bản Cho Chính Mình Nhưng lý thuyết thì lúc nào cũng đẹp đẽ, còn thực tế lại là một cuộc vật lộn âm thầm mỗi ngày. Bản thân tôi phải thú nhận rằng, việc chống chọi lại những cơn nghiện mạng xã hội hay thói quen trì hoãn chưa bao giờ là điều dễ dàng. Những tiếng chuông thông báo, những video ngắn cuốn hút vẫn luôn ở đó, sẵn sàng kéo tôi rời xa mục tiêu bất cứ lúc nào. Thay vì cố gắng đối đầu trực diện hay ép mình vào một kỷ luật thép phi thực tế, tôi chọn cách thỏa hiệp một cách thông minh với chính mình. Tôi tập trung giải quyết việc khó nhất và quan trọng nhất ngay vào đầu ngày. Đối với tôi, chiến thắng được buổi sáng đồng nghĩa với việc đã cầm chắc chiến thắng cho cả ngày hôm đó. Để rồi trong khoảng thời gian còn lại, nếu bản thân có lỡ sao nhãng hay lướt điện thoại một chút, tôi cũng không còn bị dằn dằn dội bởi cảm giác tội lỗi Chấp nhận những ngày mình không hoàn thành mục tiêu. Cuộc sống đôi khi có nhiều biến số mà ta không tài nào kiểm soát được, tôi cũng sẽ không tránh được những ngày buồn hay downmood, cả ngày vật vờ không làm được gì cả. Chấp nhận những khoảnh khắc yếu đuối của bản thân và khắc phục nó, bước tiếp. Hy vọng một ngày tôi sẽ được sống với hình ảnh mà tôi luôn hằng mong ước. 16:T799,Chúng ta đang quá tham lam Mạng xã hội ngày nay dựng lên những khung cảnh quá hoàn hảo: một đứa trẻ phát âm tiếng Anh chuẩn bản xứ, những người trẻ chưa đầy ba mươi đã sở hữu nhà riêng, xe sang hay tự do tài chính. Chúng ta lướt qua những lát cắt ấy mỗi ngày và vô tình rơi vào một cái bẫy tâm lý nguy hiểm: nhìn vào kết quả của người khác và gán nó làm tiêu chuẩn cho bản thân. Nhưng sự thật là, những gì bạn thấy chưa chắc đã là 100% sự thật, có những bí mật đằng sau mà bạn chưa nhìn rõ, mọi trạng thái ở hiện tại đều có nguyên do của nó. Đằng sau một đứa trẻ nói tiếng Anh lưu khoát có thể là một gia đình có điều kiện, được đầu tư học trường quốc tế và tiếp xúc với ngoại ngữ từ lúc còn chưa sõi tiếng mẹ đẻ. Đằng sau một sự thành công sớm là những nguồn lực ngầm về tài chính, mối quan hệ hoặc xuất phát điểm vượt trội. Tất nhiên vẫn sẽ tồn tại vài trường hợp xuất chúng, nhưng tỷ lệ là dưới 1%. Bạn cảm giác ghen tị với thành công của họ. Nhưng hành động của bạn là dành hàng giờ đồng hồ mỗi ngày chỉ để tiêu thụ nội dung và tiếp tục than vãn về cuộc sống hiện tại. Đợt rồi tôi có dịp được gặp lại những người bạn cũ thời cấp 3, cuộc trò chuyện đang rất vui vẻ thì đột nhiên có đứa bảo, "Chán quá tụi bây, tao làm ở chỗ đó mấy năm rồi mà chả thấy lên lương gì nhiều". Tôi mới hỏi lại nó là vậy công việc mày dạo này khó hơn trước à. Thì nó bảo, đâu vẫn thế thôi, mà tao làm được 4 năm rồi. Đoạn này tôi nghĩ thầm trong bụng thôi chứ17:T1616, ## Bước đi chập chững từ các công ty khởi nghiệp Tôi có nhiều năm làm việc với các công ty start up và may mắn được cọ xát với nhiều công nghệ mới, được nhúng tay khá sâu vào các dự án, như là trực tiếp sửa đổi / thiết kế lại hệ thống database của một ứng dụng đang chạy production và kết quả được cải thiện tương đối chỉ với vài kỹ năng cơ bản về Index và partitioning. Các bạn nghe mọi thứ như đang tiến triển rất tốt đúng không. Tuy nhiên, có một điều mà tôi băn khoăn mãi, nếu so thông số ở dạng tỷ lệ thì rất tốt, performance tăng nhanh hẳn 50%, nhưng tổng số users dùng các sản phẩm mà công ty tôi làm ra, dưới 1000 người. Hay 1 dự án blockchain, anh PM và Tech Lead của tôi luôn cố gắng tìm cách cải thiện cơ chế đồng thuận (consensus) để nâng cao tốc độ xử lý và có thể xử lý nhiều giao dịch hơn trong một giây; và cũng giống như dự án trước, số users sử dụng nền tảng của chúng tôi… không nhiều đến thế. Trong thâm tâm tôi luôn cảm thấy, việc nên ưu tiên trong giai đoạn này, là tập trung vào việc làm sao tăng được users, còn việc cải thiện performance trên một tập người dùng nhỏ, chỉ có giá trị trên mặt giấy tờ. Bản thân tôi cũng muốn ứng dụng của mình chạy mượt, đem lại trải nghiệm tốt cho người dùng chứ, nhưng mà một ứng dụng là công sức của một tập thể, có nhiều biến số mà tôi không thể kiểm soát được. Người dùng sản phẩm thì cạn dần, và khi doanh thu không đáp ứng được, kết quả là chả còn dự án nào tồn tại đến hiện tại. Khi dự án sập, tôi cảm giác như công sức trước đó của mình không mang lại nhiều ý nghĩa lắm ngoài việc hết tháng nhận tiền lương. ## Sự phát triển của AI và nhìn nhận thực tế của ngành Cùng với sự phát triển chóng mặt của AI, các kỹ năng tối ưu Database của tôi, thứ tôi luôn tự hào, giờ đây chỉ cần vài câu prompt, nó đã có thể hiểu rõ các liên kết trong database và đưa ra phương án tối ưu khá chính xác. Có 1 kỷ niệm khá vui mà AI tí nữa đã phá hỏng dự án lúc đó tôi đang làm, anh tech-lead hí hửng khoe với tôi là dùng AI đánh được index đầy đủ luôn, đến khi tôi check qua thì thấy 1 lỗi cực kỳ lớn, vì chỉ muốn tối ưu tốc độ đọc, AI đã tạo tới 7 index trên cùng một bảng. Tốc độ đọc nhanh hơn thật, nhưng giá phải trả là thời gian ghi bị chậm đi gấp 3–4 lần. Tôi vẫn rất ngưỡng mộ kiến thức của anh Tech Lead, tuy nhiên đâu có ai mà giỏi hết mọi mặt, cái mà tôi muốn nói ở đây là, do tôi có kiến thức về Database, tôi mới nhận ra vấn đề ở đó; để một ứng dụng được hình thành, thì cần nhiều kiến thức ở nhiều mảng, vậy câu hỏi là AI còn để lại ‘rác’ ở chỗ nào mà mình chưa nhận ra không, Đó chính là lúc nợ kỹ thuật (technical debt) xuất hiện. Một khi sự cố xảy ra mà không ai thật sự hiểu bản chất, đó sẽ là chuỗi ngày fix bug vô tận. Về ngách Software Engineer, cá nhân tôi thấy nhu cầu trên thị trường không còn nhiều nữa, vì bây giờ ai cũng có thể vibe code ra được một ứng dụng phục vụ được cho nhu cầu cá nhân của họ. Các kiến thức khó nhất khi làm software engineer là bảo mật, xử lý lượng đồng thời cao, hay tính nguyên tử của dữ liệu… bây giờ trở nên vô nghĩa khi họ chỉ dùng ứng dụng để phục vụ nhu cầu cá nhân, tôi đùa là họ có lưu trữ dữ liệu ở local storage đi chăng nữa cũng chả sao. ## Đi Tìm Bài Toán Ở Quy mô doanh nghiệp Khi tìm hiểu thì tôi biết được SAP vẫn tồn tại và giữ vị thế số 1 trong thị trường phần mềm quản trị doanh nghiệp (ERP) nhờ vào việc giải quyết bài toán phức tạp nhất của các tập đoàn lớn, kết nối, đồng bộ các quy trình vận hành, thứ mà tôi chưa được trải nghiệm ở các công ty start up trước đó. Các khách hàng đang sử dụng SAP là những cái tên mà nói ra ai cũng từng sử dụng sản phẩm của họ hoặc ít nhất là đã nghe qua: PepsiCo, Samsung, LG, Toyota,… vâng, rất nhiều công ty nằm trong S&P 500. Họ vẫn sẽ dùng SAP vì chi phí chuyển đổi hệ thống là cực kỳ khổng lồ. Làm việc với SAP, tôi không chỉ làm việc kỹ thuật khô khan, mà ở đấy tôi có cơ hội hiểu hơn về nghiệp vụ, về các quy trình chuẩn quốc tế tối ưu trong tài chính, chuỗi cung ứng, sản xuất đã được đóng gói sẵn, giúp các doanh nghiệp áp dụng ngay tiêu chuẩn của các tập đoàn hàng đầu thế giới. Đồng thời, nền tảng kỹ thuật trước đó giúp tôi tiếp thu domain mới rất nhanh: không mất nhiều thời gian để hiểu về CSDL HANA, CDS Views hay xây dựng ứng dụng chuẩn RESTful (RAP). [Đọc tiếp: Chương 2. Đặt nền móng →](/blog/sap-foundation) 18:T7c6,Bước đi chập chững từ các công ty khởi nghiệp Tôi có nhiều năm làm việc với các công ty start up và may mắn được cọ xát với nhiều công nghệ mới, được nhúng tay khá sâu vào các dự án, như là trực tiếp sửa đổi / thiết kế lại hệ thống database của một ứng dụng đang chạy production và kết quả được cải thiện tương đối chỉ với vài kỹ năng cơ bản về Index và partitioning. Các bạn nghe mọi thứ như đang tiến triển rất tốt đúng không. Tuy nhiên, có một điều mà tôi băn khoăn mãi, nếu so thông số ở dạng tỷ lệ thì rất tốt, performance tăng nhanh hẳn 50%, nhưng tổng số users dùng các sản phẩm mà công ty tôi làm ra, dưới 1000 người. Hay 1 dự án blockchain, anh PM và Tech Lead của tôi luôn cố gắng tìm cách cải thiện cơ chế đồng thuận (consensus) để nâng cao tốc độ xử lý và có thể xử lý nhiều giao dịch hơn trong một giây; và cũng giống như dự án trước, số users sử dụng nền tảng của chúng tôi… không nhiều đến thế. Trong thâm tâm tôi luôn cảm thấy, việc nên ưu tiên trong giai đoạn này, là tập trung vào việc làm sao tăng được users, còn việc cải thiện performance trên một tập người dùng nhỏ, chỉ có giá trị trên mặt giấy tờ. Bản thân tôi cũng muốn ứng dụng của mình chạy mượt, đem lại trải nghiệm tốt cho người dùng chứ, nhưng mà một ứng dụng là công sức của một tập thể, có nhiều biến số mà tôi không thể kiểm soát được. Người dùng sản phẩm thì cạn dần, và khi doanh thu không đáp ứng được, kết quả là chả còn dự án nào tồn tại đến hiện tại. Khi dự án sập, tôi cảm giác như công sức trước đó của mình không19:T205d, ## Tư duy và phương pháp dẫn đường Một hành trình hiệu quả không thể bắt đầu bằng sự cảm tính. Đề hành trình học tập của tôi trở nên rõ ràng và hiệu quả, không thể một mình tay không bắt giặc được, thứ tôi cần là một kế hoạch, một phương pháp và tư duy học tập đúng đắn. Tất nhiên là tôi sẽ không kỳ vọng mình sẽ đi đúng hướng ngay từ ban đầu. Tuy nhiên, tôi sẽ không cải thiện được nhiều nếu không có một thước đo thật sự là rõ ràng. ### Sử dụng lợi thế từ những gì sẵn có: Áp dụng tư duy của một Software Engineer, tôi biến việc học thành một "pipeline" tự động. Thay vì đọc hàng trăm tài liệu khô khan và cực khó nuốt. Tôi dùng AI để tóm tắt các khái niệm cốt lõi, phân tích từ các case study và tạo kịch bản thực hành các tình huống. Hệ thống cũng tạo ra các tài liệu dành cho việc ôn tập, tạo ra câu hỏi bắt buộc não phải chủ động truy xuất kiến thức, đánh giá lại hiệu quả và nhắc nhở ôn tập theo chu kỳ thời gian tối ưu. Bắt chước thay vì cố gắng sáng tạo ra một cái gì mới. Bây giờ trên Github có sẵn nhiều example mà tôi có thể làm theo, trước khi sáng tạo ra cái của riêng mình thì tôi phải trải qua giai đoạn học, hiểu, có thể giải thích và làm theo đã. ### Chiến lược thực chiến để sẵn sàng cho dự án Chấp nhận sự mơ hồ ban đầu, không hoảng sợ trước những thiết lập phức tạp hay lỗi hệ thống ban đầu; học cách sống chung và gỡ rối từng bước. Thay vì học vẹt các Transaction codes hay ý nghĩa từng fields trong bảng, tôi tiếp cận bằng cách luồng nghiệp vụ vào bài toán, phân tích một chuỗi End-to-End gồm những bước gì và triển khai hệ thống ra sao. **Quy tắc 80/20:** Thay vì cố gắng hiểu hết mọi thứ, tôi sẽ tập trung làm chủ 20% kiến thức nền tảng, nền móng vững chắc sẽ giúp tôi tự tin và có thể dễ dàng hơn trong việc tìm hiểu một kiến thức mới nằm trong 80% còn lại. Lý thuyết suông chỉ mang lại cảm giác hiểu giả tạo. Chả ai biết cách đi xe máy bằng cách xem Youtube cả. Việc bắt tay vào làm trực tiếp, hệ thống báo lỗi và tự tra cứu lỗi để sửa. Tôi đặt niềm tin tuyệt đối vào vòng lặp: Làm → Sửa sai → Cải thiện. Đây là con đường ngắn nhất để thẩm thấu kiến thức. Đối với SAP, thời gian đầu tôi sẽ tìm hiểu các syntax của ABAP, những tư duy, khác biệt so với ngôn ngữ lập trình khác, khi đã nắm được cách nó hoạt động, tôi sẽ dần chuyển mình sang học những concept, chương trình mới hơn như là RAP. ## Kiến trúc hệ thống: Giải mã ERP và các mảnh ghép trong SAP ### Về khái niệm ERP: Trong một doanh nghiệp tồn tại rất nhiều phòng ban làm việc với nhau. Mỗi phòng ban sử dụng một phần mềm riêng lẻ như bộ phận kho bãi dùng Excel để ghi chép, bộ phận bán hàng dùng một phần mềm CRM độc lập. Điều này dẫn đến việc dữ liệu bị phân tán, và mất nhiều thời gian, công sức đối soát để đảm bảo tính đúng đắn. _ERP (Enterprise Resource Planning - hệ thống quản trị_ nguồn lực doanh nghiệp). Đây là khái niệm chỉ rõ phần mềm vận hành, quản lý doanh nghiệp, đóng vai trò là một bộ não trung tâm, thu gom, chia sẻ dữ liệu tập trung trên một hệ thống duy nhất. Đảm bảo tính đồng nhất và chuẩn hoá dữ liệu giữa nhiều bộ phận trong cùng một doanh nghiệp. ### SAP - cái tên nổi bật nhất thế giới ERP ERP là tên gọi chung cho dòng giải pháp của doanh nghiệp, **SAP** (Systems, Applications, and Products in Data Processing) là đại diện lớn nhất trong thị trường này. Công ty Đức được thành lập 1972 và là một trong những công ty phần mềm lớn nhất thế giới. Sức mạnh của SAP không chỉ nằm ở công cụ phần mềm, mà là các quy chuẩn đã được đúc kết từ hàng vạn doanh nghiệp lớn nhất thế giới. Điểm đặc trưng của SAP là **tính chặt chẽ và tích hợp cực cao**: Mọi hành động diễn ra ở một khâu đều kéo theo các bút toán hoặc luồng dữ liệu tự động ở các khâu khác, giúp doanh nghiệp kiểm soát rủi ro gần như tuyệt đối. ### Các mảnh ghép cốt lõi: Hệ sinh thái Module trong SAP Để quản lý toàn bộ một tập đoàn phức tạp, SAP chia nhỏ hệ thống thành các **Module (Phân hệ)** đảm nhận từng nghiệp vụ chuyên biệt, nhưng tất cả đều kết nối khăng khít với nhau: ### Quản trị Tài chính & Kiểm soát (Finance & Controlling): - **FI (Financial Accounting):** Quản lý sổ cái, công nợ phải thu/phải trả, tài sản cố định và lập báo cáo tài chính chuẩn mực. - **CO (Controlling):** Quản lý chi phí nội bộ, tính giá thành sản phẩm và phân tích lợi nhuận. ### Chuỗi cung ứng & Vận hành (Supply Chain & Logistics): - **MM (Materials Management):** Quản lý Mua hàng (Procurement), định mức tồn kho và Nhập/Xuất/Kiểm kê Kho. - **SD (Sales and Distribution):** Quản lý Bán hàng, từ báo giá, đơn đặt hàng (Sales Order), giao hàng đến xuất hóa đơn cho khách. **PP (Production Planning):** Quản lý lập kế hoạch và điều độ sản xuất, định mức nguyên vật liệu (BOM). ### Quản lý Tài sản & Chất lượng (Asset & Quality): - **PM (Plant Maintenance):** Quản lý bảo trì, bảo dưỡng máy móc thiết bị nhà xưởng. - **QM (Quality Management):** Kiểm tra và quản lý chất lượng nguyên vật liệu đầu vào cũng như thành phẩm. ### Quản trị Nhân sự (Human Capital Management): - **HCM / SuccessFactors:** Quản lý sơ đồ tổ chức, chấm công, tính lương và tuyển dụng/đào tạo. ### Tập trung vào một mũi nhọn: tôi chọn bắt đầu SD Một lý do đơn giản khiến tôi chọn SD là vì tôi thấy nó gần gũi và những khái niệm khá gần với thực tế. Ai trong chúng ta cũng từng đóng vai là người mua hàng hoặc từng bán một cái gì đó (là sản phẩm hay kể cả là sức lao động). SD không đơn thuần là phân hệ quản lý bán hàng, mà nó chính là doanh thu của toàn bộ doanh nghiệp, nơi kết nối trực tiếp với thị trường, khách hàng và dòng tiền. Phân hệ này gồm nghiệp vụ end-to-end cực kỳ sống động vì nó bao phủ trọn vẹn hành trình từ báo giá đến khâu xuất hoá đơn, và cũng dễ mở rộng khi đây là điểm giao thao cực mạnh với các phân hệ khác: làm việc với MM ở quản lý tồn kho hay FI ngay thời điểm hóa đơn doanh thu được ghi nhận. **Định hướng chặng đường** Khép lại những trang lý thuyết ban đầu. Tôi nhận ra SAP không chỉ là một phần mềm khô khan, nó chính là xương sống vận hành, dòng chảy kết nối các nguồn lực giúp một doanh nghiệp tồn tại và vận hành trơn tru. Để làm chủ một hệ thống đồ sộ như SAP, không có lối tắt nào ngoài việc bắt đầu từ những bước đi nhỏ nhất. Hiểu một phần tư duy nghiệp vụ chỉ là bước đầu, hành trình tiếp theo sẽ là trực tiếp thao tác trên hệ thống, tôi sẽ bắt đầu bằng việc khám phá các kỹ thuật cơ bản trong SAP ABAP. [Đọc tiếp: Chương 3. Hiểu rõ hơn về các khái niệm trong SAP →](/blog/sap-concepts) 1a:T7c1,Tư duy và phương pháp dẫn đường Một hành trình hiệu quả không thể bắt đầu bằng sự cảm tính. Đề hành trình học tập của tôi trở nên rõ ràng và hiệu quả, không thể một mình tay không bắt giặc được, thứ tôi cần là một kế hoạch, một phương pháp và tư duy học tập đúng đắn. Tất nhiên là tôi sẽ không kỳ vọng mình sẽ đi đúng hướng ngay từ ban đầu. Tuy nhiên, tôi sẽ không cải thiện được nhiều nếu không có một thước đo thật sự là rõ ràng. Sử dụng lợi thế từ những gì sẵn có: Áp dụng tư duy của một Software Engineer, tôi biến việc học thành một "pipeline" tự động. Thay vì đọc hàng trăm tài liệu khô khan và cực khó nuốt. Tôi dùng AI để tóm tắt các khái niệm cốt lõi, phân tích từ các case study và tạo kịch bản thực hành các tình huống. Hệ thống cũng tạo ra các tài liệu dành cho việc ôn tập, tạo ra câu hỏi bắt buộc não phải chủ động truy xuất kiến thức, đánh giá lại hiệu quả và nhắc nhở ôn tập theo chu kỳ thời gian tối ưu. Bắt chước thay vì cố gắng sáng tạo ra một cái gì mới. Bây giờ trên Github có sẵn nhiều example mà tôi có thể làm theo, trước khi sáng tạo ra cái của riêng mình thì tôi phải trải qua giai đoạn học, hiểu, có thể giải thích và làm theo đã. Chiến lược thực chiến để sẵn sàng cho dự án Chấp nhận sự mơ hồ ban đầu, không hoảng sợ trước những thiết lập phức tạp hay lỗi hệ thống ban đầu; học cách sống chung và gỡ rối từng bước. Thay vì học vẹt các Transaction codes hay ý nghĩa từng fields trong bảng, tôi tiếp cận bằng cách luồng nghiệp vụ vào bài toán, phân tích một chuỗi End-to-End1b:T713,## Tư duy và phương pháp dẫn đường Một hành trình hiệu quả không thể bắt đầu bằng sự cảm tính. Đề hành trình học tập của tôi trở nên rõ ràng và hiệu quả, không thể một mình tay không bắt giặc được, thứ tôi cần là một kế hoạch, một phương pháp và tư duy học tập đúng đắn. Tất nhiên là tôi sẽ không kỳ vọng mình sẽ đi đúng hướng ngay từ ban đầu. Tuy nhiên, tôi sẽ không cải thiện được nhiều nếu không có một thước đo thật sự là rõ ràng. ### Sử dụng lợi thế từ những gì sẵn có: Áp dụng tư duy của một Software Engineer, tôi biến việc học thành một "pipeline" tự động. Thay vì đọc hàng trăm tài liệu khô khan và cực khó nuốt. Tôi dùng AI để tóm tắt các khái niệm cốt lõi, phân tích từ các case study và tạo kịch bản thực hành các tình huống. Hệ thống cũng tạo ra các tài liệu dành cho việc ôn tập, tạo ra câu hỏi bắt buộc não phải chủ động truy xuất kiến thức, đánh giá lại hiệu quả và nhắc nhở ôn tập theo chu kỳ thời gian tối ưu. Bắt chước thay vì cố gắng sáng tạo ra một cái gì mới. Bây giờ trên Github có sẵn nhiều example mà tôi có thể làm theo, trước khi sáng tạo ra cái của riêng mình thì tôi phải trải qua giai đoạn học, hiểu, có thể giải thích và làm theo đã. ### Chiến lược thực chiến để sẵn sàng cho dự án Chấp nhận sự mơ hồ ban đầu, không hoảng sợ trước những thiết lập phức tạp hay lỗi hệ thống ban đầu; học cách sống chung và gỡ rối từng bước.1c:T112d, ## Các tính năng nội bật của SAP - **Tính tích hợp (Integration):** Cho phép tất cả các phòng ban/chức năng dùng chung một hệ thống và chia sẻ chung dữ liệu. - **Đa ngôn ngữ (Multilingual):** Hỗ trợ hơn 40 ngôn ngữ (Anh, Đức, Thái, Trung...) giúp xóa bỏ rào cản ngôn ngữ. - **Cơ chế cấp phép dựa trên người dùng (User-based License Agreement):** Bắt buộc phải có tài khoản (Username/Password) được xác thực từ SAP Server mới có thể đăng nhập, giúp bảo mật dữ liệu và phân quyền chặt chẽ. ## Nền tảng công nghệ, ngôn ngữ & phân hệ - **SAP NetWeaver:** Là nền tảng công nghệ đóng vai trò như môi trường thực thi (_Runtime Environment_) cho toàn bộ hệ sinh thái ứng dụng của SAP (như SAP ERP, SAP CRM, SAP SRM, SAP PI). - **Ngôn ngữ ABAP:** Viết tắt của _Advanced Business Application Programming_ (hiện phổ biến là thế hệ thứ 4 - ABAP/4). Đây là ngôn ngữ lập trình riêng của SAP, nằm tại tầng Application Layer. - **Các phân hệ (Modules) trong SAP:** - _Functional Modules (Phân hệ nghiệp vụ):_ Gồm các module con như **SD** (Bán hàng & Phân phối), **MM** (Quản lý vật tư), **FI** (Tài chính).... - _Technical Modules (Phân hệ kỹ thuật):_ Gồm **SAP ABAP** (Lập trình), **SAP BI/BO** (Phục vụ làm báo cáo) và **SAP Basis**. - _SAP Basis:_ Đảm nhận vai trò quản trị, giám sát hệ thống 24/7, duy trì hệ thống không bị sự cố/crash và quản lý cấp quyền (User ID, password) ## Kiến trúc 3 lớp tổng quan (SAP R/3 Architecture) ![[../images/3-architecture.png]] 1. **Presentation Layer:** Tầng giao diện người dùng (tương tác trực tiếp qua SAP GUI). 2. **Application Layer:** Tầng ứng dụng/phát triển, chứa các chương trình lập trình bằng ABAP để xử lý logic. 3. **Database Layer:** Tầng cơ sở dữ liệu lưu trữ và truy xuất toàn bộ thông tin hệ thống. ![[../images/application-server-components.png]] 1. **Dispatcher (Bộ điều phối):** - Mọi yêu cầu (_input request_) gửi từ người dùng ở tầng Presentation Layer đều sẽ đi vào **Dispatcher** đầu tiên. - Dispatcher không trực tiếp xử lý ngay request mà đẩy toàn bộ vào một hàng chờ (**Queue**). 2. **Queue (Hàng chờ):** - Lưu giữ các request và sắp xếp thứ tự xử lý theo cơ chế **FIFO** (_First-In, First-Out_ - yêu cầu nào đến trước sẽ được lấy ra xử lý trước). 3. **Work Process (Tiến trình xử lý):** - Dispatcher sẽ lấy từng request từ Queue ra và gán cho một **Work Process** để thực thi. - **Nguyên tắc đơn nhiệm:** Một Work Process chỉ xử lý **duy nhất 1 request tại một thời điểm**. Nếu có nhiều yêu cầu, hệ thống phải xếp hàng xử lý tuần tự (đây là lý do khiến màn hình SAP GUI đôi khi bị xoay/loading lâu khi gặp chương trình nặng). 4. **Hai vùng bộ nhớ đệm quan trọng trong Work Process:** - **User Context:** Là vùng bộ nhớ đệm lưu trữ thông tin về người dùng đang làm việc (User ID, mật khẩu, thời gian đăng nhập, chương trình đang chạy, số lượng cửa sổ đang mở). Vùng bộ nhớ này chỉ tự động giải phóng khi người dùng **Thoát/Log out** khỏi tài khoản SAP. - **Roll Area:** Là vùng bộ nhớ đệm nhỏ dành riêng cho việc thực thi chương trình. Khi chương trình ABAP bắt đầu chạy, Roll Area được cấp phát để lưu trữ dữ liệu tính toán tạm thời và sẽ **giải phóng ngay lập tức** khi chương trình kết thúc. ### Quy trình xử lý hoàn chỉnh của một Request: **Presentation Layer** _(Gửi request)_ $\rightarrow$ **Dispatcher** $\rightarrow$ **Queue (FIFO)** $\rightarrow$ **Work Process** _(Xử lý kết hợp với_ **User Context** _&_ **Roll Area**_)_ $\leftrightarrow$ **Database Layer** _(Truy xuất/Lưu data)_ $\rightarrow$ Trả kết quả ngược lại **Presentation Layer** [Đọc tiếp: Chương 4. ABAP Fundamentals: Bước Chân Vào Tầng Xử Lý Logic →](/blog/sap-abap) 1d:T843,Các tính năng nội bật của SAP - Tính tích hợp (Integration): Cho phép tất cả các phòng ban/chức năng dùng chung một hệ thống và chia sẻ chung dữ liệu. - Đa ngôn ngữ (Multilingual): Hỗ trợ hơn 40 ngôn ngữ (Anh, Đức, Thái, Trung...) giúp xóa bỏ rào cản ngôn ngữ. - Cơ chế cấp phép dựa trên người dùng (User-based License Agreement): Bắt buộc phải có tài khoản (Username/Password) được xác thực từ SAP Server mới có thể đăng nhập, giúp bảo mật dữ liệu và phân quyền chặt chẽ. Nền tảng công nghệ, ngôn ngữ & phân hệ - SAP NetWeaver: Là nền tảng công nghệ đóng vai trò như môi trường thực thi (Runtime Environment) cho toàn bộ hệ sinh thái ứng dụng của SAP (như SAP ERP, SAP CRM, SAP SRM, SAP PI). - Ngôn ngữ ABAP: Viết tắt của Advanced Business Application Programming (hiện phổ biến là thế hệ thứ 4 - ABAP/4). Đây là ngôn ngữ lập trình riêng của SAP, nằm tại tầng Application Layer. - Các phân hệ (Modules) trong SAP: - Functional Modules (Phân hệ nghiệp vụ): Gồm các module con như SD (Bán hàng & Phân phối), MM (Quản lý vật tư), FI (Tài chính).... - Technical Modules (Phân hệ kỹ thuật): Gồm SAP ABAP (Lập trình), SAP BI/BO (Phục vụ làm báo cáo) và SAP Basis. - SAP Basis: Đảm nhận vai trò quản trị, giám sát hệ thống 24/7, duy trì hệ thống không bị sự cố/crash và quản lý cấp quyền (User ID, password) Kiến trúc 3 lớp tổng quan (SAP R/3 Architecture) ![[../images/3-architecture.png]] 1. Presentation Layer: Tầng giao diện người dùng (tương tác trực tiếp qua SAP GUI). 2. Application Layer: Tầng ứng dụng/phát triển, chứa các chương trình lập trình bằng ABAP để xử lý logic. 3. Database Layer: Tầng cơ sở dữ liệu lưu trữ và truy xuất toàn bộ thông tin hệ thống. ![[../images/application-server-components.png]] 1. Dispatcher (Bộ điều phối): - Mọi1e:T872,## Các tính năng nội bật của SAP - **Tính tích hợp (Integration):** Cho phép tất cả các phòng ban/chức năng dùng chung một hệ thống và chia sẻ chung dữ liệu. - **Đa ngôn ngữ (Multilingual):** Hỗ trợ hơn 40 ngôn ngữ (Anh, Đức, Thái, Trung...) giúp xóa bỏ rào cản ngôn ngữ. - **Cơ chế cấp phép dựa trên người dùng (User-based License Agreement):** Bắt buộc phải có tài khoản (Username/Password) được xác thực từ SAP Server mới có thể đăng nhập, giúp bảo mật dữ liệu và phân quyền chặt chẽ. ## Nền tảng công nghệ, ngôn ngữ & phân hệ - **SAP NetWeaver:** Là nền tảng công nghệ đóng vai trò như môi trường thực thi (_Runtime Environment_) cho toàn bộ hệ sinh thái ứng dụng của SAP (như SAP ERP, SAP CRM, SAP SRM, SAP PI). - **Ngôn ngữ ABAP:** Viết tắt của _Advanced Business Application Programming_ (hiện phổ biến là thế hệ thứ 4 - ABAP/4). Đây là ngôn ngữ lập trình riêng của SAP, nằm tại tầng Application Layer. - **Các phân hệ (Modules) trong SAP:** - _Functional Modules (Phân hệ nghiệp vụ):_ Gồm các module con như **SD** (Bán hàng & Phân phối), **MM** (Quản lý vật tư), **FI** (Tài chính).... - _Technical Modules (Phân hệ kỹ thuật):_ Gồm **SAP ABAP** (Lập trình), **SAP BI/BO** (Phục vụ làm báo cáo) và **SAP Basis**. - _SAP Basis:_ Đảm nhận vai trò quản trị, giám sát hệ thống 24/7, duy trì hệ thống không bị sự cố/crash và quản lý cấp quyền (User ID, password) ## Kiến trúc 3 lớp tổng quan (SAP R/3 Architecture) ![[../images/3-architecture.png]] 1. **Presentation Layer:** Tầng giao diện người dùng (tương tác trực tiếp qua SAP GUI). 2. **Application Layer:** Tầng ứng dụng/phát triển, chứa các chương trình lập trình bằng ABAP để xử lý logic. 3. **Database Layer:** Tầng cơ sở dữ liệu lưu trữ và truy xuất toàn bộ thông tin hệ thống. ![[../images/application-server-components.png]]1f:T713, Hiện tại SAP đang đẩy mạnh xu hướng hiện đại hóa với nền tảng Cloud, kiến trúc RESTful (RAP) và các ngôn ngữ như JavaScript, nhưng việc học ABAP ở thời điểm hiện tại vẫn còn nguyên giá trị. Đây là ngôn ngữ gốc ở tầng Core Backend trong SAP, các logic nghiệp vụ phức tạp trong hệ thống đều đã được viết và tối ưu bằng ABAP qua nhiều năm. Để tuỳ biến, vận hành hay mở rộng tính năng cho hệ thống, việc đọc hiểu các codebase cũ là không thể bỏ qua. Việc đập đi làm lại hoặc chuyển toàn bộ code lõi sang ngôn ngữ khác là bài toán vô cùng rủi ro và tốn kém hàng triệu USD. Do đó, nhu cầu duy trì, chuyển đổi hệ thống cũ (Legacy) sang SAP S/4HANA vẫn tạo ra nguồn cầu nhân lực ABAP cực kỳ ổn định. Về tài liệu chính thức, các bạn có thể xem tài liệu gốc của SAP: https://learning.sap.com/courses/learn-the-basics-of-abap-programming-on-sap-btp/introducing-abap-syntax_b815682e-9a5e-4372-a021-66ea71208746 Ở bài viết này, tôi sẽ viết như một bảng tổng hợp nhanh lại kiến thức. ### ABAP Basic Statements [Đọc tiếp: ABAP Basic Statements →](/blog/sap-abap-1) ### ABAP Data Dictionary [Đọc tiếp: ABAP Data Dictionary →](/blog/sap-abap-2) ### ABAP Open SQL [Đọc tiếp: ABAP Open SQL →](/blog/sap-abap-3) ### ABAP Internal Table [Đọc tiếp: ABAP Internal Table →](/blog/sap-abap-4) ### ABAP Modularization [Đọc tiếp: ABAP Modularization →](/blog/sap-abap-5) ### ABAP Classical Report [Đọc tiếp: ABAP Classical Report →](/blog/sap-abap-6) ### ABAP ALV Report [Đọc tiếp: ABAP ALV Report →](/blog/sap-abap-7) 20:T659,Hiện tại SAP đang đẩy mạnh xu hướng hiện đại hóa với nền tảng Cloud, kiến trúc RESTful (RAP) và các ngôn ngữ như JavaScript, nhưng việc học ABAP ở thời điểm hiện tại vẫn còn nguyên giá trị. Đây là ngôn ngữ gốc ở tầng Core Backend trong SAP, các logic nghiệp vụ phức tạp trong hệ thống đều đã được viết và tối ưu bằng ABAP qua nhiều năm. Để tuỳ biến, vận hành hay mở rộng tính năng cho hệ thống, việc đọc hiểu các codebase cũ là không thể bỏ qua. Việc đập đi làm lại hoặc chuyển toàn bộ code lõi sang ngôn ngữ khác là bài toán vô cùng rủi ro và tốn kém hàng triệu USD. Do đó, nhu cầu duy trì, chuyển đổi hệ thống cũ (Legacy) sang SAP S/4HANA vẫn tạo ra nguồn cầu nhân lực ABAP cực kỳ ổn định. Về tài liệu chính thức, các bạn có thể xem tài liệu gốc của SAP: https://learning.sap.com/courses/learn-the-basics-of-abap-programming-on-sap-btp/introducing-abap-syntaxb815682e-9a5e-4372-a021-66ea71208746 Ở bài viết này, tôi sẽ viết như một bảng tổng hợp nhanh lại kiến thức. ABAP Basic Statements Đọc tiếp: ABAP Basic Statements → ABAP Data Dictionary Đọc tiếp: ABAP Data Dictionary → ABAP Open SQL Đọc tiếp: ABAP Open SQL → ABAP Internal Table Đọc tiếp: ABAP Internal Table → ABAP Modularization Đọc tiếp: ABAP Modularization → ABAP Classical Report Đọc tiếp: ABAP Classical Report → ABAP ALV Report Đọc tiếp: ABAP ALV Report →21:T711,Hiện tại SAP đang đẩy mạnh xu hướng hiện đại hóa với nền tảng Cloud, kiến trúc RESTful (RAP) và các ngôn ngữ như JavaScript, nhưng việc học ABAP ở thời điểm hiện tại vẫn còn nguyên giá trị. Đây là ngôn ngữ gốc ở tầng Core Backend trong SAP, các logic nghiệp vụ phức tạp trong hệ thống đều đã được viết và tối ưu bằng ABAP qua nhiều năm. Để tuỳ biến, vận hành hay mở rộng tính năng cho hệ thống, việc đọc hiểu các codebase cũ là không thể bỏ qua. Việc đập đi làm lại hoặc chuyển toàn bộ code lõi sang ngôn ngữ khác là bài toán vô cùng rủi ro và tốn kém hàng triệu USD. Do đó, nhu cầu duy trì, chuyển đổi hệ thống cũ (Legacy) sang SAP S/4HANA vẫn tạo ra nguồn cầu nhân lực ABAP cực kỳ ổn định. Về tài liệu chính thức, các bạn có thể xem tài liệu gốc của SAP: https://learning.sap.com/courses/learn-the-basics-of-abap-programming-on-sap-btp/introducing-abap-syntax_b815682e-9a5e-4372-a021-66ea71208746 Ở bài viết này, tôi sẽ viết như một bảng tổng hợp nhanh lại kiến thức. ### ABAP Basic Statements [Đọc tiếp: ABAP Basic Statements →](/blog/sap-abap-1) ### ABAP Data Dictionary [Đọc tiếp: ABAP Data Dictionary →](/blog/sap-abap-2) ### ABAP Open SQL [Đọc tiếp: ABAP Open SQL →](/blog/sap-abap-3) ### ABAP Internal Table [Đọc tiếp: ABAP Internal Table →](/blog/sap-abap-4) ### ABAP Modularization [Đọc tiếp: ABAP Modularization →](/blog/sap-abap-5) ### ABAP Classical Report [Đọc tiếp: ABAP Classical Report →](/blog/sap-abap-6) ### ABAP ALV Report [Đọc tiếp: ABAP ALV Report →](/blog/sap-abap-7)22:T196f, ## ABAP Basic Statements ### 1. Basic Syntax Rules & Comments - **Statement Termination**: Every ABAP statement must end with a **period (\*\***.\***\*)**. A statement can span across multiple lines until a period is encountered. - **Case Insensitivity**: ABAP code is case-insensitive; keywords, additions, and operands can be written in uppercase or lowercase. - **Comments**: - An **asterisk** (\*) at the very first position of a line comments out the entire line. - A **double quote (\*\***"\***\*)** comments out everything from that position to the end of the line. - **Chained Statements**: Multiple statements repeating the same keyword can be chained using a **colon (\*\***:\***\*)** and separated by **commas (\*\***,\***\*)** (e.g., `WRITE: var1, var2.`). --- ### 2. Data Objects & Type Declarations - **Data Objects**: ABAP distinguishes between **Variables** (`DATA`), **Constants** (`CONSTANTS`), and **Literals** (text in `'...'`, string in `` `...` ``, or numbers). - **Variable Declaration**: Declared using `DATA TYPE ` with an optional `VALUE` addition. To copy the type of an existing data object, use `LIKE`. - **Local vs. Global Types**: - **Local Data Types** (`TYPES`): Defined locally within a program. If a local type shares the same name as a global type, the local definition takes **precedence**. - **Global Data Types**: Created and managed system-wide via the **ABAP Dictionary** (transaction code `SE11`). - **Predefined Data Types**: - **Complete Data Types** (fixed length): `D` (Date - 8 characters `YYYYMMDD`), `T` (Time - 6 characters `HHMMSS`), `I` (Integer - 4 bytes, range -2^31 to +2^31), `STRING` (dynamic character string). - **Incomplete Data Types** (length required): `C` (Character), `N` (Numeric text), and `P` (Packed number - used for calculations/currencies with `DECIMALS` specification). - **Internal Tables**: Declared using `DATA TYPE TABLE OF ` to hold lists of structured data. --- ### 3. Coding Convension - **Custom Type**: GT*, GTS*, GTT\_ - **Constant**: GC\_ - **Global variables**: GD\_ - **Work Area (Structure)**: GS\_ - **Internal Table**: GT\_ - **Local variables**: LD\_ - **Local work area**: LS\_ - **Local internal table**: LT\_ - **Selection-screen Parameter**: P\_ - **Selection-screen Select-option**: S\_ - **Selection-screen Radio Button**: RB\_ - **Selection-screen Checkbox**: CB\_ - **Subroutines (Procedure)**: GET_DATA, SET_DATA - **Global class**: ZCL, YCL - **Local class**: LCL - **Class instance (object)**: O, LO - **Class methods**: GET_DATA, SET_DATA - **Class attributes**: no prefix --- ### 4. Control Structures & Loops - **Conditional Branching (IF)**: Implemented using `IF ... ELSEIF ... ELSE ... ENDIF`. - **Multi-way Branching (CASE)**: Implemented using `CASE WHEN ... WHEN OTHERS ... ENDCASE`. Each `WHEN` branch operates independently and exits automatically without requiring a `BREAK` statement. - **Logical Operators & Initial Check**: Conditions can be combined using `AND`, `OR`, `NOT`, and parenthetical grouping `()`. Use `IS INITIAL` to check if a variable holds its initial/uninitialized default value. - **Loops (DO / WHILE)**: Unconditional/conditional looping via `DO ... ENDDO` or `WHILE ... ENDWHILE`, exited using the `EXIT` statement. - **Internal Table Loop (LOOP AT)**: Iterates through internal tables via `LOOP AT INTO [WHERE ] ... ENDLOOP`. Supports pattern matching such as `CP` (Contains Pattern with wildcard `*`) or `CF`. --- ### 5. Output & Screen Formatting - **Output Command (WRITE)**: In classical report programs, `WRITE ` outputs data to the list screen. Advanced formatting uses `WRITE /() ` to specify newlines (`/`), starting position, and display length. - **Spacing & Dividers**: `SKIP ` skips blank lines, and `ULINE` draws horizontal divider lines. - **Multilingual Labels (Text Symbols)**: Avoid hardcoding text strings; use **Text Symbols** (`TEXT-xxx` or `text-001`) so labels can be translated into multiple system languages. --- ### 6. Message Handling - **Displaying Messages**: Triggered using `MESSAGE TYPE `. Message types include `S` (Success), `I` (Information), `W` (Warning), `E` (Error), `A` (Abort), and `X` (Exit / Exception). - **Message Class (SE91)**: Manages centralized messages and supports passing up to 4 dynamic parameters (`WITH var1 var2 var3 var4`) into placeholders (`&1` through `&4`). --- ### 7. Selection Screens & User Inputs - **Single Parameters (PARAMETERS)**: Generates single input fields (parameter names are limited to 8 characters). Additions include `OBLIGATORY` (mandatory field) and `DEFAULT `. - **Range Selection (SELECT-OPTIONS)**: Creates a range input control (`FROM` ... `TO`) using `SELECT-OPTIONS FOR `. - **Screen Blocks**: Encloses parameters in visual frames using `SELECTION-SCREEN BEGIN OF BLOCK WITH FRAME TITLE ... END OF BLOCK`. --- ### 8. Program Events in Report Programs - **INITIALIZATION**: Executes first when opening a report program, used for initializing defaults. - **AT SELECTION-SCREEN**: Triggers when user interacts with or submits the selection screen, ideal for input validation. - **START-OF-SELECTION**: Kicks off upon pressing Execute (**F8**), containing core business processing and data queries. --- ### 9. Operations, Date/Time Arithmetic & System Variables - **Arithmetic Operations**: Uses standard operators (`+`, `-`, `*`, `/`), integer division (`DIV`), modulo (`MOD`), and square root (`SQRT`). - **Date (D) & Time (T) Calculations**: Automatically calculates date/time rollovers (e.g., adding 1 day to `20231231` yields `20240101`). Substring offset access uses `<var>+<offset>(<length>)`. - **Key System Variables (sy-)**: - `sy-subrc`: Return code of the previous statement (`0` = success, non-zero e.g., `4` = failure). - `sy-tabix`: Current line index inside an internal table loop (`LOOP AT`). - `sy-datum`: Current system date. - `sy-uzeit`: Current system time. - `sy-uname`: Logged-in user name. - `sy-langu`: Logged-in language. - `sy-tcode`: Current transaction code. - `sy-repid`: Current program ID. --- ### 10. Debugging Capabilities - **ABAP Debugger**: Allows setting breakpoints to step line-by-line (using **F6** to step over, **F8** to continue) to monitor real-time data transformations and diagnose runtime dumps or logic errors. 23:T800,ABAP Basic Statements 1. Basic Syntax Rules & Comments - Statement Termination: Every ABAP statement must end with a period (\\.\\). A statement can span across multiple lines until a period is encountered. - Case Insensitivity: ABAP code is case-insensitive; keywords, additions, and operands can be written in uppercase or lowercase. - Comments: - An asterisk (\) at the very first position of a line comments out the entire line. - A double quote (\\"\\) comments out everything from that position to the end of the line. - Chained Statements: Multiple statements repeating the same keyword can be chained using a colon (\\:\\) and separated by commas (\\,\\) (e.g., WRITE: var1, var2.). --- 2. Data Objects & Type Declarations - Data Objects: ABAP distinguishes between Variables (DATA), Constants (CONSTANTS), and Literals (text in '...', string in ... , or numbers). - Variable Declaration: Declared using DATA <variablename TYPE <datatype with an optional VALUE addition. To copy the type of an existing data object, use LIKE. - Local vs. Global Types: - Local Data Types (TYPES): Defined locally within a program. If a local type shares the same name as a global type, the local definition takes precedence. - Global Data Types: Created and managed system-wide via the ABAP Dictionary (transaction code SE11). - Predefined Data Types: - Complete Data Types (fixed length): D (Date - 8 characters YYYYMMDD), T (Time - 6 characters HHMMSS), I (Integer - 4 bytes, range -2^31 to +2^31), STRING (dynamic character string). - Incomplete Data Types (length required): C (Character), N (Numeric text), and P (Packed number - used for calculations/currencies with DECIMALS specification). - Internal Tables: Declared using DATA <tablename TYPE TABLE OF <linetype to hold lists of structured data. --- 3. Coding Convension - Custom Type: GT, GTS, GTT\ - Constant: GC\ - Global variables: GD\ - Work Area (Structure): GS\ - Internal Table: GT\ - Local variables: LD\ - Local work area: LS\ - Local internal table: LT\ - Selection-screen Parameter: P\24:T7f3,## ABAP Basic Statements ### 1. Basic Syntax Rules & Comments - **Statement Termination**: Every ABAP statement must end with a **period (\*\***.\***\*)**. A statement can span across multiple lines until a period is encountered. - **Case Insensitivity**: ABAP code is case-insensitive; keywords, additions, and operands can be written in uppercase or lowercase. - **Comments**: - An **asterisk** (\*) at the very first position of a line comments out the entire line. - A **double quote (\*\***"\***\*)** comments out everything from that position to the end of the line. - **Chained Statements**: Multiple statements repeating the same keyword can be chained using a **colon (\*\***:\***\*)** and separated by **commas (\*\***,\***\*)** (e.g., `WRITE: var1, var2.`). --- ### 2. Data Objects & Type Declarations - **Data Objects**: ABAP distinguishes between **Variables** (`DATA`), **Constants** (`CONSTANTS`), and **Literals** (text in `'...'`, string in `` `...` ``, or numbers). - **Variable Declaration**: Declared using `DATA <variable_name> TYPE <data_type>` with an optional `VALUE` addition. To copy the type of an existing data object, use `LIKE`. - **Local vs. Global Types**: - **Local Data Types** (`TYPES`): Defined locally within a program. If a local type shares the same name as a global type, the local definition takes **precedence**. - **Global Data Types**: Created and managed system-wide via the **ABAP Dictionary** (transaction code `SE11`). - **Predefined Data Types**: - **Complete Data Types** (fixed length): `D` (Date - 8 characters `YYYYMMDD`), `T` (Time - 6 characters `HHMMSS`), `I` (Integer - 4 bytes, range -2^31 to +2^31), `STRING` (dynamic character string). - **Incomplete Data Types** (length required): `C` (Character), `N` (Numeric text), and `P` (Packed number - used for calculations/currencies with `DECIMALS` specification). - **Internal Tables**: Declared using `DATA <table_name> TYPE TABLE OF <line_type>` to hold lists of structured data. --- ### 3. Coding Convension25:T22f5, ## 1. System Overview & Architecture The **ABAP Data Dictionary (DDIC)**, managed via Transaction Code **`SE11`**, is an integrated database management framework embedded within the SAP ABAP application server. It acts as a database abstraction layer positioned between SAP application programs and the underlying Relational Database Management System (RDBMS) such as Oracle or Microsoft SQL Server. ``` +-------------------------------------------------------+ | SAP Application Layer | | (ABAP Programs, SE38, SE80) | +-------------------------------------------------------+ | v +-------------------------------------------------------+ | ABAP Data Dictionary (SE11) | | (Domains, Data Elements, Structures, Tables, Views) | +-------------------------------------------------------+ | v (Auto-generated DDL / Objects) +-------------------------------------------------------+ | Underlying RDBMS Layer | | (Oracle, MS SQL Server, SAP HANA) | +-------------------------------------------------------+ ``` ### Key Functional Capabilities - **Database Independence**: Eliminates the requirement for developers to write platform-specific SQL Data Definition Language (DDL) scripts. - **Centralized Object Reuse**: Enables system-wide definition and reuse of global data types, database tables, views, and search helps. - **Active Runtime Catalog**: Database table structures defined in the DDIC are compiled directly into physical database objects upon activation. --- ## 2. Elementary Data Type Architecture: Domain vs. Data Element ![[../images/domain-data-element.png]] Data field definitions in the ABAP Dictionary decouple **technical parameters** from **business semantics** through a two-tier architecture comprising **Domains** and **Data Elements**. ![[../images/domain-data-element-1.png]] ### 2.1 Domain (Technical Attribute Layer) - **Definition**: Defines the physical and technical attributes of a data field. - **Technical Parameters**: - Built-in Data Type (e.g., `CHAR`, `NUMC`, `DEC`, `DATS`, `TIMS`). - Field Length and **Output Length** (accounts for formatting characters such as decimal points, currency signs, or negative indicators). - Case Sensitivity toggle (`Lower Case` / `Case Sensitive`). - **Value Restrictions**: - **Fixed Values (Value Range)**: Hardcoded valid single values or interval ranges enforced at domain level. - **Value Table**: Points to a master check table containing allowable key entries. ### 2.2 Data Element (Semantic Attribute Layer) - **Definition**: Defines the business meaning and contextual usage of a data object. - **Semantic Attributes**: - **UI Field Labels**: Defines Short, Medium, Long, and Heading labels displayed across screens and report columns. - **F1 Help Documentation**: Links to detailed documentation created via the documentation editor for end-user assistance. - **Relationship**: References a Domain to inherit technical attributes. A single Domain can be referenced by multiple Data Elements (e.g., Domain `S_CITY` referenced by Data Elements `S_FROMCIT` and `S_TOCITY`). - **Naming Conventions**: Domains and Data Elements reside in distinct object namespaces and can share identical names, though project guidelines typically utilize prefixes (e.g., `DO_` for domains, `DE_` for data elements). ### Example: ## ![[../images/domain-data-element-2.png]] ## 3. Composite Data Objects & Database Tables ### 3.1 Structures - **Definition**: Reusable, structured type definitions comprising a sequence of named components/fields. - **Behavior**: Structures do **not** persist data in the physical database. - **Applications**: - Used in ABAP programs to instantiate **Work Areas** (single-row structures). - Included directly within database table definitions via the **`INCLUDE`** statement to standardize field groups across multiple tables. ### 3.2 Data Categories in SAP 1. **Master Data**: Core entity records modified infrequently (e.g., Customer, Vendor, Material, Employee). 2. **Transactional Data**: High-volume operational transaction records (e.g., Sales Orders, Purchase Orders, Accounting Documents). 3. **Configuration Data**: System customization parameters established during project setup (e.g., Currency Codes, Payment Terms). 4. **System Data**: System administration and administrative runtime logs. ### 3.3 Database Table Types | Table Type | Description & Physical Mapping | | :-------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Transparent Table** | **1-to-1 Mapping**: Each transparent table defined in `SE11` corresponds to exactly one physical table in the database. | | **Pooled Table** | **N-to-1 Mapping**: Multiple logical pooled tables consolidated into a single physical table in the database; used primarily by system tables. | | **Cluster Table** | **N-to-1 Mapping**: Multiple logical cluster tables combined into a single database cluster table (e.g., `BSEG`); optimized for complex structural documents, considered legacy in SAP HANA. | | **Table Type** | **Global Memory Type**: A DDIC object defining internal table types used for ABAP program execution, containing no database persistence. | ### 3.4 Relational Features - **Primary Key**: Uniquely identifies each record in a database table. Key fields cannot be edited directly after record insertion. - **Client Dependency (`MANDT` / `CLIENT`)**: Automatic client separation is achieved by defining the primary key field `MANDT` (Data Element `MANDT`), ensuring data isolation per system client. - **Foreign Keys & Check Tables**: Foreign key field definitions map fields to a **Check Table** to maintain relational data integrity and auto-generate F4 input validation. --- ## 4. Database Views & Core Data Services (CDS) Views are logical definitions that join fields across one or more tables without duplicating physical data. ### 4.1 Classic DDIC Views (`SE11`) 1. **Database View**: Implements standard inner joins across database tables for read access. 2. **Maintenance View**: Configures table joins specifically to power Table Maintenance Generators (TMG) for administrative data entry. 3. **Projection View**: Selects a subset of fields from a single table to mask unwanted attributes. 4. **Help View**: Serves as the data selection foundation for Search Helps. ### 4.2 Core Data Services (CDS) Views - **Architecture**: Modern, code-based data modeling tool defined inside Eclipse ADT using SQL DDL syntax. - **Integration**: Automatically generates a underlying classic SQL View (limited to 16 characters) accessible via standard `SE11` and `SE16N` queries. --- ## 5. Input Assistance & Data Inspection ### 5.1 Search Help (F4 Help) Provides user assistance dialogs during UI field input. - **Elementary Search Help**: Defines a single search path, specifying the selection method (table/view), input/output parameters, and hit list layout. - **Collective Search Help**: Combines multiple Elementary Search Helps into a single tabbed dialog interface. ### 5.2 Data Inspection Utilities - **`SE16`**: Classic ABAP Workbench data browser utility; supports ALV Grid display via user parameter adjustments. - **`SE16N`**: Enhanced application data browser providing field filtering and record inspection capabilities. --- ## 6. Technical Settings & Performance Guidelines Every database table created in `SE11` requires technical settings configuration prior to activation: - **Delivery Class**: Specifies table data maintenance rules and client transport behavior (e.g., `A` for Application Master/Transaction data, `C` for Customizing). - **Data Class**: Determines physical database space allocation: - `APPL0`: Master Data. - `APPL1`: Transactional Data. - `USER`: User-specific datasets. - **Size Category**: Configures initial database extent allocation based on expected row count ranges. - **Buffering & Logging**: Enables application server memory caching for static tables or logs change operations. - **Secondary Indexes**: Additional index structures created on non-key columns to accelerate read performance; must be balanced against maintenance overhead during insert/update operations. ![[../images/domain-data-element-3.png]] 26:Ta28,1. System Overview & Architecture The ABAP Data Dictionary (DDIC), managed via Transaction Code SE11, is an integrated database management framework embedded within the SAP ABAP application server. It acts as a database abstraction layer positioned between SAP application programs and the underlying Relational Database Management System (RDBMS) such as Oracle or Microsoft SQL Server. +-------------------------------------------------------+ | SAP Application Layer | | (ABAP Programs, SE38, SE80) | +-------------------------------------------------------+ | v +-------------------------------------------------------+ | ABAP Data Dictionary (SE11) | | (Domains, Data Elements, Structures, Tables, Views) | +-------------------------------------------------------+ | v (Auto-generated DDL / Objects) +-------------------------------------------------------+ | Underlying RDBMS Layer | | (Oracle, MS SQL Server, SAP HANA) | +-------------------------------------------------------+ Key Functional Capabilities - Database Independence: Eliminates the requirement for developers to write platform-specific SQL Data Definition Language (DDL) scripts. - Centralized Object Reuse: Enables system-wide definition and reuse of global data types, database tables, views, and search helps. - Active Runtime Catalog: Database table structures defined in the DDIC are compiled directly into physical database objects upon activation. --- 2. Elementary Data Type Architecture: Domain vs. Data Element ![[../images/domain-data-element.png]] Data field definitions in the ABAP Dictionary decouple technical parameters from business semantics through a two-tier architecture comprising Domains and Data Elements. ![[../images/domain-data-element-1.png]] 2.1 Domain (Technical Attribute Layer) - Definition: Defines the physical and technical attributes of a data field. - Technical Parameters: - Built-in Data Type (e.g., CHAR, NUMC, DEC, DATS, TIMS). - Field Length and Output Length (accounts for formatting characters such as decimal points, currency signs, or negative indicators). - Case Sensitivity toggle (Lower Case / Case Sensitive). - Value Restrictions: - Fixed Values (Value Range): Hardcoded valid single values or interval ranges enforced at domain level. - Value Table: Points to a master check table containing allowable key entries. 2.2 Data Element (Semantic Attribute Layer) - Definition: Defines the business meaning and contextual usage of a data object. - Semantic Attributes: - UI Field Labels: Defines Short, Medium, Long, and Heading labels displayed across screens and report columns. -27:Tabf,## 1. System Overview & Architecture The **ABAP Data Dictionary (DDIC)**, managed via Transaction Code **`SE11`**, is an integrated database management framework embedded within the SAP ABAP application server. It acts as a database abstraction layer positioned between SAP application programs and the underlying Relational Database Management System (RDBMS) such as Oracle or Microsoft SQL Server. ``` +-------------------------------------------------------+ | SAP Application Layer | | (ABAP Programs, SE38, SE80) | +-------------------------------------------------------+ | v +-------------------------------------------------------+ | ABAP Data Dictionary (SE11) | | (Domains, Data Elements, Structures, Tables, Views) | +-------------------------------------------------------+ | v (Auto-generated DDL / Objects) +-------------------------------------------------------+ | Underlying RDBMS Layer | | (Oracle, MS SQL Server, SAP HANA) | +-------------------------------------------------------+ ``` ### Key Functional Capabilities - **Database Independence**: Eliminates the requirement for developers to write platform-specific SQL Data Definition Language (DDL) scripts. - **Centralized Object Reuse**: Enables system-wide definition and reuse of global data types, database tables, views, and search helps. - **Active Runtime Catalog**: Database table structures defined in the DDIC are compiled directly into physical database objects upon activation. --- ## 2. Elementary Data Type Architecture: Domain vs. Data Element ![[../images/domain-data-element.png]] Data field definitions in the ABAP Dictionary decouple **technical parameters** from **business semantics** through a two-tier architecture comprising **Domains** and **Data Elements**. ![[../images/domain-data-element-1.png]] ### 2.1 Domain (Technical Attribute Layer) - **Definition**: Defines the physical and technical attributes of a data field. - **Technical Parameters**: - Built-in Data Type (e.g., `CHAR`, `NUMC`, `DEC`, `DATS`, `TIMS`). - Field Length and **Output Length** (accounts for formatting characters such as decimal points, currency signs, or negative indicators). - Case Sensitivity toggle (`Lower Case` / `Case Sensitive`). - **Value Restrictions**: - **Fixed Values (Value Range)**: Hardcoded valid single values or interval ranges enforced at domain level. - **Value Table**: Points to a master check table containing allowable key entries. ### 2.2 Data Element (Semantic Attribute Layer)28:T201d, ## 1. Architecture & Execution Model **Open SQL** is an embedded subset of ANSI SQL fully integrated into the ABAP programming language. It acts as an abstraction layer between application programs and the underlying database management system (DBMS). ``` +-------------------------------------------------------+ | ABAP Application Layer | | (Open SQL Statements / SE38) | +-------------------------------------------------------+ | v (ABAP Syntax Check & Compilation) +-------------------------------------------------------+ | ABAP Database Interface | | (Translates Open SQL into Native SQL DML) | +-------------------------------------------------------+ | v (Database-Specific SQL Execution) +-------------------------------------------------------+ | Underlying RDBMS Layer | | (Oracle, MS SQL Server, SAP HANA) | +-------------------------------------------------------+ ``` ### 1.1 Key Architectural Properties - **Database Independence**: Open SQL statements are uniform across all supported database platforms. The **Database Interface** automatically converts Open SQL statements into the platform-specific **Native SQL** required by the underlying RDBMS (e.g., Oracle, MS SQL Server). - **Integrated Syntax Validation**: Because Open SQL is a native component of the ABAP language, the ABAP compiler validates SQL syntax directly during program compilation. - **Open SQL vs. Native SQL**: - **Open SQL**: Portable, database-agnostic, statically syntax-checked by the ABAP IDE, and automatically managed by the database interface. - **Native SQL**: Executes database-specific DML/DDL scripts directly. It bypasses the Database Interface, sacrificing portability and static compile-time syntax checks. - **Legacy Table Declarations**: The obsolete `TABLES <table>` statement implicitly creates a structure/work area sharing the table's name. Modern ABAP standards explicitly discourage this statement in favor of explicit type definitions. --- ## 2. Fundamental Query Syntax & Row Selection A standard Open SQL data retrieval statement consists of four core clauses: `SELECT`, `FROM`, `INTO`, and `WHERE`. ```abap SELECT <fields> FROM <table> INTO <target> WHERE <conditions>. ``` ### 2.1 Filtering & Evaluation (`WHERE`) - **Conditional Operators**: Supports standard comparison operators (`=`, `<`, `>`, `<=`, `>=`, `<>`), string pattern matching (`CP`, `CF`), range operators (`BETWEEN`, `IN`), and logical connectors (`AND`, `OR`, `NOT`). - **Selection Tables**: The `IN` operator evaluates field values against selection tables or range tables. ### 2.2 Row-Limiting Techniques - **`SELECT SINGLE`**: - Fetches a single record matching the query criteria. - **Best Practice**: Pass the complete primary key in the `WHERE` clause to guarantee deterministic behavior. - Does not open a database loop and does not require an `ENDSELECT` statement. - **`UP TO n ROWS`**: - Limits the result set to `n` rows. - **Best Practice**: Recommended over `SELECT SINGLE` when filtering on partial key fields. - Requires an `ENDSELECT` statement when selecting row-by-row into a work area. ### 2.3 Result Ordering & Deduplication - **`ORDER BY`**: Guarantees output row ordering. Can sort by `PRIMARY KEY` or by specific columns using `ASCENDING` or `DESCENDING` modifiers. - **`DISTINCT`**: Eliminates duplicate result rows prior to populating the target data object. ### 2.4 System Fields - **`sy-subrc`**: Returns `0` if the query successfully retrieves data, and `4` if no matching records are found. - **`sy-dbcnt`**: Contains the total count of records retrieved or processed by the query. --- ## 3. Aggregation & Grouping Open SQL provides built-in aggregation functions to perform calculations directly on the database engine prior to returning results. | Aggregation Function | Description | | :------------------------------ | :-------------------------------------------------------- | | `COUNT( * )` / `COUNT( field )` | Returns the total count of rows or non-null field values. | | `MAX( field )` | Identifies the maximum value in a column. | | `MIN( field )` | Identifies the minimum value in a column. | | `SUM( field )` | Calculates the total sum of a numeric column. | | `AVG( field )` | Computes the average value of a numeric column. | ### 3.1 Grouping Requirement (`GROUP BY`) When an Open SQL statement includes both scalar columns and aggregate functions in the `SELECT` clause, **all non-aggregated columns must be explicitly listed in the `GROUP BY` clause**. ```abap SELECT carrid, MAX( flytime ), MIN( flytime ) FROM spfli INTO (lv_carrid, lv_max_time, lv_min_time) GROUP BY carrid. ``` --- ## 4. Target Data Objects & Mapping Strategies Data retrieved via Open SQL can be mapped into single-row **Work Areas** or multi-row **Internal Tables**. ``` positional mapping (INTO TABLE): Database Columns: [ MANDT ] [ CARRID ] [ CONNID ] [ COUNTRYFR ] | | | | Target Structure: [ MANDT ] [ CARRID ] [ CONNID ] [ COUNTRYFR ] name-based mapping (INTO CORRESPONDING FIELDS OF TABLE): Database Columns: [ CARRID ] [ CONNID ] [ COUNTRYFR ] | | | +-----------+------------+ (Matches by Name) | Target Structure: [ STATUS ] [ CARRID ] [ CONNID ] [ COUNTRYFR ] ``` ### 4.1 Target Object Comparison | Feature | Work Area (`STRUCTURE`) | Internal Table (`INTERNAL TABLE`) | | :---------------- | :------------------------------------------------- | :---------------------------------------------- | | **Capacity** | Holds a single row of data at a time. | Holds multi-row datasets in application memory. | | **Access Syntax** | Direct field component selection (`<wa>-<field>`). | Iterated using `LOOP AT <itab> INTO <wa>`. | | **Target Clause** | `INTO <work_area>`. | `INTO TABLE <internal_table>`. | ### 4.2 Positional Mapping vs. Name-Based Mapping - **`INTO TABLE <itab>`**: Transfers column data sequentially based on field positions. If the target structure layout differs from the `SELECT` clause field order, data misalignment or truncation occurs. - **`INTO CORRESPONDING FIELDS OF TABLE <itab>`**: Matches database table columns to internal table fields strictly by **field name**, ignoring structural field sequence. Unmapped target fields remain set to their initial values. --- ## 5. Multi-Table Operations & Advanced Filtering ### 5.1 Relational Joins (`JOIN`) Joins combine records across multiple database tables within a single database request. Fields are qualified using tilde syntax (`<table>~<field>` or `<alias>~<field>`). - **`INNER JOIN`**: Returns combined records only when join conditions match in both left and right tables. - **`LEFT OUTER JOIN`**: Returns all rows from the left table. If no matching row exists in the right table, right-table fields are populated with type-specific initial values. ```abap SELECT header~vbeln, header~kunnr, item~posnr, item~matnr FROM vbak AS header INNER JOIN vbap AS item ON header~vbeln = item~vbeln INTO TABLE @DATA(lt_orders). ``` ### 5.2 Internal Table Filtering (`FOR ALL ENTRIES IN`) The `FOR ALL ENTRIES IN` clause evaluates an Open SQL query against all entries in a pre-populated driver internal table. - **Behavior**: Replaces large, complex database joins by using in-memory driver tables as filter criteria. - **Syntax**: ```abap SELECT doc_type, company_code, doc_num FROM bkpf INTO TABLE lt_headers FOR ALL ENTRIES IN lt_filter_tab WHERE doc_type = lt_filter_tab-doc_type. ``` --- 29:T9e1,1. Architecture & Execution Model Open SQL is an embedded subset of ANSI SQL fully integrated into the ABAP programming language. It acts as an abstraction layer between application programs and the underlying database management system (DBMS). +-------------------------------------------------------+ | ABAP Application Layer | | (Open SQL Statements / SE38) | +-------------------------------------------------------+ | v (ABAP Syntax Check & Compilation) +-------------------------------------------------------+ | ABAP Database Interface | | (Translates Open SQL into Native SQL DML) | +-------------------------------------------------------+ | v (Database-Specific SQL Execution) +-------------------------------------------------------+ | Underlying RDBMS Layer | | (Oracle, MS SQL Server, SAP HANA) | +-------------------------------------------------------+ 1.1 Key Architectural Properties - Database Independence: Open SQL statements are uniform across all supported database platforms. The Database Interface automatically converts Open SQL statements into the platform-specific Native SQL required by the underlying RDBMS (e.g., Oracle, MS SQL Server). - Integrated Syntax Validation: Because Open SQL is a native component of the ABAP language, the ABAP compiler validates SQL syntax directly during program compilation. - Open SQL vs. Native SQL: - Open SQL: Portable, database-agnostic, statically syntax-checked by the ABAP IDE, and automatically managed by the database interface. - Native SQL: Executes database-specific DML/DDL scripts directly. It bypasses the Database Interface, sacrificing portability and static compile-time syntax checks. - Legacy Table Declarations: The obsolete TABLES <table statement implicitly creates a structure/work area sharing the table's name. Modern ABAP standards explicitly discourage this statement in favor of explicit type definitions. --- 2. Fundamental Query Syntax & Row Selection A standard Open SQL data retrieval statement consists of four core clauses: SELECT, FROM, INTO, and WHERE. abap SELECT <fields FROM <table INTO <target WHERE <conditions. 2.1 Filtering & Evaluation (WHERE) - Conditional Operators: Supports standard comparison operators (=, <, , <=, =, <), string pattern matching (CP, CF), range operators (BETWEEN, IN), and logical connectors (AND, OR, NOT). - Selection Tables: The IN operator evaluates field values against selection tables or range tables. 2.2 Row-Limiting Techniques - SELECT SINGLE: - Fetches a single record matching the query2a:Tb38,## 1. Architecture & Execution Model **Open SQL** is an embedded subset of ANSI SQL fully integrated into the ABAP programming language. It acts as an abstraction layer between application programs and the underlying database management system (DBMS). ``` +-------------------------------------------------------+ | ABAP Application Layer | | (Open SQL Statements / SE38) | +-------------------------------------------------------+ | v (ABAP Syntax Check & Compilation) +-------------------------------------------------------+ | ABAP Database Interface | | (Translates Open SQL into Native SQL DML) | +-------------------------------------------------------+ | v (Database-Specific SQL Execution) +-------------------------------------------------------+ | Underlying RDBMS Layer | | (Oracle, MS SQL Server, SAP HANA) | +-------------------------------------------------------+ ``` ### 1.1 Key Architectural Properties - **Database Independence**: Open SQL statements are uniform across all supported database platforms. The **Database Interface** automatically converts Open SQL statements into the platform-specific **Native SQL** required by the underlying RDBMS (e.g., Oracle, MS SQL Server). - **Integrated Syntax Validation**: Because Open SQL is a native component of the ABAP language, the ABAP compiler validates SQL syntax directly during program compilation. - **Open SQL vs. Native SQL**: - **Open SQL**: Portable, database-agnostic, statically syntax-checked by the ABAP IDE, and automatically managed by the database interface. - **Native SQL**: Executes database-specific DML/DDL scripts directly. It bypasses the Database Interface, sacrificing portability and static compile-time syntax checks. - **Legacy Table Declarations**: The obsolete `TABLES <table>` statement implicitly creates a structure/work area sharing the table's name. Modern ABAP standards explicitly discourage this statement in favor of explicit type definitions. --- ## 2. Fundamental Query Syntax & Row Selection A standard Open SQL data retrieval statement consists of four core clauses: `SELECT`, `FROM`, `INTO`, and `WHERE`. ```abap SELECT <fields> FROM <table> INTO <target> WHERE <conditions>. ``` ### 2.1 Filtering & Evaluation (`WHERE`) - **Conditional Operators**: Supports standard comparison operators (`=`, `<`, `>`, `<=`, `>=`, `<>`), string pattern matching (`CP`, `CF`), range operators (`BETWEEN`, `IN`), and logical connectors (`AND`, `OR`, `NOT`). - **Selection Tables**: The `IN` operator evaluates field values against selection tables or range tables. ### 2.2 Row-Limiting Techniques2b:T6055, ## 1. Mental Model: Type, Structure, Work Area, and Internal Table Do not treat these as four equivalent objects. ```text TYPES declaration defines a type; it does not hold runtime values │ ├── DATA structure one structured data object │ └── may serve as a work area │ └── DATA internal table zero or more lines of one line type ``` ### 1.1 Structured type A structured type defines named components and their types. `TYPES` creates a type, not a runtime data object. ```abap TYPES: BEGIN OF ty_flight, carrier_id TYPE c LENGTH 3, connection_id TYPE n LENGTH 4, city_from TYPE c LENGTH 40, city_to TYPE c LENGTH 40, price TYPE p LENGTH 8 DECIMALS 2, currency TYPE c LENGTH 3, END OF ty_flight. ``` The type can be local, defined globally in a class/interface, or supplied by a released Dictionary/CDS artifact. `SE11` is a classic Dictionary maintenance tool, not the definition of the ABAP concept itself. ### 1.2 Structure data object `DATA` instantiates a data object and therefore allocates runtime state. ```abap DATA flight TYPE ty_flight. ``` The word **structure** can mean either a structured type or a structured data object, depending on context. Say which one you mean in technical explanations. ### 1.3 Work area A **work area** is a role played by a single data object when a table statement copies one line into it or reads a line from it. It is not a separate ABAP type category. ```abap DATA flight TYPE ty_flight. LOOP AT flights INTO flight. " flight is the work area for this loop ENDLOOP. ``` ### 1.4 Internal table An internal table is an in-memory ABAP data object containing zero or more lines. Its type is defined by: 1. line type; 2. table category; 3. primary table key; 4. optional secondary table keys. It is not a database table and is not persisted by `COMMIT WORK`. Its lifetime follows the lifetime and scope of its owning ABAP data object. ```abap TYPES ty_flights TYPE STANDARD TABLE OF ty_flight WITH EMPTY KEY. DATA flights TYPE ty_flights. ``` ### 1.5 Database boundary ```text Database table / CDS entity │ SELECT ▼ Internal table in ABAP application-server memory │ processing ▼ INSERT / UPDATE / MODIFY / DELETE or EML, when explicitly executed ``` Changing an internal-table line does not automatically update a database table or a RAP business object. --- ## 2. Complete, Reusable Example Types The examples below use explicit keys so their behavior is visible. ```abap TYPES: BEGIN OF ty_flight, carrier_id TYPE c LENGTH 3, connection_id TYPE n LENGTH 4, city_from TYPE c LENGTH 40, city_to TYPE c LENGTH 40, price TYPE p LENGTH 8 DECIMALS 2, currency TYPE c LENGTH 3, END OF ty_flight. TYPES ty_flights_seq TYPE STANDARD TABLE OF ty_flight WITH EMPTY KEY. TYPES ty_flights_sorted TYPE SORTED TABLE OF ty_flight WITH UNIQUE KEY primary_key COMPONENTS carrier_id connection_id. TYPES ty_flights_hashed TYPE HASHED TABLE OF ty_flight WITH UNIQUE KEY primary_key COMPONENTS carrier_id connection_id. DATA flights_seq TYPE ty_flights_seq. DATA flights_sorted TYPE ty_flights_sorted. DATA flights_hashed TYPE ty_flights_hashed. ``` `WITH EMPTY KEY` is a deliberate statement: the standard table is being used as a sequence, not as a keyed collection. --- ## 3. Table Categories Big-O values below are useful mental models, not promises about every kernel, row width, cache state, or access form. | Category | Primary organization | Primary-key uniqueness | Efficient access | Typical use | | ---------------- | ------------------------------------------ | ---------------------- | ----------------------------------------------------------- | ---------------------------------------------------- | | `STANDARD TABLE` | Primary index in insertion order | Non-unique or empty | Index access; sequential processing | Append-heavy lists, ordered processing, small tables | | `SORTED TABLE` | Primary index always sorted by primary key | Unique or non-unique | Left-aligned primary-key access, approximately `O(log n)` | Range reads and frequent ordered key access | | `HASHED TABLE` | Hash administration; no primary index | Must be unique | Complete primary-key equality, approximately `O(1)` average | Fast exact lookup by a unique key | ### 3.1 Standard table - Fast append and index access. - A normal key search is linear unless an appropriate secondary key or a valid binary-search pattern is used. - The primary key does not enforce uniqueness. - Prefer `WITH EMPTY KEY` when the table is intentionally only a sequence. ### 3.2 Sorted table - Lines are always maintained in ascending primary-key order. - The primary key may be unique or non-unique. - Optimized access requires the search components to form a usable left-aligned part of the sorted key. - It supports index access because it is an index table. For a key `(carrier_id, connection_id)`, searching by `carrier_id` can use the sorted prefix; searching only by `connection_id` cannot use that primary-key prefix efficiently. ### 3.3 Hashed table - The primary key must be unique. - Best for equality lookup using the complete hash key. - No primary index access such as `INDEX 1`. - Partial-key and range searches do not receive the main hash advantage. ### 3.4 Selection rule ```text Need stable index/insertion order or mostly append/loop? → STANDARD Need sorted traversal, ranges, or prefix-key lookup? → SORTED Need exact lookup by one complete unique key? → HASHED Need several access paths? → Add justified secondary keys; do not copy the table automatically ``` --- ## 4. Primary and Secondary Table Keys A table key is not merely documentation. It determines uniqueness, access optimization, ordering for sorted keys, and maintenance cost. ### 4.1 Secondary-key example ```abap TYPES ty_flights_multi TYPE STANDARD TABLE OF ty_flight WITH EMPTY KEY WITH UNIQUE HASHED KEY by_connection COMPONENTS carrier_id connection_id WITH NON-UNIQUE SORTED KEY by_route COMPONENTS city_from city_to. ``` ```abap READ TABLE flights_multi WITH TABLE KEY by_connection COMPONENTS carrier_id = 'LH' connection_id = '0400' INTO DATA(flight). LOOP AT flights_multi INTO DATA(route_flight) USING KEY by_route WHERE city_from = 'FRANKFURT'. " Uses the named sorted access path when the condition fits the key ENDLOOP. ``` ### 4.2 Secondary-key trade-off Secondary keys can make reads much faster, but they require extra memory and must be maintained when table content changes. Add one only for a demonstrated access pattern, not “for performance” in the abstract. --- ## 5. Assignment and Name-Based Mapping The original claim that normal assignment can silently “misalign” fields is too broad. ABAP checks assignment compatibility and applies the defined assignment rules. It does not simply scramble fields because their names differ. Use direct assignment when source and target types are compatible: ```abap target = source. ``` Use `CORRESPONDING` when the desired contract is name-based component mapping: ```abap DATA(target) = CORRESPONDING ty_target( source MAPPING target_id = source_id ). ``` Use the statement form when updating an existing target: ```abap MOVE-CORRESPONDING source TO target. ``` Unmatched target components keep or receive values according to the exact statement/operator variant. Check `BASE`, `MAPPING`, `EXCEPT`, and deep-mapping semantics when preservation matters. --- ## 6. Constructing and Adding Lines ### 6.1 Constructor expressions ```abap flights_seq = VALUE #( ( carrier_id = 'LH' connection_id = '0400' city_from = 'FRANKFURT' city_to = 'NEW YORK' price = '800.00' currency = 'EUR' ) ( carrier_id = 'SQ' connection_id = '0012' city_from = 'SINGAPORE' city_to = 'TOKYO' price = '650.00' currency = 'SGD' ) ). ``` ### 6.2 `APPEND` `APPEND` adds at the end of an index table. It is natural for a standard table. ```abap APPEND VALUE #( carrier_id = 'VN' connection_id = '0030' city_from = 'HO CHI MINH CITY' city_to = 'TOKYO' ) TO flights_seq. ``` Although `APPEND` is possible for sorted index tables, the new line must fit after the existing last line and obey key uniqueness. Otherwise the operation fails at runtime. Prefer semantic insertion for sorted tables. ### 6.3 `INSERT ... INTO TABLE` This key-based form works with all table categories and lets the table choose the physical position. ```abap INSERT VALUE #( carrier_id = 'LH' connection_id = '0400' ) INTO TABLE flights_sorted. IF sy-subrc = 4. " Duplicate unique key; no line inserted ENDIF. ``` For a standard table, use `INSERT ... INDEX index` only when position has business meaning. --- ## 7. Reading One Line Safely ### 7.1 `READ TABLE ... INTO`: copy the row ```abap READ TABLE flights_sorted WITH TABLE KEY primary_key COMPONENTS carrier_id = 'LH' connection_id = '0400' INTO DATA(flight). IF sy-subrc = 0. " flight is a copy ENDIF. ``` Modifying `flight` does not modify the table until it is written back. ### 7.2 `READ TABLE ... ASSIGNING`: alias the row ```abap READ TABLE flights_sorted WITH TABLE KEY primary_key COMPONENTS carrier_id = 'LH' connection_id = '0400' ASSIGNING FIELD-SYMBOL(<flight>). IF sy-subrc = 0. <flight>-price = '825.00'. " Changes the table line directly ENDIF. ``` A field symbol is an alias to an assigned data object, not a separately copied row. It must be assigned before dereferencing. ### 7.3 `REFERENCE INTO`: retain a data reference ```abap READ TABLE flights_sorted WITH TABLE KEY primary_key COMPONENTS carrier_id = 'LH' connection_id = '0400' REFERENCE INTO DATA(flight_ref). IF sy-subrc = 0. flight_ref->price = '825.00'. ENDIF. ``` ### 7.4 Table expressions ```abap TRY. DATA(lh_price) = flights_sorted[ carrier_id = 'LH' connection_id = '0400' ]-price. CATCH cx_sy_itab_line_not_found. " Handle the missing row ENDTRY. ``` A failed table expression normally raises `CX_SY_ITAB_LINE_NOT_FOUND`; it does not simply set `sy-subrc` like `READ TABLE`. For existence only: ```abap IF line_exists( flights_sorted[ carrier_id = 'LH' connection_id = '0400' ] ). " Do not perform a second lookup unless the row content is also needed ENDIF. ``` Use one `READ TABLE`, assignment, or reference when the next step needs the line; `line_exists` followed by a second read repeats the lookup. ### 7.5 System fields For common `READ TABLE` forms, `sy-subrc = 0` means a line was found and `sy-subrc = 4` commonly means no matching line was found. For index tables, `sy-tabix` can identify the affected or current primary/secondary index, but its meaning depends on the statement and key used. Hashed primary-key access has no primary table index. Table expressions do not generally set `sy-subrc` and do not generally update `sy-tabix`; use their expression/exception semantics instead. Never rely on a system field without tying it to the immediately preceding statement. --- ## 8. Iteration: Copy, Alias, or Reference | Form | Row handling | Use when | | ------------------------- | ------------------------------------------- | ------------------------------------------ | | `LOOP ... INTO` | Copies each row | Readability or independent copy is desired | | `LOOP ... ASSIGNING` | Assigns a field symbol to the current row | Direct mutation or avoiding row copies | | `LOOP ... REFERENCE INTO` | Returns a data reference to the current row | A reference must be passed or retained | ```abap LOOP AT flights_seq INTO DATA(flight_copy) WHERE city_from = 'FRANKFURT'. " Changes to flight_copy do not automatically change flights_seq ENDLOOP. LOOP AT flights_seq ASSIGNING FIELD-SYMBOL(<flight_row>) WHERE city_from = 'FRANKFURT'. <flight_row>-price += 25. " Direct table-line modification ENDLOOP. ``` `ASSIGNING` can avoid copying wide or deep rows, but do not claim it is always faster in a meaningful way. Choose it first for semantics—direct mutation—and measure performance where it matters. The primary-key components of sorted and hashed tables are protected from changes that would invalidate their administration. Delete and reinsert a line when its primary identity must change. --- ## 9. Modifying Lines ### 9.1 Modify by table key ```abap DATA changed_flight TYPE ty_flight. changed_flight-carrier_id = 'LH'. changed_flight-connection_id = '0400'. changed_flight-price = '850.00'. MODIFY TABLE flights_sorted FROM changed_flight. IF sy-subrc <> 0. " No row matched the primary key ENDIF. ``` ### 9.2 Modify selected components ```abap MODIFY flights_seq FROM VALUE #( price = '700.00' currency = 'EUR' ) TRANSPORTING price currency WHERE carrier_id = 'LH'. ``` ### 9.3 Modify by field symbol ```abap LOOP AT flights_seq ASSIGNING FIELD-SYMBOL(<flight>) WHERE carrier_id = 'LH'. <flight>-price *= '0.95'. ENDLOOP. ``` No `MODIFY` is needed in the last example because `<flight>` aliases the table line. By contrast, a changed work-area copy from `LOOP ... INTO` must be written back explicitly, normally with a clear key or index. --- ## 10. Deleting and Clearing ```abap DELETE flights_seq INDEX 1. DELETE flights_sorted USING KEY primary_key WHERE carrier_id = 'LH'. DELETE TABLE flights_hashed WITH TABLE KEY primary_key COMPONENTS carrier_id = 'LH' connection_id = '0400'. ``` ### 10.1 Remove duplicates `DELETE ADJACENT DUPLICATES` removes only neighboring duplicates according to the comparison. For a standard table, sort into the required adjacency first. ```abap SORT flights_seq BY city_from city_to. DELETE ADJACENT DUPLICATES FROM flights_seq COMPARING city_from city_to. ``` The sort fields and comparison fields must express the same intended identity. ### 10.2 `CLEAR` versus `FREE` ```abap CLEAR flights_seq. " Remove rows; retain initial allocation for reuse FREE flights_seq. " Remove rows and release the initial table allocation ``` Use `CLEAR` when the table will probably be filled again soon. Use `FREE` when releasing a large table's allocation is useful. The ABAP runtime still owns the details of dynamic memory management; do not assume an operating-system memory change at that exact statement. --- ## 11. Sorting and Binary Search ```abap SORT flights_seq BY carrier_id connection_id. READ TABLE flights_seq WITH KEY carrier_id = 'LH' connection_id = '0400' BINARY SEARCH INTO DATA(flight). ``` For `BINARY SEARCH` to be correct, the standard table must already be sorted in ascending order with a compatible leading field sequence. If later code changes the order, the search contract silently becomes fragile. Prefer a sorted table or named sorted secondary key when repeated optimized key access is part of the data model. Use one-off `SORT` plus `BINARY SEARCH` only when the local lifecycle makes the ordering invariant obvious. --- ## 12. Aggregation with `COLLECT` `COLLECT` finds a line using the internal table's **primary key**. If found, it adds the source's numeric non-key components to the existing line. If not found, it inserts the line. ```abap TYPES: BEGIN OF ty_route_total, city_from TYPE c LENGTH 40, city_to TYPE c LENGTH 40, revenue TYPE decfloat34, END OF ty_route_total. TYPES ty_route_totals TYPE HASHED TABLE OF ty_route_total WITH UNIQUE KEY primary_key COMPONENTS city_from city_to. DATA route_totals TYPE ty_route_totals. LOOP AT flights_seq INTO DATA(flight). COLLECT VALUE ty_route_total( city_from = flight-city_from city_to = flight-city_to revenue = flight-price ) INTO route_totals. ENDLOOP. ``` All components outside the primary key must be numeric for this aggregation form. An explicit sorted or hashed key makes the aggregation identity and lookup behavior clearer than relying on a standard table's implicit standard key. Do not confuse ABAP `COLLECT` with database aggregation. When a large dataset can be aggregated correctly by the database, prefer `SELECT ... GROUP BY` so fewer rows cross into application-server memory. --- ## 13. Modern Group Processing Prefer `LOOP AT ... GROUP BY` over legacy control-break processing when writing new code. Grouping is explicit and does not depend on physical component order or temporary masking of work-area fields. ```abap LOOP AT flights_seq INTO DATA(flight) GROUP BY ( carrier_id = flight-carrier_id members = GROUP SIZE ) ASSIGNING FIELD-SYMBOL(<carrier_group>). DATA(total_price) = REDUCE decfloat34( INIT total = CONV decfloat34( 0 ) FOR member IN GROUP <carrier_group> NEXT total += member-price ). " <carrier_group>-carrier_id, <carrier_group>-members, total_price ENDLOOP. ``` Grouping happens in two phases: ABAP assigns rows to group keys, then iterates over the groups. Member iteration uses `LOOP AT GROUP` or `FOR ... IN GROUP`. ### 13.1 Modern table transformations Constructor and iteration expressions can make pure transformations concise: ```abap DATA(lh_flights) = VALUE ty_flights_seq( FOR flight IN flights_seq WHERE ( carrier_id = 'LH' ) ( flight ) ). ``` Use expression syntax when it makes the transformation clearer. A conventional loop is still appropriate when error handling, tracing, or several side effects would make one expression difficult to understand. --- ## 14. Legacy Constructs You Must Recognize ### 14.1 Header lines ```abap " Obsolete — recognize it; do not introduce it DATA old_flights TYPE STANDARD TABLE OF ty_flight WITH HEADER LINE. ``` This declaration creates both: ```text old_flights implicit single-line header area old_flights[] internal table body ``` That name collision makes statements ambiguous: ```abap CLEAR old_flights. " Historically addresses the header line CLEAR old_flights[]. " Addresses the table body ``` Header-line declarations are obsolete and are not allowed in classes. Modern code uses an explicit table plus an explicit work area, inline declaration, or field symbol. ### 14.2 `AT NEW`, `AT END OF`, and `SUM` Legacy control-break events include: - `AT FIRST` - `AT NEW component` - `AT END OF component` - `AT LAST` They depend on the processing order and on the component order of the row structure. During classic control-break blocks, character-like components to the right of the break component can be represented by asterisks and other components can receive initial values temporarily. This behavior is one reason the code is difficult to maintain. When reading old code: 1. inspect the row-type component order; 2. inspect the table's actual processing order; 3. identify the exact break component; 4. check which values are valid inside the event block; 5. inspect any `SUM` behavior carefully. For new code, prefer explicit `GROUP BY` and `REDUCE`. --- ## 15. Database and RAP Boundaries ### 15.1 Avoid `SELECT` inside a loop ```abap " Avoid repeated database round trips LOOP AT requests INTO DATA(request). SELECT SINGLE ... WHERE request_uuid = @request-request_uuid ... ENDLOOP. ``` Prefer set-oriented retrieval using a join, association, subquery, range, or a carefully guarded `FOR ALL ENTRIES`, depending on the problem and release. When using `FOR ALL ENTRIES`: - guard against an initial driver table; - select only necessary columns; - understand duplicate elimination and key semantics; - measure against a join or other set-oriented alternative. ### 15.2 Internal table versus RAP transactional buffer RAP method parameters and EML results are represented using generated internal table types, but the RAP transactional buffer is a framework-managed business object state. It is not identical to one local variable such as `DATA(items)`. ```text Local internal table variable → ordinary ABAP runtime data RAP transactional buffer → framework-managed pending BO changes, addressed through EML ``` Changing a local EML result table does not change the business object. Use `MODIFY ENTITIES` when the BO state must change. --- ## 16. Performance Rules That Survive Interviews 1. **Choose the table category from access patterns.** Do not choose hashed only because the dataset is “large.” 2. **Use the key explicitly.** Optimized lookup depends on the key and search components actually used. 3. **Keep processing set-oriented.** Avoid repeated database access inside internal-table loops. 4. **Avoid unnecessary row copies.** Use `ASSIGNING` or `REFERENCE INTO` when direct access is the intended semantic, especially for wide/deep rows. 5. **Do not over-index.** Secondary keys consume memory and add mutation cost. 6. **Do not sort repeatedly.** If sorted access is a stable requirement, model it with a sorted table or secondary key. 7. **Push suitable filtering and aggregation to the database.** Internal tables are not a replacement for SQL execution on large persisted datasets. 8. **Measure material paths.** Runtime depends on row count, width, mutation frequency, selectivity, and release—not only theoretical complexity. --- ## 17. Common Failure Modes | Symptom | Likely cause | Correction | | ----------------------------------- | ----------------------------------------------------------- | ------------------------------------------------ | | Lookup is still slow | Search does not use a suitable primary/secondary key | Name the key and align the search components | | `BINARY SEARCH` misses a row | Standard table is not sorted compatibly | Sort correctly or model a sorted key | | Duplicate insert fails | Unique sorted/hashed key already exists | Handle `sy-subrc` or choose non-unique semantics | | Table expression dumps | Row is absent and exception/default was not handled | Use `TRY`, `OPTIONAL`, or `READ TABLE` | | Work-area change is lost | `LOOP ... INTO` created a copy | Write it back or use `ASSIGNING` intentionally | | Sorted/hashed key cannot be changed | Direct mutation would invalidate primary-key administration | Delete and reinsert with the new identity | | Duplicate deletion misses rows | Equal comparison values are not adjacent | Sort by the comparison identity first | | `COLLECT` groups unexpectedly | Primary table key does not match aggregation identity | Define an explicit unique key | | RAP BO did not change | Only a local result internal table was modified | Use EML `MODIFY ENTITIES` | --- ## 18. Compact Decision and Syntax Sheet ```text Declare a sequence STANDARD TABLE ... WITH EMPTY KEY Repeated ordered/range access SORTED TABLE ... WITH [NON-]UNIQUE KEY ... Exact unique lookup HASHED TABLE ... WITH UNIQUE KEY ... Read a copy READ TABLE ... INTO ... Read and mutate the row READ TABLE ... ASSIGNING ... Read with a durable reference READ TABLE ... REFERENCE INTO ... Expression lookup itab[ key = value ] Existence only line_exists( itab[ key = value ] ) Insert by table semantics INSERT line INTO TABLE itab Aggregate by explicit primary key COLLECT line INTO itab Group modern ABAP data LOOP AT itab ... GROUP BY ... ``` ### Useful whole-table operations ```abap " Value-copy one compatible table target_flights = source_flights. " Append all source lines APPEND LINES OF source_flights TO target_flights. " Current number of lines DATA(line_count) = lines( target_flights ). " Older statement form still encountered DESCRIBE TABLE target_flights LINES DATA(described_count). ``` 2c:T774,1. Mental Model: Type, Structure, Work Area, and Internal Table Do not treat these as four equivalent objects. text TYPES declaration defines a type; it does not hold runtime values │ ├── DATA structure one structured data object │ └── may serve as a work area │ └── DATA internal table zero or more lines of one line type 1.1 Structured type A structured type defines named components and their types. TYPES creates a type, not a runtime data object. abap TYPES: BEGIN OF tyflight, carrierid TYPE c LENGTH 3, connectionid TYPE n LENGTH 4, cityfrom TYPE c LENGTH 40, cityto TYPE c LENGTH 40, price TYPE p LENGTH 8 DECIMALS 2, currency TYPE c LENGTH 3, END OF tyflight. The type can be local, defined globally in a class/interface, or supplied by a released Dictionary/CDS artifact. SE11 is a classic Dictionary maintenance tool, not the definition of the ABAP concept itself. 1.2 Structure data object DATA instantiates a data object and therefore allocates runtime state. abap DATA flight TYPE tyflight. The word structure can mean either a structured type or a structured data object, depending on context. Say which one you mean in technical explanations. 1.3 Work area A work area is a role played by a single data object when a table statement copies one line into it or reads a line from it. It is not a separate ABAP type category. abap DATA flight TYPE tyflight. LOOP AT flights INTO flight. " flight is the work area for this loop ENDLOOP. 1.4 Internal table An internal table is an in-memory ABAP data object containing zero or more lines. Its type is defined by: 1. line type; 2. table category; 3. primary table key; 4. optional secondary table keys. It is not a database table and is not persisted by COMMIT WORK. Its lifetime follows the lifetime and scope of its owning ABAP data object. abap TYPES tyflights TYPE STANDARD TABLE OF tyflight WITH EMPTY KEY. DATA flights2d:T80f,## 1. Mental Model: Type, Structure, Work Area, and Internal Table Do not treat these as four equivalent objects. ```text TYPES declaration defines a type; it does not hold runtime values │ ├── DATA structure one structured data object │ └── may serve as a work area │ └── DATA internal table zero or more lines of one line type ``` ### 1.1 Structured type A structured type defines named components and their types. `TYPES` creates a type, not a runtime data object. ```abap TYPES: BEGIN OF ty_flight, carrier_id TYPE c LENGTH 3, connection_id TYPE n LENGTH 4, city_from TYPE c LENGTH 40, city_to TYPE c LENGTH 40, price TYPE p LENGTH 8 DECIMALS 2, currency TYPE c LENGTH 3, END OF ty_flight. ``` The type can be local, defined globally in a class/interface, or supplied by a released Dictionary/CDS artifact. `SE11` is a classic Dictionary maintenance tool, not the definition of the ABAP concept itself. ### 1.2 Structure data object `DATA` instantiates a data object and therefore allocates runtime state. ```abap DATA flight TYPE ty_flight. ``` The word **structure** can mean either a structured type or a structured data object, depending on context. Say which one you mean in technical explanations. ### 1.3 Work area A **work area** is a role played by a single data object when a table statement copies one line into it or reads a line from it. It is not a separate ABAP type category. ```abap DATA flight TYPE ty_flight. LOOP AT flights INTO flight. " flight is the work area for this loop ENDLOOP. ``` ### 1.4 Internal table An internal table is an in-memory ABAP data object containing zero or more lines. Its type is defined by: 1. line type; 2. table category; 3. primary table key; 4. optional secondary table keys. It is not a database table and is not persisted by `COMMIT WORK`. Its lifetime follows the lifetime and scope of its owning ABAP data object.2e:T809d, ## 1. The Four Levels of Modularization The word **module** is ambiguous. First identify what is being separated. ```text Repository / deployment organization Package and software component │ Architectural contract Class, interface, released API │ Callable processing block Method, function module, legacy FORM routine │ Source-text organization INCLUDE ``` | Level | Main question | Examples | | ---------------------- | --------------------------------------------------------------- | ------------------------------------- | | Package boundary | Which objects belong, depend on one another, and move together? | Package, software component | | Architectural boundary | What stable responsibility and contract are exposed? | Interface, global class, released API | | Procedure boundary | What inputs enter, what outputs leave, and what can fail? | Method, function module, `FORM` | | Source organization | In which source unit is this text maintained? | `INCLUDE` program | Splitting 2,000 lines into ten includes improves navigation, but does not by itself reduce shared state, coupling, side effects, or test difficulty. --- ## 2. Modern Decision Guide | Need | Preferred construct | Why | | -------------------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------- | | Business/domain logic in new development | Instance method behind an interface | Encapsulation, substitution, testing, dependency injection | | Stateless utility with no substitutable dependency | Static method, used selectively | Simple call without object state | | One calculated result | Functional method with `RETURNING` | Natural expression-oriented call | | Existing classic reusable API | Existing function module | Preserve the supported contract; wrap when useful | | RFC or update-task infrastructure that requires it | Appropriately configured function module | Function modules provide these classic runtime capabilities | | Organizing a large legacy program | Include program | Source separation only | | Reading old procedural code | `FORM`/`PERFORM` | Compatibility and controlled refactoring | | New RAP business logic | Behavior implementation method plus helper classes | Framework contract plus testable domain logic | Default rule for new code: ```text Interface → class → small cohesive methods ``` Do not introduce a function module or `FORM` merely because code must be reused. --- ## 3. Methods: The Primary Modern Procedure A method belongs to a class or interface. It has a statically known signature, visibility, parameter directions, typing, and exception contract. ### 3.1 Instance method ```abap INTERFACE zif_amount_calculator PUBLIC. METHODS calculate_net_amount IMPORTING quantity TYPE decfloat34 unit_price TYPE decfloat34 RETURNING VALUE(net_amount) TYPE decfloat34. ENDINTERFACE. CLASS zcl_amount_calculator DEFINITION PUBLIC FINAL CREATE PUBLIC. PUBLIC SECTION. INTERFACES zif_amount_calculator. ENDCLASS. CLASS zcl_amount_calculator IMPLEMENTATION. METHOD zif_amount_calculator~calculate_net_amount. net_amount = quantity * unit_price. ENDMETHOD. ENDCLASS. ``` Call: ```abap DATA(calculator) = NEW zcl_amount_calculator( ). DATA(net_amount) = calculator->zif_amount_calculator~calculate_net_amount( quantity = CONV decfloat34( '3' ) unit_price = CONV decfloat34( '12.50' ) ). ``` The interface expresses the consumer contract. The class expresses one implementation. Calling through the interface makes replacement and testing possible. ### 3.2 Static method ```abap CLASS-METHODS normalize_status IMPORTING raw_status TYPE string RETURNING VALUE(status) TYPE string. ``` Call: ```abap DATA(status) = zcl_status_helper=>normalize_status( raw_status ). ``` Static methods are suitable for genuinely stateless operations. Excessive static dependencies behave like globals: they are difficult to substitute and can make isolated tests harder. ### 3.3 Visibility | Visibility | Meaning | | ------------------- | ------------------------------------------- | | `PUBLIC SECTION` | Callable by external consumers | | `PROTECTED SECTION` | Accessible to the class and subclasses | | `PRIVATE SECTION` | Internal implementation detail of the class | Expose the smallest useful public contract. Test public behavior; do not make every helper public merely to call it from a test. ### 3.4 Functional methods A functional method has exactly one `RETURNING` parameter and can appear in an expression. ```abap METHODS calculate_total IMPORTING items TYPE ztt_order_item RETURNING VALUE(total) TYPE decfloat34. DATA(total) = calculator->calculate_total( items ). ``` The return value is completely typed and passed by value. Use `EXPORTING` or `CHANGING` parameters only when the procedure naturally produces several outputs or intentionally updates caller-owned state. --- ## 4. Method Interfaces and Parameter Directions Directions are named from the **callee's** perspective. | Formal parameter in method | Callee meaning | Caller clause | | -------------------------- | -------------------------------------------------- | ------------------------------------------------ | | `IMPORTING` | Method receives input | `EXPORTING` or omitted in functional call syntax | | `EXPORTING` | Method produces output | `IMPORTING` | | `CHANGING` | Method receives and returns the same logical value | `CHANGING` | | `RETURNING` | Functional result | Operand position or `RECEIVING` | Example: ```abap METHODS determine_status IMPORTING current_quantity TYPE i EXPORTING reason TYPE string CHANGING status TYPE string. service->determine_status( EXPORTING current_quantity = quantity IMPORTING reason = DATA(reason) CHANGING status = status ). ``` The caller's keywords are not an arbitrary “inversion.” Both sides describe the same flow from their own perspective. ### 4.1 Optional and default parameters Method input and changing parameters can be optional or have defaults where the language permits. ```abap METHODS format_amount IMPORTING amount TYPE decfloat34 currency TYPE c LENGTH 3 DEFAULT 'EUR' show_currency TYPE abap_bool OPTIONAL RETURNING VALUE(text) TYPE string. ``` Inside a procedure, `IS SUPPLIED` distinguishes an omitted optional parameter from one supplied with its type-initial value. Use optional parameters carefully. Too many independent options often indicate that the method has several responsibilities or needs a parameter object. --- ## 5. Parameter Passing: Reference, Value, and Value-Result Parameter direction and parameter passing are different dimensions. ```text Direction: IMPORTING / EXPORTING / CHANGING / RETURNING Passing: by reference / by value / value-result behavior ``` ### 5.1 Pass by reference The formal parameter refers to the actual parameter. No independent parameter copy is created for the procedure contract. - Changes through an output-capable reference parameter affect the caller. - Aliasing can create side effects when the same object is reachable through several paths. - Input parameters should be treated as inputs according to their contract. ### 5.2 Pass by value `VALUE(parameter)` creates a local formal parameter. Input values are copied in; output-capable values are copied back only when procedure processing completes successfully. For large or deep data, do not assume an immediate physical copy of every byte: the ABAP runtime can optimize copying internally. Choose semantics first and measure important paths. ### 5.3 Value-result For an output-capable `VALUE(...)` parameter, the procedure works on a local value and transfers the result to the caller at successful completion. If an exception ends the procedure before successful completion, that copy-back does not occur. ### 5.4 Prefer intention-revealing interfaces ```text Input only → IMPORTING One new result → RETURNING Several new results → EXPORTING or a result structure Intentional in/out → CHANGING ``` Do not use `CHANGING` as a convenient substitute for designing a result. --- ## 6. Class-Based Exceptions Declare failures that the caller can reasonably handle. ```abap METHODS submit_request IMPORTING request_uuid TYPE sysuuid_x16 RAISING zcx_request_invalid zcx_request_unauthorized. ``` ```abap TRY. service->submit_request( request_uuid ). CATCH zcx_request_invalid INTO DATA(invalid_error). DATA(message) = invalid_error->get_text( ). CATCH zcx_request_unauthorized INTO DATA(auth_error). message = auth_error->get_text( ). ENDTRY. ``` Use class-based exceptions for exceptional failure paths. Do not return a Boolean plus an unrelated global message when the caller needs structured error information. In RAP behavior methods, follow the generated `FAILED` and `REPORTED` contract for business-operation failures instead of replacing it with an arbitrary exception design. --- ## 7. Includes: Source Organization, Not Encapsulation An include program is an ABAP repository source object that cannot be compiled independently. `INCLUDE name.` incorporates its source into the compilation unit of the including program. ```abap REPORT zorder_report. INCLUDE zorder_report_top. " declarations INCLUDE zorder_report_sel. " selection screen INCLUDE zorder_report_cls. " local classes ``` Conceptually: ```text Main source + included source units ↓ activation/compilation One compilation unit ``` ### 7.1 What an include does - Splits a large source into separately maintained source units. - Participates in the including program's compilation and syntax context. - Can organize declarations, procedural blocks, local classes, or event logic. - Cannot execute independently. ### 7.2 What an include does not do - It does not define a callable interface merely by being an include. - It does not create a runtime call or stack frame. - It does not isolate global variables from the including program. - It does not make logic reusable in the architectural sense. - It does not automatically improve unit testability. Declarations in an include have the visibility and scope produced by their position in the combined program. Source order therefore matters. ### 7.3 Parameters An include itself has no parameter interface. A method or legacy `FORM` written inside an include can have parameters because that procedure—not the include— defines the call boundary. ### 7.4 Activation An include must be syntax-checked in a compilation-unit context. When it changes, activate the include and affected owning repository objects as a consistent change set. Do not claim that an include is independently compiled or that every include change always requires a manual activation of every main program; tooling and dependency handling vary by development environment. ### 7.5 Reuse warning SAP recommends assigning an include program to one compilation unit. Reusing the same include across unrelated programs creates hidden dependencies on global declarations, program type, source order, and event context. Extract a class or interface when reuse is the real requirement. --- ## 8. Subroutines: Legacy `FORM` and `PERFORM` SAP classifies subroutines as obsolete. You must recognize and safely maintain them in classic code, but use methods for new designs. ```abap PERFORM calculate_net USING quantity unit_price CHANGING net_amount. FORM calculate_net USING quantity TYPE decfloat34 unit_price TYPE decfloat34 CHANGING net_amount TYPE decfloat34. net_amount = quantity * unit_price. ENDFORM. ``` At `PERFORM`, control enters the `FORM`, executes it, and returns after the call. ### 8.1 Scope - A subroutine is implemented outside classes. - It normally belongs to its program's procedural context. - It can directly access that program's global data, which creates hidden input and output channels. - Data declared inside the `FORM` is local to a call; `STATICS` data persists across calls in the relevant internal session. `PERFORM ... IN PROGRAM` can call a subroutine in another program, but creates a fragile cross-program dependency. Do not use it as a modern public API. ### 8.2 Subroutine parameter passing | Declaration | Passing behavior | Caller effect | | ------------------- | -------------------- | ---------------------------------------------------------------- | | `USING p` | Reference by default | A write can affect caller state, despite the input-oriented name | | `USING VALUE(p)` | Value | Local copy; caller is not changed | | `CHANGING p` | Reference by default | Writes immediately affect caller state | | `CHANGING VALUE(p)` | Value-result | Local value copied back after successful completion | `USING` and `CHANGING` communicate intent; `VALUE(...)` determines value passing. A reference-passed `USING` parameter is not protected from writes by the language in the same way a strong immutable contract would be, so treat it as read-only by convention. ### 8.3 Typing Without explicit typing, a subroutine formal parameter is generically typed as `any`. This defers useful checks and allows failures to appear at runtime. ```abap " Avoid in maintained code FORM process USING input. " Better legacy form FORM process USING input TYPE ty_request. ``` Subroutines do not support modern optional/default parameter interfaces. Static calls should pass the declared parameter sequence exactly. Dynamic subroutine calls weaken static checks further and introduce injection risk if an external value controls the procedure/program name. ### 8.4 Obsolete `TABLES` parameters ```abap " Obsolete — recognize, do not introduce FORM process TABLES rows STRUCTURE zs_row. ``` Use typed `USING` or `CHANGING` parameters while maintaining a `FORM`, and use a class method when refactoring the design. ```abap TYPES ty_requests TYPE STANDARD TABLE OF ty_request WITH EMPTY KEY. FORM process USING requests TYPE ty_requests. " Read-only by convention ENDFORM. ``` --- ## 9. Function Modules A function module is a globally named procedure implemented inside a function group. Classic maintenance uses transaction `SE37`; function groups can be inspected with `SE80` or ADT tooling, depending on the environment. ```text Function group (function pool) ├── global data shared by its function modules ├── generated and developer-managed includes ├── Function Module A └── Function Module B ``` The function module has a public interface. The function group's global data is shared state within the loaded function pool and can make behavior order- dependent if misused. ### 9.1 Call direction Consider an illustrative custom function module whose interface imports an ID and exports a result: ```abap CALL FUNCTION 'Z_READ_REQUEST_STATUS' EXPORTING request_uuid = request_uuid IMPORTING status = status EXCEPTIONS not_found = 1 OTHERS = 2. IF sy-subrc <> 0. " Handle classic exception result ENDIF. ``` | Function-module interface | Caller uses | Flow | | ------------------------- | ------------------------------ | ------------------------ | | `IMPORTING request_uuid` | `EXPORTING request_uuid = ...` | Caller → function module | | `EXPORTING status` | `IMPORTING status = ...` | Function module → caller | | `CHANGING data` | `CHANGING data = ...` | Both directions | This is the same callee/caller perspective used for method calls. ### 9.2 Interface typing and runtime checks Function module names and interfaces are resolved at runtime by `CALL FUNCTION`, even when the name is a literal. Incorrect names, missing parameters, unknown parameters, length conflicts, and type conflicts therefore lead to dynamic-call exceptions or runtime errors such as: - `CALL_FUNCTION_NOT_FOUND` - `CALL_FUNCTION_PARM_MISSING` - `CALL_FUNCTION_PARM_UNKNOWN` - `CALL_FUNCTION_CONFLICT_TYPE` - `CALL_FUNCTION_CONFLICT_LENG` The sample's generic `ILLEGAL_TYPE_PARAM` label is not the useful diagnostic name for ordinary function-module parameter mismatches. Read the actual short dump and identify the formal and actual parameter types. ### 9.3 Optional parameters Unlike `FORM` routines, function module importing and changing parameters can be optional or have default values. Exporting parameters are optional to the caller. The function module can use `parameter IS SUPPLIED` where supported to distinguish omission from an initial value. ### 9.4 Exceptions #### Classic non-class-based exception ```abap CALL FUNCTION 'Z_READ_REQUEST_STATUS' EXPORTING request_uuid = request_uuid IMPORTING status = status EXCEPTIONS not_found = 1 OTHERS = 2. CASE sy-subrc. WHEN 0. " Success WHEN 1. " NOT_FOUND WHEN OTHERS. " Another mapped exception ENDCASE. ``` The numeric values are assigned by the caller. `sy-subrc = 1` has meaning only because this particular call maps `not_found = 1`. #### Class-based exception If the function module declares class-based exceptions, handle them with `TRY ... CATCH` according to its interface. ```abap TRY. CALL FUNCTION 'Z_READ_REQUEST_STATUS_NEW' EXPORTING request_uuid = request_uuid IMPORTING status = status. CATCH zcx_request_not_found INTO DATA(error). DATA(message) = error->get_text( ). ENDTRY. ``` SAP considers non-class-based exceptions a compatibility mechanism. Do not define them for new general-purpose APIs when a class-based contract is available and supported by the invocation type. ### 9.5 Obsolete `TABLES` interface parameters The `TABLES` parameter style is legacy and reference-based. New interfaces use typed importing, exporting, changing, or returning parameters. Be especially careful with RFC restrictions: remote-enabled interfaces have serialization and type constraints beyond local calls. --- ## 10. Specialized Function-Module Runtime Modes Function modules remain important where the platform explicitly requires their runtime capabilities. ### 10.1 Remote-enabled function module (RFC) ```abap CALL FUNCTION 'Z_REMOTE_OPERATION' DESTINATION destination EXPORTING input = input IMPORTING output = output EXCEPTIONS system_failure = 1 MESSAGE system_message communication_failure = 2 MESSAGE communication_message OTHERS = 3. ``` RFC introduces a serialization and communication boundary. Never pass an untrusted external string directly as a dynamic function or destination name. Validate allowlisted values and use supported communication configuration. ### 10.2 Update function module ```abap CALL FUNCTION 'Z_WRITE_AUDIT' IN UPDATE TASK EXPORTING audit_entry = audit_entry. ``` An update function module registers work for update processing associated with the SAP LUW. It has strict interface and execution rules. Do not replace an ordinary method call with `IN UPDATE TASK` merely to make it asynchronous. ### 10.3 Background/asynchronous mechanisms Classic asynchronous RFC, background tasks, bgRFC, qRFC, application jobs, and events solve different reliability and sequencing problems. “Function module” alone does not imply remote, asynchronous, or transactional behavior; the call variant and module attributes matter. --- ## 11. Other Legacy Processing Blocks ### 11.1 Macros ```abap DEFINE set_status. &1-status = &2. END-OF-DEFINITION. ``` Macros are source-level substitution constructs with positional placeholders, not typed procedures. They can obscure control flow and tooling. Recognize them in old code; prefer methods for new logic. ### 11.2 Dialog modules ```abap MODULE validate_screen_input INPUT. " Classic dynpro PAI logic ENDMODULE. ``` `MODULE ... ENDMODULE` processing blocks are called by classic screen flow logic (`PBO`/`PAI`). They are relevant to dynpro maintenance, not a preferred general-purpose reuse mechanism. ### 11.3 Event blocks Blocks such as `START-OF-SELECTION` define framework-driven program events. They are entry points, not reusable APIs. Keep them thin and delegate coherent logic to methods. --- ## 12. Scope and State | Location | Typical lifetime/visibility | Main risk | | -------------------------- | -------------------------------- | ------------------------------------------- | | Method local `DATA` | One invocation | Low; explicit local state | | Instance attribute | Object lifetime | Hidden mutation if responsibility is broad | | Static/class attribute | Internal-session/class lifetime | Global-style coupling and test interference | | Program global data | Program/internal-session context | Hidden inputs and outputs across procedures | | Function-group global data | Loaded function-pool context | Calls depend on prior calls/state | | `STATICS` local data | Retained across procedure calls | Surprising state and test-order dependence | The phrase “local data is freed immediately on exit” is an oversimplification. Local names leave scope at procedure exit, but referenced objects, shared data, runtime optimizations, and garbage collection determine physical memory lifetime. Prefer explicit parameters and returned results over procedure access to global state. --- ## 13. Refactoring a `FORM` into a Class ### 13.1 Legacy form ```abap DATA orders TYPE ztt_order. DATA total TYPE decfloat34. FORM calculate_total. LOOP AT orders INTO DATA(order). total += order-net_amount. ENDLOOP. ENDFORM. ``` Hidden contract: ```text Input: global orders Output: global total Failure: undocumented ``` ### 13.2 First safe step: expose the contract ```abap FORM calculate_total USING orders TYPE ztt_order CHANGING total TYPE decfloat34. CLEAR total. LOOP AT orders INTO DATA(order). total += order-net_amount. ENDLOOP. ENDFORM. ``` ### 13.3 Modern result: functional method ```abap METHODS calculate_total IMPORTING orders TYPE ztt_order RETURNING VALUE(total) TYPE decfloat34. METHOD calculate_total. total = REDUCE decfloat34( INIT sum = CONV decfloat34( 0 ) FOR order IN orders NEXT sum += order-net_amount ). ENDMETHOD. ``` The improvement is not the shorter syntax. The method has an explicit input, one explicit result, no dependency on program global state, and a contract that can live behind an interface. --- ## 14. Testable Modular Design Merely extracting code into a method does not make it testable. A method that calls the database, system date, authorization, external service, and output UI directly still has many hidden dependencies. ```text Application service ├── zif_order_repository ├── zif_authorization ├── zif_clock └── pure amount/status policy ``` Inject dependencies through a constructor or factory-visible seam: ```abap METHODS constructor IMPORTING repository TYPE REF TO zif_order_repository authorization TYPE REF TO zif_order_authorization. ``` Then ABAP Unit tests can supply doubles implementing those interfaces. ### Design properties - **High cohesion:** one module owns one closely related responsibility. - **Low coupling:** consumers depend on small contracts, not implementation globals. - **Explicit dependencies:** database, time, authorization, and external calls are visible. - **Explicit effects:** mutation and persistence are not hidden in a “helper.” - **Stable abstraction:** names express business intent, not implementation steps such as `do_processing_2`. --- ## 15. Transaction Ownership A reusable procedure should not issue `COMMIT WORK` or `ROLLBACK WORK` unless its documented contract truly owns the complete SAP LUW. Otherwise it can prematurely commit changes made by its caller. ```text Caller/application boundary starts orchestration ├── validate ├── calculate ├── persist/register changes └── decide transaction completion ``` This is especially important when wrapping legacy function modules: inspect whether the called API performs commits, registers update tasks, sends messages, or mutates function-group global state. --- ## 16. Modularization in RAP ### 16.1 Framework entry points A RAP behavior pool is an ABAP class pool. The framework calls generated handler/saver method signatures based on the behavior definition. ```text Behavior definition declares operation/action/validation/determination ↓ RAP runtime invokes generated behavior-handler method ↓ Behavior method orchestrates EML and domain helpers ``` Do not rename generated method parameters or invent an unrelated callable name; the framework contract determines the signature. ### 16.2 Keep behavior methods thin enough ```abap METHOD validate_customer. " 1. Read required BO state with EML " 2. Delegate pure/customer-existence decision where useful " 3. Fill FAILED and REPORTED according to RAP contract ENDMETHOD. ``` Good extraction candidates include: - deterministic calculations; - state-transition policies; - message construction; - adapters around released external APIs; - repository/query logic with a test seam. Keep `%tky`, `%cid`, `%is_draft`, `FAILED`, `MAPPED`, and `REPORTED` handling at the RAP boundary unless a dedicated helper abstraction genuinely improves it. ### 16.3 Transaction rule Do not execute `COMMIT WORK` inside RAP behavior implementation. RAP owns the save sequence and transaction boundary. A legacy function module that commits internally is therefore dangerous to call from a RAP interaction/save flow. ### 16.4 Local mode is not modularization `IN LOCAL MODE` changes EML authorization/feature-control handling inside the current BO implementation context. It does not make the called logic a separate module and does not bypass validations or the transactional buffer. --- ## 17. ABAP Cloud and Clean-Core Boundary ABAP Cloud uses a restricted language version and released APIs to provide lifecycle-stable development. For new cloud-ready code: - use classes, interfaces, and methods; - use ADT as the development environment; - depend only on objects released for the required contract; - check API State, not merely whether an object exists; - avoid obsolete syntax such as `FORM`/`PERFORM`; - do not call an unreleased classic function module directly from clean-core code; - wrap permitted classic dependencies only within an intentional migration tier in applicable private/on-premise scenarios. A function module is not automatically forbidden because it is old, and a class is not automatically clean-core because it is object-oriented. The decisive questions are release state, allowed language version, and stability contract. --- ## 18. Naming Guidance Prefixes such as `iv_`, `ev_`, `cv_`, `lt_`, and `gt_` are team conventions, not ABAP language requirements. Use names that expose intent: ```abap METHODS calculate_total IMPORTING items TYPE ztt_order_item RETURNING VALUE(total) TYPE decfloat34. ``` This is usually clearer than encoding every implementation detail: ```abap METHODS calc IMPORTING it_data TYPE ztt_order_item RETURNING VALUE(rv_val) TYPE decfloat34. ``` Follow the project's agreed style consistently, but do not mistake prefixes for encapsulation or type safety. --- ## 19. Common Failure Modes | Symptom | Likely cause | Diagnostic direction | | ----------------------------------------- | ------------------------------------------------------------------- | -------------------------------------------------------------- | | Changing an include breaks several places | Shared source depends on different globals/contexts | Use where-used list; establish each compilation-unit contract | | `PERFORM` call dumps or behaves strangely | Parameter sequence/type mismatch or hidden globals | Compare caller/callee order and explicit types | | Function module call dumps | Missing, unknown, length-conflicting, or type-conflicting parameter | Read ST22 dump and compare SE37 interface with actual values | | `sy-subrc` handling is wrong | Caller mapped classic exceptions differently or checked too late | Read the exact `EXCEPTIONS` mapping immediately after the call | | Unit test depends on execution order | Static, global, `STATICS`, or function-group state | Reset/extract state; inject dependency | | Helper unexpectedly commits data | Procedure owns hidden transaction control | Inspect `COMMIT WORK`, update-task, RFC, and called APIs | | RAP transaction becomes inconsistent | Legacy call commits or bypasses BO contract | Keep transaction under RAP and use released/compatible APIs | | “Reusable” method cannot be reused | It reads globals, UI state, or database implicitly | Make inputs, outputs, effects, and dependencies explicit | | Static utility is impossible to fake | Consumer depends directly on static implementation | Introduce a small interface and instance collaborator | --- ## 20. Technical Review Workflow When reviewing a modularization problem: 1. **Identify the construct:** include, method, function module, `FORM`, macro, screen module, or event block. 2. **Identify the owner:** program, class, interface, function group, package, or framework. 3. **Write the real contract:** inputs, outputs, exceptions/messages, database effects, global state, commits, and external calls. 4. **Check call resolution:** static method, dynamic method, local/external `PERFORM`, local FM, RFC, update task, or framework callback. 5. **Check typing and parameter passing:** direction, reference/value, optional parameters, table types, and aliasing. 6. **Check lifecycle:** local invocation, object state, class/global state, function-group state, or internal session. 7. **Check test seam:** can dependencies be substituted without a real database, clock, authorization, or remote system? 8. **Check transaction ownership:** who is allowed to save, commit, or roll back? 9. **Check release contract:** is the dependency permitted in the target ABAP language version and API contract? 10. **Refactor by risk:** first expose hidden parameters and effects, then move behavior behind a method/interface. --- ## 21. Compact Syntax Sheet ```text Instance method object->method( ... ) Static method class=>method( ... ) Functional result DATA(result) = object->method( input ) Class-based failure TRY ... CATCH cx_... ENDTRY Include source INCLUDE source_name. Legacy subroutine PERFORM routine USING ... CHANGING ... FORM routine USING ... CHANGING ... ENDFORM. Function module CALL FUNCTION 'NAME' EXPORTING ... IMPORTING ... CHANGING ... EXCEPTIONS ... Remote function call CALL FUNCTION 'NAME' DESTINATION destination ... Update registration CALL FUNCTION 'NAME' IN UPDATE TASK ... ``` 2f:T93e,1. The Four Levels of Modularization The word module is ambiguous. First identify what is being separated. text Repository / deployment organization Package and software component │ Architectural contract Class, interface, released API │ Callable processing block Method, function module, legacy FORM routine │ Source-text organization INCLUDE | Level | Main question | Examples | | ---------------------- | --------------------------------------------------------------- | ------------------------------------- | | Package boundary | Which objects belong, depend on one another, and move together? | Package, software component | | Architectural boundary | What stable responsibility and contract are exposed? | Interface, global class, released API | | Procedure boundary | What inputs enter, what outputs leave, and what can fail? | Method, function module, FORM | | Source organization | In which source unit is this text maintained? | INCLUDE program | Splitting 2,000 lines into ten includes improves navigation, but does not by itself reduce shared state, coupling, side effects, or test difficulty. --- 2. Modern Decision Guide | Need | Preferred construct | Why | | -------------------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------- | | Business/domain logic in new development | Instance method behind an interface | Encapsulation, substitution, testing, dependency injection | | Stateless utility with no substitutable dependency | Static method, used selectively | Simple call without object state | | One calculated result | Functional method with RETURNING | Natural expression-oriented call | | Existing classic reusable API | Existing function module | Preserve the supported contract; wrap when useful | | RFC or update-task infrastructure that requires it | Appropriately configured function module | Function modules provide these classic runtime capabilities | | Organizing a large legacy program | Include program | Source separation only | | Reading old procedural code | FORM/PERFORM | Compatibility and controlled refactoring | | New RAP business logic | Behavior implementation method plus helper classes | Framework contract plus testable domain logic | Default rule for new code: text Interface → class → small cohesive methods Do30:Tc2b,## 1. The Four Levels of Modularization The word **module** is ambiguous. First identify what is being separated. ```text Repository / deployment organization Package and software component │ Architectural contract Class, interface, released API │ Callable processing block Method, function module, legacy FORM routine │ Source-text organization INCLUDE ``` | Level | Main question | Examples | | ---------------------- | --------------------------------------------------------------- | ------------------------------------- | | Package boundary | Which objects belong, depend on one another, and move together? | Package, software component | | Architectural boundary | What stable responsibility and contract are exposed? | Interface, global class, released API | | Procedure boundary | What inputs enter, what outputs leave, and what can fail? | Method, function module, `FORM` | | Source organization | In which source unit is this text maintained? | `INCLUDE` program | Splitting 2,000 lines into ten includes improves navigation, but does not by itself reduce shared state, coupling, side effects, or test difficulty. --- ## 2. Modern Decision Guide | Need | Preferred construct | Why | | -------------------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------- | | Business/domain logic in new development | Instance method behind an interface | Encapsulation, substitution, testing, dependency injection | | Stateless utility with no substitutable dependency | Static method, used selectively | Simple call without object state | | One calculated result | Functional method with `RETURNING` | Natural expression-oriented call | | Existing classic reusable API | Existing function module | Preserve the supported contract; wrap when useful | | RFC or update-task infrastructure that requires it | Appropriately configured function module | Function modules provide these classic runtime capabilities | | Organizing a large legacy program | Include program | Source separation only | | Reading old procedural code | `FORM`/`PERFORM` | Compatibility and controlled refactoring | | New RAP business logic | Behavior implementation method plus helper classes | Framework contract plus testable domain logic | Default rule for new code:31:T7fb5, ## 1. The Correct Overall Mental Model A classic executable report is **event-driven**. Source-code position does not mean that ABAP simply executes every line from top to bottom. The ABAP runtime framework raises events and calls the matching event blocks. The selection screen also creates a loop: ```text Program requested │ ▼ Program loaded into internal session, if not already loaded │ ├─ global/static initialization performed by runtime └─ LOAD-OF-PROGRAM event block, if defined │ ▼ INITIALIZATION │ ▼ AT SELECTION-SCREEN OUTPUT selection-screen PBO │ ▼ Selection screen displayed │ ▼ User action │ ├─ F4 help ───────────────► ON VALUE-REQUEST FOR field │ │ │ └─ redisplay loop │ ├─ F1 help ───────────────► ON HELP-REQUEST FOR field │ │ │ └─ redisplay loop │ ├─ Enter / pushbutton / │ radio USER-COMMAND ────► selection-screen PAI events │ │ │ └─ AT SELECTION-SCREEN OUTPUT │ → redisplay │ └─ Execute F8 ─────────────► selection-screen PAI validation │ ├─ validation error │ └─ OUTPUT → redisplay │ └─ validation succeeds └─ START-OF-SELECTION │ ├─ report application logic ├─ END-OF-SELECTION, if defined └─ output/list processing ``` The straight-line version from the initial draft omitted the redisplay cycle. `AT SELECTION-SCREEN OUTPUT` can run many times; `INITIALIZATION` normally runs once for that report execution before the standard selection screen first appears. --- ## 2. Report Source Layout Versus Runtime Order A maintainable report can be arranged like this: ```abap REPORT zsales_order_report. " Global declarations and selection-screen definition TABLES sscrfields. PARAMETERS: p_open RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND mode, p_all RADIOBUTTON GROUP mode. SELECT-OPTIONS s_order FOR vbak-vbeln. CLASS lcl_application DEFINITION FINAL. PUBLIC SECTION. CLASS-METHODS run. ENDCLASS. CLASS lcl_application IMPLEMENTATION. METHOD run. " Application orchestration ENDMETHOD. ENDCLASS. INITIALIZATION. " One-time selection defaults AT SELECTION-SCREEN OUTPUT. " Dynamic screen attributes before each display AT SELECTION-SCREEN. " Cross-field/action validation START-OF-SELECTION. lcl_application=>run( ). ``` The physical order improves readability, but runtime execution is determined by events. Each event block begins with an event keyword and ends at the next processing block or the end of the program; there is no `END-...` statement. Keep event blocks thin and delegate application logic to methods. This prevents the report framework, selection-screen state, database logic, and output logic from becoming one inseparable procedure. ### 2.1 Declaration-scope trap Most event blocks are not ordinary procedures. Declarations written inside them belong to the compilation unit's global declarations and remain visible in subsequent processing blocks. Selection-screen and logical-database event blocks are special runtime implementations that can allow local declarations, but a consistent design should still put working data inside called methods. ```abap START-OF-SELECTION. DATA result TYPE string. " Do not assume method-local lifecycle semantics lcl_application=>run( ). ``` The safe architectural rule is not “declare globals inside an event.” It is “use the event as a thin framework adapter and work locally inside methods.” --- ## 3. Phase 1 — Program Load ### 3.1 What “load” means When the executable program is first needed in an internal session, its load is made available and its global data context is initialized. Programs already loaded in the same internal session need not be loaded again simply because a procedure is called again. Do not confuse: ```text Repository activation/generation creates or updates executable program load Runtime loading brings the program into an internal session for execution ``` ### 3.2 `LOAD-OF-PROGRAM` Contrary to the draft statement, this is a definable event block: ```abap LOAD-OF-PROGRAM. " Rarely needed in an ordinary report ``` It is the program constructor event and occurs when the program is loaded into an internal session. It is not the normal place for user defaults or report business processing. Typical guidance: - Use declaration-time initialization for simple constants/default state. - Use `INITIALIZATION` for initial selection-screen values. - Use constructors for object initialization. - Avoid database updates, user interaction, commits, or large queries in `LOAD-OF-PROGRAM`. ### 3.3 Why it may run less often than expected `LOAD-OF-PROGRAM` is associated with loading the program, not every selection-screen redisplay. If the program remains loaded in the internal session, repeated calls or interactions do not imply repeated program-load events. --- ## 4. Phase 2 — `INITIALIZATION` `INITIALIZATION` occurs before the standard selection screen is first processed for the report execution. ```abap PARAMETERS p_date TYPE sy-datum. INITIALIZATION. p_date = sy-datum. ``` Good uses: - calculate initial date ranges; - choose a sensible initial radio button; - initialize selection-screen texts or pushbutton labels; - supply lightweight defaults that should occur once. Avoid: - repeatedly controlling whether a field is visible or editable; - expensive report data selection; - changing database state; - authorization enforcement that must also protect background execution or non-screen entry points. ### 4.1 `DEFAULT` versus `INITIALIZATION` ```abap PARAMETERS p_status TYPE c LENGTH 1 DEFAULT 'O'. ``` Use declaration `DEFAULT` for a static initial value. Use `INITIALIZATION` when the starting value requires runtime calculation. ### 4.2 Why not put dynamic screen logic here? `INITIALIZATION` does not run on every redisplay. If screen input readiness depends on the currently selected radio button, use `AT SELECTION-SCREEN OUTPUT`. Also distinguish an initial proposal from the effective runtime selection. Selection variants, SPA/GPA memory values, `SUBMIT` parameters, or previous user input can influence values later in the screen lifecycle. When debugging, inspect the value at `AT SELECTION-SCREEN OUTPUT` and again in PAI instead of assuming the value assigned during `INITIALIZATION` is still effective. --- ## 5. Phase 3 — Selection-Screen PBO `AT SELECTION-SCREEN OUTPUT` is the Process Before Output event of the selection screen. It runs directly before the screen is displayed and can run repeatedly. ```abap PARAMETERS: p_file RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND mode, p_order RADIOBUTTON GROUP mode, p_path TYPE string LOWER CASE MODIF ID fil, p_vbeln TYPE vbak-vbeln MODIF ID ord. AT SELECTION-SCREEN OUTPUT. LOOP AT SCREEN. CASE screen-group1. WHEN 'FIL'. screen-active = xsdbool( p_file = abap_true ). WHEN 'ORD'. screen-active = xsdbool( p_order = abap_true ). ENDCASE. MODIFY SCREEN. ENDLOOP. ``` `MODIF ID fil` is represented in `SCREEN-GROUP1` as uppercase `FIL`. ### 5.1 Common `SCREEN` fields | Field | Purpose | | --------------------------------------- | ----------------------------------------- | | `SCREEN-GROUP1` | Modification group from `MODIF ID` | | `SCREEN-ACTIVE` | Combined active/inactive control | | `SCREEN-INPUT` | Input enabled/disabled | | `SCREEN-INVISIBLE` | Visible/hidden behavior | | `SCREEN-REQUIRED` | Visual/required-state control | | `SCREEN-DISPLAY_3D` or other attributes | Release/UI-specific presentation controls | Always execute `MODIFY SCREEN` for a changed row of the special `SCREEN` table. ### 5.2 Idempotence rule Implement output logic so the correct screen state is recalculated from the current selection values on every PBO. Do not rely on the event running only once or on the previous display state. --- ## 6. Phase 4 — Screen Display and User Action After PBO, the selection screen is sent to the presentation layer. The user can enter values, request help, choose a command, press Enter, or execute. The action determines the next event path. “User does something” is therefore not one event. | User action | Important event path | | ------------------------------------------ | ------------------------------------------------------------- | | Press F4 on a field | `ON VALUE-REQUEST FOR field` | | Press F1 on a field | `ON HELP-REQUEST FOR field` | | Change radio/checkbox with `USER-COMMAND` | Selection-screen PAI; then redisplay | | Press a custom selection-screen pushbutton | Selection-screen PAI; then usually redisplay | | Press Enter | Selection-screen PAI; then redisplay | | Press Execute F8 | Selection-screen PAI; if valid, leave screen and start report | | Press Back/Exit/Cancel | Exit-command handling and screen termination path | --- ## 7. F4 Value Help: `ON VALUE-REQUEST` Use a custom value-request event only when Dictionary/search-help behavior does not already provide the correct F4 help. ```abap AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_path. p_path = lcl_file_dialog=>choose_file( ). ``` Flow: ```text User presses F4 on p_path → AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_path → custom logic proposes/sets a value → selection screen is displayed again ``` This is not the report's business validation event and does not proceed to `START-OF-SELECTION`. ### 7.1 Prefer metadata-driven value help If the parameter refers to a DDIC field with a search help, check table, or fixed domain values, the runtime can often supply value help automatically. Do not replace correct metadata with unnecessary custom F4 code. ### 7.2 Security rule Value help narrows or proposes input; it is not authorization enforcement and does not guarantee that submitted input is valid. Validate the final value and perform authorization checks at the execution boundary. --- ## 8. F1 Help: `ON HELP-REQUEST` ```abap AT SELECTION-SCREEN ON HELP-REQUEST FOR p_path. lcl_help=>show_path_explanation( ). ``` Use this only when standard field/documentation help is insufficient. Like F4, it is a help request, not successful report execution. --- ## 9. Radio Buttons and `USER-COMMAND` Changing a radio button does **not** necessarily cause an immediate server round trip. Associate a function code when the selection should trigger dynamic screen modification: ```abap PARAMETERS: p_file RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND mode, p_order RADIOBUTTON GROUP mode. ``` The command is assigned to the group through the first declared radio button. On selection: ```text Radio selection changes → function code MODE is sent → selection-screen PAI events run → AT SELECTION-SCREEN OUTPUT recalculates field state → screen is redisplayed ``` Access the function code through `SSCRFIELDS-UCOMM` in classic code: ```abap TABLES sscrfields. AT SELECTION-SCREEN. CASE sscrfields-ucomm. WHEN 'MODE'. " Usually no business execution here; allow redisplay ENDCASE. ``` Radio-button user commands are well suited to screen adaptation, not to running the main report. F8 remains the normal transition to report execution. --- ## 10. Phase 5 — Selection-Screen PAI and Validation PAI transfers input from the screen and raises the relevant `AT SELECTION-SCREEN` events. Think of validation as layers from narrow to broad. ```text Field or selection-criterion checks → end-of-multiple-selection checks → radio-button-group checks → block checks → generic AT SELECTION-SCREEN command/cross-field check ``` The exact triggered subset depends on the screen fields and user action. ### 10.1 Validate one parameter ```abap AT SELECTION-SCREEN ON p_vbeln. IF p_order = abap_true AND p_vbeln IS INITIAL. MESSAGE e001(zreport) WITH 'Enter a sales order'. ENDIF. ``` Use for a rule local to that field. A radio-button field is validated with the group event rather than an individual field event. ### 10.2 Validate a radio-button group ```abap AT SELECTION-SCREEN ON RADIOBUTTON GROUP mode. IF p_file = abap_false AND p_order = abap_false. MESSAGE e002(zreport) WITH 'Choose a mode'. ENDIF. ``` ### 10.3 Validate a block ```abap SELECTION-SCREEN BEGIN OF BLOCK criteria WITH FRAME TITLE text-t01. PARAMETERS p_vbeln TYPE vbak-vbeln. SELECT-OPTIONS s_date FOR sy-datum. SELECTION-SCREEN END OF BLOCK criteria. AT SELECTION-SCREEN ON BLOCK criteria. IF p_vbeln IS INITIAL AND s_date[] IS INITIAL. MESSAGE e003(zreport) WITH 'Enter an order or date range'. ENDIF. ``` ### 10.4 Validate a complete `SELECT-OPTIONS` criterion ```abap AT SELECTION-SCREEN ON END OF s_date. LOOP AT s_date ASSIGNING FIELD-SYMBOL(<date_range>). IF <date_range>-option = 'BT' AND <date_range>-low > <date_range>-high. MESSAGE e004(zreport) WITH 'Invalid date interval'. ENDIF. ENDLOOP. ``` The selection criterion is a range-like table containing `SIGN`, `OPTION`, `LOW`, and `HIGH`. Validate the whole selection table when intervals or multiple rows interact. ### 10.5 Generic `AT SELECTION-SCREEN` ```abap AT SELECTION-SCREEN. CASE sscrfields-ucomm. WHEN 'ONLI'. " Common Execute function code; verify in target context lcl_selection_validator=>validate( file_mode = p_file path = p_path order = p_vbeln ). WHEN 'MODE'. " Dynamic mode switch; return to screen ENDCASE. ``` Use the generic event for cross-field validation and command handling. Do not hard-code a function code without confirming the actual selection-screen context. --- ## 11. Validation Failure and Redisplay An error message during selection-screen validation prevents the transition to `START-OF-SELECTION` and returns control to the selection screen. ```text Execute F8 → PAI validation → MESSAGE E → validation stops → AT SELECTION-SCREEN OUTPUT → corrected screen displayed ``` This is why `AT SELECTION-SCREEN OUTPUT` must tolerate repeated execution. `OBLIGATORY` provides basic required-input checking, but it does not replace cross-field business validation, existence checks, or authorization checks. ### 11.1 Message types are context-sensitive `MESSAGE E`, `W`, `I`, `S`, `A`, and `X` do not have one universal control-flow meaning independent of their processing context. In selection-screen PAI, error messages can return the user to input. In other report phases, the same message type can have a different runtime consequence. Diagnose the event and dialog context, not only the letter. --- ## 12. Exit Commands Back, Exit, and Cancel are exit-type commands. Use the specialized event only when cleanup or confirmation is genuinely necessary: ```abap AT SELECTION-SCREEN ON EXIT-COMMAND. " Avoid validation that traps the user on a screen they are leaving ``` This event is designed to handle exit commands before ordinary selection-screen validation prevents leaving because of invalid field content. Do not perform report business processing here. --- ## 13. Phase 6 — `START-OF-SELECTION` After the user chooses Execute and selection-screen processing succeeds, the runtime raises `START-OF-SELECTION`. ```abap START-OF-SELECTION. lcl_application=>run( ). ``` This is the report's standard processing block and should usually be its thin application entry point. Typical application flow: ```text START-OF-SELECTION → create application/service objects → enforce execution authorization → convert selection-screen globals into an input structure → read data set-wise → apply business rules → prepare result model → render output ``` ### 13.1 Implicit `START-OF-SELECTION` Executable statements written before the first explicit processing block are assigned to an implicit `START-OF-SELECTION` block. If no explicit event blocks exist, all functional statements form the implicit standard event. Avoid this confusing layout: ```abap REPORT zbad_layout. DATA value TYPE i. value = 10. " Implicit START-OF-SELECTION START-OF-SELECTION. value += 1. " A separate explicit event block ``` Prefer an explicit event keyword and a thin method call so runtime placement is obvious. --- ## 14. `END-OF-SELECTION` Historically, `END-OF-SELECTION` marks processing after a logical database has finished supplying rows through `GET` events. ```abap END-OF-SELECTION. " Final processing after logical-database selection ``` Without a logical database, it follows standard selection processing but often adds no useful architectural boundary. Do not use it simply because its name sounds like the required end of every report. A modern report can orchestrate its complete flow from a method called at `START-OF-SELECTION`. --- ## 15. Logical-Database Events Older reports can be linked to a logical database and receive node data through events such as: ```abap GET node. " Process one logical-database node instance GET node LATE. " Process after subordinate nodes ``` Conceptual runtime: ```text START-OF-SELECTION → logical database reads nodes → GET parent → GET child → GET parent LATE → END-OF-SELECTION ``` Recognize this in legacy reports. For new data access, prefer explicit Open SQL, CDS entities, and released APIs according to the target development model. --- ## 16. Output and List Events ### 16.1 Simple/classic list `WRITE` produces classic list output. Page/list processing can raise events such as: - `TOP-OF-PAGE` - `END-OF-PAGE` - `AT LINE-SELECTION` - `AT USER-COMMAND` Interactive list events happen after initial report processing, in response to the user acting on the displayed list. They are not part of the selection- screen validation sequence. ### 16.2 ALV/SALV For tabular results, ALV/SALV typically provides sorting, filtering, totals, layout variants, and event callbacks. Keep retrieval and business logic independent from the chosen renderer so they can be tested without a GUI. ```text Selection model → application service → result table → ALV adapter ``` --- ## 17. Complete Worked Flow ```abap REPORT zorder_extract. TABLES sscrfields. PARAMETERS: p_order RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND mode, p_file RADIOBUTTON GROUP mode, p_vbeln TYPE vbak-vbeln MODIF ID ord, p_path TYPE string LOWER CASE MODIF ID fil. INITIALIZATION. p_order = abap_true. AT SELECTION-SCREEN OUTPUT. LOOP AT SCREEN. CASE screen-group1. WHEN 'ORD'. screen-active = xsdbool( p_order = abap_true ). WHEN 'FIL'. screen-active = xsdbool( p_file = abap_true ). ENDCASE. MODIFY SCREEN. ENDLOOP. AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_path. p_path = lcl_file_dialog=>choose_file( ). AT SELECTION-SCREEN. IF sscrfields-ucomm = 'ONLI'. IF p_order = abap_true AND p_vbeln IS INITIAL. MESSAGE e001(zreport) WITH 'Enter a sales order'. ENDIF. IF p_file = abap_true AND p_path IS INITIAL. MESSAGE e002(zreport) WITH 'Choose a file'. ENDIF. ENDIF. START-OF-SELECTION. lcl_application=>run( order_mode = p_order order = p_vbeln file_mode = p_file path = p_path ). ``` ### 17.1 Initial display ```text Program begins → INITIALIZATION selects order mode → OUTPUT activates p_vbeln and deactivates p_path → screen displayed ``` ### 17.2 User selects file mode ```text USER-COMMAND MODE → AT SELECTION-SCREEN handles round trip → OUTPUT deactivates p_vbeln and activates p_path → screen displayed again ``` ### 17.3 User presses F4 on path ```text F4 → ON VALUE-REQUEST FOR p_path → dialog result assigned → screen displayed again ``` ### 17.4 User presses Execute without a path ```text F8 / ONLI → AT SELECTION-SCREEN → MESSAGE E → START-OF-SELECTION does not run → OUTPUT → screen displayed for correction ``` ### 17.5 User presses Execute with valid input ```text F8 / ONLI → AT SELECTION-SCREEN validation succeeds → START-OF-SELECTION → lcl_application=>run( ) → result output ``` --- ## 18. Dialog, Background, and `SUBMIT` Are Different Entry Modes The main diagram describes an interactive SAP GUI execution. Reports can also run through a background job or `SUBMIT`. ### 18.1 Background job A job normally receives saved selection values through a variant and has no interactive user available for F4 help, popups, or correction dialogs. ```abap IF sy-batch = abap_true. " Use background-safe logging/output; never require a frontend file dialog ENDIF. ``` Selection-screen UI convenience is therefore not a reliable business-security boundary. Validate the effective execution input and authorization in a background-safe application layer. ### 18.2 `SUBMIT` ```abap SUBMIT ztarget_report WITH p_vbeln = order AND RETURN. ``` `SUBMIT` starts an executable program and supplies selection values. Additions such as `VIA SELECTION-SCREEN`, `USING SELECTION-SET`, background-job options, and list export change the invocation behavior. Dynamic report names are a security risk when they originate externally. Use an allowlist and proper authorization checks. ### 18.3 Design consequence Do not place core business rules only in F4 handlers, screen PBO, or GUI-only validation. Extract an application service that can receive the same input from dialog, job, test, or another allowed entry point. --- ## 19. Selection Screen Versus Application Validation | Concern | Selection-screen layer | Application/domain layer | | --------------------------- | -------------------------- | ---------------------------------------- | | Enable/disable a field | Yes | No | | Show F4 help | Yes | No | | Basic cross-field usability | Yes | Often repeated as invariant if important | | Authorization to read order | May provide early feedback | Must enforce before protected access | | Business invariant | Helpful early feedback | Must be authoritative | | Database consistency | No | Persistence/transaction boundary | | Background-safe execution | Not guaranteed | Required | This parallels RAP: UI metadata and value help improve interaction, while the backend business object must still enforce invariants and authorization. --- ## 20. Program Structure Recommendation ```text Executable report ├── selection-screen declarations ├── INITIALIZATION initial UI defaults ├── AT SELECTION-SCREEN OUTPUT dynamic UI state ├── AT SELECTION-SCREEN ... early input feedback └── START-OF-SELECTION thin application entry │ ▼ Application class ├── authorization ├── input validation ├── query/repository ├── domain transformation └── output adapter ``` Use includes only for source organization when necessary. They do not replace the method/class boundaries described in the [ABAP Modularization reference](./abap-modularization-technical-reference.md). Use explicit internal-table types and access patterns from the [ABAP Internal Tables reference](./abap-internal-tables-technical-reference.md). --- ## 21. Transaction and Side-Effect Rules - Do not update persistent business data during `INITIALIZATION` or screen PBO. - F4/F1 handlers should provide help, not perform commits. - Separate report/query output from update transactions where possible. - If the report performs updates, document authorization, locking, validation, update API, commit ownership, restart behavior, and audit logging. - Do not call `COMMIT WORK` inside a reusable helper that does not own the whole SAP LUW. - A report that calls a BAPI/function module must inspect whether that API performs commits or expects the caller to commit. - For RAP business objects, use EML and allow RAP to own its transaction model; do not reproduce RAP save behavior in a classic report. --- ## 22. Debugging and Operations Map | Need | Classic tool/transaction | Evidence | | --------------------------- | ------------------------------------------------------- | ------------------------------------------- | | Execute/test report | `SE38` or `SA38` | Selection values, event behavior, output | | Repository navigation | `SE80` or ADT | Program, includes, classes, where-used | | Debug event sequence | ADT/SAP GUI debugger | Breakpoints in each event block; call stack | | Analyze short dump | `ST22` | Runtime error, source position, call stack | | Runtime performance | `SAT` | Call hierarchy and ABAP runtime cost | | SQL trace | `ST05` | SQL statements, executions, rows, duration | | System-wide SQL aggregation | `SQLM` where available | Repeated SQL workload evidence | | Background execution | `SM37` | Job step, variant, spool, status, job log | | Authorization failure | `SU53` immediately after failure; trace when authorized | Failed authorization objects/fields | | Application log | `SLG1` when the report writes application logs | Durable business/technical messages | ### 22.1 Event-flow debugging sequence 1. Set breakpoints in `LOAD-OF-PROGRAM`, `INITIALIZATION`, `AT SELECTION-SCREEN OUTPUT`, the relevant field/value-help event, generic `AT SELECTION-SCREEN`, and `START-OF-SELECTION`. 2. Start a new execution context and record which breakpoints occur. 3. Trigger a radio-button user command and observe the PAI → PBO redisplay loop. 4. Trigger F4 and distinguish its request path. 5. Execute once with invalid input and prove that `START-OF-SELECTION` is not reached. 6. Execute with valid input and inspect the transition to the application method. 7. Repeat in background only after removing GUI-dependent assumptions. --- ## 23. Common Misinterpretations | Misinterpretation | Correction | | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | “ABAP executes a report top to bottom.” | The runtime invokes event blocks according to the report and screen lifecycle. | | “`LOAD-OF-PROGRAM` is implicit and cannot be defined.” | It is a definable program-constructor event, though rarely needed in an ordinary report. | | “`INITIALIZATION` runs before every display.” | It initializes before the first standard-screen processing; PBO can repeat. | | “Changing any radio button immediately triggers an event.” | Immediate round trip requires an associated `USER-COMMAND` or another screen command. | | “F4 executes `AT SELECTION-SCREEN` like F8.” | Custom F4 uses `ON VALUE-REQUEST`; it does not start report execution. | | “`OUTPUT` means report result output.” | `AT SELECTION-SCREEN OUTPUT` is selection-screen PBO before display. | | “Every `AT SELECTION-SCREEN` event always runs.” | The triggered variants depend on fields and the user's action. | | “F8 directly calls `START-OF-SELECTION`.” | Selection-screen PAI and validation must succeed first. | | “`END-OF-SELECTION` is mandatory.” | It is especially meaningful with logical databases and is not required for every report. | | “A required screen field enforces the business rule everywhere.” | Screen checks do not replace application authorization and invariants. | | “Report event blocks are local procedures.” | Most event blocks work with compilation-unit global data; keep them thin. | | “The same interactive flow occurs in background.” | Background processing has no user-driven F4 or correction loop. | --- ## 24. Compact Event Reference | Event | Frequency/trigger | Main responsibility | | -------------------------------- | ------------------------------------------------- | -------------------------------------- | | `LOAD-OF-PROGRAM` | When program is loaded into internal session | Rare program-constructor logic | | `INITIALIZATION` | Before first standard selection-screen processing | Initial selection defaults | | `AT SELECTION-SCREEN OUTPUT` | Before every relevant display | Dynamic screen attributes | | `... ON VALUE-REQUEST FOR field` | User presses F4 | Custom value help | | `... ON HELP-REQUEST FOR field` | User presses F1 | Custom field help | | `... ON field` | Selection-screen PAI for field | Field validation | | `... ON END OF selcrit` | Whole selection criterion available | Multiple/range validation | | `... ON RADIOBUTTON GROUP group` | Radio group processed in PAI | Group validation | | `... ON BLOCK block` | Block processed in PAI | Related-field validation | | `AT SELECTION-SCREEN` | General PAI event | Command and cross-field validation | | `... ON EXIT-COMMAND` | Exit-type command | Safe leave/cleanup behavior | | `START-OF-SELECTION` | Selection processing succeeded | Main application entry | | `GET node` | Logical database provides node | Legacy logical-database row processing | | `END-OF-SELECTION` | Selection/logical DB processing completes | Legacy/final report processing | | List events | User/page activity on classic list | Classic output interaction | --- 32:T9dd,1. The Correct Overall Mental Model A classic executable report is event-driven. Source-code position does not mean that ABAP simply executes every line from top to bottom. The ABAP runtime framework raises events and calls the matching event blocks. The selection screen also creates a loop: text Program requested │ ▼ Program loaded into internal session, if not already loaded │ ├─ global/static initialization performed by runtime └─ LOAD-OF-PROGRAM event block, if defined │ ▼ INITIALIZATION │ ▼ AT SELECTION-SCREEN OUTPUT selection-screen PBO │ ▼ Selection screen displayed │ ▼ User action │ ├─ F4 help ───────────────► ON VALUE-REQUEST FOR field │ │ │ └─ redisplay loop │ ├─ F1 help ───────────────► ON HELP-REQUEST FOR field │ │ │ └─ redisplay loop │ ├─ Enter / pushbutton / │ radio USER-COMMAND ────► selection-screen PAI events │ │ │ └─ AT SELECTION-SCREEN OUTPUT │ → redisplay │ └─ Execute F8 ─────────────► selection-screen PAI validation │ ├─ validation error │ └─ OUTPUT → redisplay │ └─ validation succeeds └─ START-OF-SELECTION │ ├─ report application logic ├─ END-OF-SELECTION, if defined └─ output/list processing The straight-line version from the initial draft omitted the redisplay cycle. AT SELECTION-SCREEN OUTPUT can run many times; INITIALIZATION normally runs once for that report execution before the standard selection screen first appears. --- 2. Report Source Layout Versus Runtime Order A maintainable report can be arranged like this: abap REPORT zsalesorderreport. " Global declarations and selection-screen definition TABLES sscrfields. PARAMETERS: popen RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND mode, pall RADIOBUTTON GROUP mode. SELECT-OPTIONS sorder FOR vbak-vbeln. CLASS lclapplication DEFINITION FINAL. PUBLIC SECTION. CLASS-METHODS run. ENDCLASS. CLASS lclapplication IMPLEMENTATION. METHOD run. " Application orchestration ENDMETHOD. ENDCLASS. INITIALIZATION. " One-time selection defaults AT SELECTION-SCREEN OUTPUT. " Dynamic screen attributes before each display AT SELECTION-SCREEN. " Cross-field/action validation START-OF-SELECTION. lclapplication=run( ). The physical order improves readability, but runtime execution is determined by events. Each event block begins with an event keyword and ends at the next processing block or the end of33:Tc52,## 1. The Correct Overall Mental Model A classic executable report is **event-driven**. Source-code position does not mean that ABAP simply executes every line from top to bottom. The ABAP runtime framework raises events and calls the matching event blocks. The selection screen also creates a loop: ```text Program requested │ ▼ Program loaded into internal session, if not already loaded │ ├─ global/static initialization performed by runtime └─ LOAD-OF-PROGRAM event block, if defined │ ▼ INITIALIZATION │ ▼ AT SELECTION-SCREEN OUTPUT selection-screen PBO │ ▼ Selection screen displayed │ ▼ User action │ ├─ F4 help ───────────────► ON VALUE-REQUEST FOR field │ │ │ └─ redisplay loop │ ├─ F1 help ───────────────► ON HELP-REQUEST FOR field │ │ │ └─ redisplay loop │ ├─ Enter / pushbutton / │ radio USER-COMMAND ────► selection-screen PAI events │ │ │ └─ AT SELECTION-SCREEN OUTPUT │ → redisplay │ └─ Execute F8 ─────────────► selection-screen PAI validation │ ├─ validation error │ └─ OUTPUT → redisplay │ └─ validation succeeds └─ START-OF-SELECTION │ ├─ report application logic ├─ END-OF-SELECTION, if defined └─ output/list processing ``` The straight-line version from the initial draft omitted the redisplay cycle. `AT SELECTION-SCREEN OUTPUT` can run many times; `INITIALIZATION` normally runs once for that report execution before the standard selection screen first appears. --- ## 2. Report Source Layout Versus Runtime Order A maintainable report can be arranged like this: ```abap REPORT zsales_order_report. " Global declarations and selection-screen definition TABLES sscrfields. PARAMETERS: p_open RADIOBUTTON GROUP mode DEFAULT 'X' USER-COMMAND mode, p_all RADIOBUTTON GROUP mode. SELECT-OPTIONS s_order FOR vbak-vbeln. CLASS lcl_application DEFINITION FINAL. PUBLIC SECTION. CLASS-METHODS run. ENDCLASS. CLASS lcl_application IMPLEMENTATION. METHOD run. " Application orchestration ENDMETHOD. ENDCLASS. INITIALIZATION. " One-time selection defaults AT SELECTION-SCREEN OUTPUT. " Dynamic screen attributes before each display AT SELECTION-SCREEN. " Cross-field/action validation START-OF-SELECTION. lcl_application=>run( ). ```34:T7d7b, ## 1. What ALV Is — and Is Not ALV, the SAP List Viewer, is a presentation framework for structured datasets. It can supply standard user functions such as sorting, filtering, totals, subtotals, layouts, printing, and export. ```text Database / CDS / released API │ ▼ Application reads, authorizes, and derives data │ ▼ Internal table = report output model │ ▼ ALV renders List, Grid, or Tree │ ▼ User sorts, filters, selects, navigates, or edits ``` ALV does **not** by itself: - read the correct business data; - authorize a user to see or change that data; - enforce business invariants; - persist edited cells; - fix duplicate rows caused by an incorrect SQL join; - turn a classic report into a Fiori or RAP application. Think of ALV as the report's **view and interaction adapter**. The internal table is its input model; application methods own the business behavior. --- ## 2. End-to-End Runtime Flow For a read-only executable report using SALV: ```text Program/report starts │ ▼ Selection-screen lifecycle │ defaults → dynamic PBO → user input → validation ▼ START-OF-SELECTION │ ├─ authorize requested scope ├─ read through an appropriate CDS view/API/Open SQL ├─ calculate and map the output model └─ return an internal table │ ▼ CL_SALV_TABLE=>FACTORY │ ├─ configure functions, columns, sorts, layout, events └─ DISPLAY │ ▼ User sorts/filters/totals/exports or triggers navigation ``` For an editable GUI grid, the display is only half the workflow: ```text Application internal table │ ▼ CL_GUI_ALV_GRID display │ ▼ User edits a frontend cell │ ├─ REGISTER_EDIT_EVENT / DATA_CHANGED └─ CHECK_CHANGED_DATA transfers/checks pending frontend changes │ ▼ Application validates values and authorization │ ├─ invalid → protocol/message; do not save └─ valid → released update API / BAPI / application service / EML │ ▼ transaction owner commits │ ▼ refresh application data and ALV ``` The decisive point is: **an editable cell is not a database update**. `CHECK_CHANGED_DATA` is part of synchronizing/validating the grid state; it is not persistence. --- ## 3. The Three Presentation Shapes People often say “ALV list, grid, and tree.” These are presentation shapes, not three levels of the same report. | Shape | Data relationship | Best fit | Typical technology | | -------- | ------------------------------------------------ | ---------------------------------------- | -------------------------------------------------------------------------- | | **List** | Flat rows or classic two-level sequential output | Printing, spool, legacy reports | Classic ALV list; `CL_SALV_HIERSEQ_TABLE` for two-level header/item output | | **Grid** | Flat two-dimensional table | Interactive analysis; optionally editing | `CL_SALV_TABLE` or `CL_GUI_ALV_GRID` | | **Tree** | Nodes with explicit parent/child relationships | Hierarchy navigation | `CL_SALV_TREE` or `CL_GUI_ALV_TREE` | SAP's ALV object model names the core structural forms more precisely: - `CL_SALV_TABLE`: simple, two-dimensional table; - `CL_SALV_HIERSEQ_TABLE`: hierarchical-sequential header/item list; - `CL_SALV_TREE`: arbitrary tree structure. Therefore, “list versus grid” can also describe the **rendering technology** of a simple table, while table versus hierarchy describes the **data shape**. Ask which meaning a colleague intends before choosing a class. ### 3.1 List view A list-oriented result is appropriate when printable sequential output matters more than rich cell interaction. It is also the conceptually safer direction for a background job that must create spool output. For the SALV simple-table model, the factory's `LIST_DISPLAY` choice selects a classic list-style rendering instead of the normal fullscreen grid rendering: ```abap cl_salv_table=>factory( EXPORTING list_display = abap_true IMPORTING r_salv_table = DATA(alv) CHANGING t_table = output ). alv->display( ). ``` This is an important distinction: `CL_SALV_TABLE` identifies the simple two-dimensional **data model**; `LIST_DISPLAY` influences its **display mode**. Always test printing and background behavior on the target release rather than inferring it only from the class name. Classic APIs such as `REUSE_ALV_LIST_DISPLAY` and `REUSE_ALV_GRID_DISPLAY_LVC` still appear in existing systems. Their `SLIS_*` and `LVC_*` metadata must be understood for maintenance, but new OO-oriented code should normally consider the ALV object model first when its capabilities fit. ### 3.2 Grid view A grid displays a flat table with columns and rows. Choose: - `CL_SALV_TABLE` for concise, mostly read-only reporting; - `CL_GUI_ALV_GRID` when you need editable cells, detailed grid events, a custom toolbar, or precise embedding in a screen/container. ### 3.3 Tree view A tree represents real hierarchy. Each node has identity and a relationship to a parent node. Sorting a flat table and indenting text does not create a sound tree model. Examples: ```text Sales Order 50000123 ├─ Item 10 │ ├─ Schedule line 1 │ └─ Schedule line 2 └─ Item 20 └─ Schedule line 1 ``` Use `CL_SALV_TREE` for a high-level tree display and `CL_GUI_ALV_TREE` when the application needs lower-level control. Use `CL_SALV_HIERSEQ_TABLE` when the model is exactly two sequential levels, such as header and items, rather than an arbitrary-depth tree. --- ## 4. Selection Guide | Requirement | Recommended starting point | Reason | | --------------------------------------- | -------------------------------------------- | ---------------------------------------- | | Quick read-only flat report | `CL_SALV_TABLE` | Minimal setup and standard ALV functions | | Editable cells | `CL_GUI_ALV_GRID` | Supported grid edit/event lifecycle | | Custom toolbar and fine-grained events | `CL_GUI_ALV_GRID` | Direct Control Framework integration | | Arbitrary parent/child hierarchy | `CL_SALV_TREE` | Node-oriented hierarchy model | | Highly customized hierarchy control | `CL_GUI_ALV_TREE` | Lower-level tree behavior | | Exactly header + item sequential levels | `CL_SALV_HIERSEQ_TABLE` | Matches the two-level data shape | | Background/spool-oriented output | List/spool-safe design | GUI controls require a frontend | | Very large HANA-backed result | Consider ALV with IDA, if available/released | Pushes paging/filtering toward HANA | Do not choose `CL_GUI_ALV_GRID` merely because it is more powerful. Its screen, container, frontend-state, event, and lifetime responsibilities are real complexity. --- ## 5. The Output Internal Table Is a View Model Do not send a persistence table to ALV merely because it already has fields. Define the output grain and only expose columns that serve the report. ```abap TYPES: BEGIN OF ty_order_output, sales_order TYPE vbak-vbeln, sold_to_party TYPE vbak-kunnr, overall_status TYPE c LENGTH 1, net_amount TYPE p LENGTH 15 DECIMALS 2, currency TYPE waers, END OF ty_order_output, ty_order_output_tab TYPE STANDARD TABLE OF ty_order_output WITH EMPTY KEY. ``` The model should contain: - the business key needed for navigation or update; - display values at one explicitly chosen grain; - currency/unit reference fields for amounts and quantities; - optional technical style/color fields required by an editable grid; - no sensitive fields merely “hidden” from the initial layout. Hiding a field with `NO_OUT` or a saved layout is presentation, not security. Protect the read before building the output table, and assume export/layout features can reveal any field supplied to the frontend. ### 5.1 Preserve the grain If one order header is joined to ten items and the header amount repeats ten times, ALV totals will correctly total the rows it received—and produce the wrong business answer. Fix the query/output grain rather than blaming ALV. --- ## 6. `CL_SALV_TABLE`: Read-Only Table with Minimal Ceremony `CL_SALV_TABLE` is the normal first choice for a flat display-only report. The factory receives the output internal table, creates the ALV model, and returns the main SALV object. ```abap CLASS lcl_output DEFINITION FINAL. PUBLIC SECTION. CLASS-METHODS display CHANGING orders TYPE ty_order_output_tab. ENDCLASS. CLASS lcl_output IMPLEMENTATION. METHOD display. TRY. cl_salv_table=>factory( IMPORTING r_salv_table = DATA(alv) CHANGING t_table = orders ). alv->get_functions( )->set_all( abap_true ). alv->get_columns( )->set_optimize( abap_true ). alv->get_display_settings( )->set_striped_pattern( abap_true ). alv->display( ). CATCH cx_salv_msg INTO DATA(error). MESSAGE error->get_text( ) TYPE 'E'. ENDTRY. ENDMETHOD. ENDCLASS. ``` Typical caller: ```abap START-OF-SELECTION. DATA(orders) = lcl_order_query=>execute( sales_orders = s_vbeln[] ). lcl_output=>display( CHANGING orders = orders ). ``` ### 6.1 What SALV owns SALV offers subobjects for configuration: ```text CL_SALV_TABLE ├─ GET_FUNCTIONS( ) standard toolbar functions ├─ GET_COLUMNS( ) column collection ├─ GET_SORTS( ) initial sorting ├─ GET_AGGREGATIONS( ) totals/aggregations ├─ GET_SELECTIONS( ) selection behavior/state ├─ GET_DISPLAY_SETTINGS( ) general appearance ├─ GET_LAYOUT( ) layout variants └─ GET_EVENT( ) SALV events ``` ### 6.2 Configure one column ```abap TRY. DATA(columns) = alv->get_columns( ). DATA(column) = columns->get_column( 'NET_AMOUNT' ). column->set_short_text( 'Net' ). column->set_medium_text( 'Net Amount' ). column->set_long_text( 'Sales Order Net Amount' ). CATCH cx_salv_not_found. " Programming/configuration mismatch: field is not in the output model ENDTRY. ``` Names passed to SALV refer to the ABAP component names in the output line type, usually interpreted in uppercase. A DDIC-backed component lets ALV reuse field labels, conversion exits, value help, and type semantics more reliably than an unrelated primitive type. ### 6.3 SALV editing boundary The supported `CL_SALV_TABLE` public model is display-oriented. Do not rely on release-dependent or unsupported tricks that extract an underlying GUI grid to make SALV editable. If editing is a real requirement, choose `CL_GUI_ALV_GRID` and implement the complete edit, validation, authorization, and persistence lifecycle explicitly. --- ## 7. SALV Events: Navigation, Not Business Trust A SALV double-click can navigate to an order detail, but the row number is only presentation state. After users sort and filter, row position is not a stable business identity. Conceptual event-handler shape: ```abap CLASS lcl_salv_handler DEFINITION FINAL. PUBLIC SECTION. METHODS on_double_click FOR EVENT double_click OF cl_salv_events_table IMPORTING row column. ENDCLASS. ``` Registration: ```abap DATA(events) = alv->get_event( ). DATA(handler) = NEW lcl_salv_handler( ). SET HANDLER handler->on_double_click FOR events. ``` Keep the handler object alive for as long as the ALV can raise events. In the handler: 1. resolve the selected row against the current output model; 2. extract its business key; 3. recheck authorization and current state; 4. call an application navigation/action method. Never treat “the user could see or select row 5” as authorization to update the business object represented by row 5. --- ## 8. `CL_GUI_ALV_GRID`: Control-Based Grid Architecture `CL_GUI_ALV_GRID` is a SAP GUI Control Framework control. It requires a parent container and therefore participates in a dynpro's PBO/PAI lifecycle. ```text Executable report │ └─ CALL SCREEN 0100 │ ├─ PBO: create custom container once │ create grid once │ register handlers once │ first display once │ ├─ SAP GUI: user interacts with grid │ └─ PAI: synchronize changes and process command then return to PBO for refresh ``` Screen 0100 normally contains a Custom Control element named, for example, `ALV_CONTAINER`. ### 8.1 Persistent controller attributes The grid, container, event handler, and output table must outlive a single PBO method call. Keep them as suitable program-global references or, preferably, attributes of a screen-controller object. ```abap DATA: container TYPE REF TO cl_gui_custom_container, grid TYPE REF TO cl_gui_alv_grid, output TYPE ty_order_output_tab, field_catalog TYPE lvc_t_fcat, layout TYPE lvc_s_layo. ``` ### 8.2 PBO: create once, refresh later ```abap MODULE status_0100 OUTPUT. SET PF-STATUS 'MAIN'. IF grid IS INITIAL. container = NEW cl_gui_custom_container( container_name = 'ALV_CONTAINER' ). grid = NEW cl_gui_alv_grid( i_parent = container ). " Register event handlers here, before user interaction grid->set_table_for_first_display( EXPORTING is_layout = layout CHANGING it_outtab = output it_fieldcatalog = field_catalog ). ELSE. grid->refresh_table_display( is_stable = VALUE lvc_s_stbl( row = abap_true col = abap_true ) ). ENDIF. ENDMODULE. ``` SAP documents `SET_TABLE_FOR_FIRST_DISPLAY` as the initial binding operation. Call `REFRESH_TABLE_DISPLAY` when only the data changes. Repeat the initial call only when the output structure changes. ### 8.3 PAI: process commands ```abap MODULE user_command_0100 INPUT. CASE sy-ucomm. WHEN 'SAVE'. lcl_screen_controller=>save( ). WHEN 'BACK' OR 'EXIT' OR 'CANC'. LEAVE TO SCREEN 0. ENDCASE. ENDMODULE. ``` The GUI status decides which function codes exist. The ALV grid can also raise toolbar and `USER_COMMAND` events for grid-specific functions. --- ## 9. Field Catalog: Structural and UI Metadata `CL_GUI_ALV_GRID` commonly uses `LVC_T_FCAT`, whose line type is `LVC_S_FCAT`. Important fields include: | Field | Meaning | | -------------------------- | ------------------------------------------------ | | `FIELDNAME` | Component in the output line type | | `COLTEXT`, `SCRTEXT_S/M/L` | Column labels | | `KEY` | Visually identifies a key column | | `NO_OUT` | Initially hides a column; not a security control | | `EDIT` | Makes a cell/column input-enabled in the grid | | `HOTSPOT` | Enables hotspot interaction | | `CHECKBOX` | Displays a checkbox-compatible field | | `DO_SUM` | Requests totals where supported | | `REF_TABLE`, `REF_FIELD` | Reuses DDIC metadata | | `CFIELDNAME` | Currency-reference component for an amount | | `QFIELDNAME` | Unit-reference component for a quantity | You can let the grid derive metadata from a single DDIC structure by passing `I_STRUCTURE_NAME`, or pass an explicit field catalog for a local/mixed output type and custom UI behavior. Example helper: ```abap APPEND VALUE lvc_s_fcat( fieldname = 'NET_AMOUNT' coltext = 'Net Amount' cfieldname = 'CURRENCY' do_sum = abap_true ) TO field_catalog. ``` Metadata names must match the actual output structure. A field catalog does not map database fields into differently named ABAP components; build that mapping when selecting or transforming the output model. --- ## 10. Editable Grid Lifecycle Setting `EDIT = abap_true` only changes the frontend interaction. A complete edit flow has five separate responsibilities. ### 10.1 Enable and register ```abap grid->register_edit_event( i_event_id = cl_gui_alv_grid=>mc_evt_modified ). SET HANDLER handler->on_data_changed FOR grid. ``` Common grid events include `DATA_CHANGED`, `DATA_CHANGED_FINISHED`, `DOUBLE_CLICK`, `HOTSPOT_CLICK`, `TOOLBAR`, and `USER_COMMAND`. ### 10.2 Validate pending changes Before a Save command uses the output table, synchronize pending frontend edits: ```abap DATA valid TYPE abap_bool. grid->check_changed_data( IMPORTING e_valid = valid ). CHECK valid = abap_true. ``` This is especially important when a user types into a cell and immediately presses Save without first leaving the cell or pressing Enter. ### 10.3 Separate UI checks from business checks The `DATA_CHANGED` handler can give immediate feedback about syntax, domains, or cross-cell relationships. The application service must still enforce: - current authorization; - optimistic-lock/version rules; - business invariants; - current database state; - transactional consistency. Client-side or ALV-event validation is not a security boundary. ### 10.4 Persist explicitly Use the system's supported change contract: for example a released API, BAPI, application service, or EML for a RAP BO. Do not perform an arbitrary direct table update simply because the grid output resembles the table. The transaction owner decides the commit/rollback boundary. Reusable methods should not casually issue `COMMIT WORK` when their caller owns the larger unit of work. ### 10.5 Re-read and refresh After successful persistence, re-read authoritative state when calculations, status changes, locks, or other users may have changed the record. Then refresh the grid while preserving row/column stability where appropriate. --- ## 11. Row Index Versus Business Identity ALV selection APIs frequently return display row indexes. Sorting and filtering can change what an index refers to. ```text Unsafe assumption: selected index 3 = database record originally loaded at index 3 Safe flow: current selected index → current output row → immutable business key → fresh authorization/state check → business operation ``` For SD-style data, carry `VBELN`, `POSNR`, and `ETENR` at the appropriate grain even if some technical key columns are not initially prominent. For a RAP BO, carry its actual entity key; an ALV row number is not `%tky`. --- ## 12. List and Background Processing `CL_GUI_ALV_GRID` needs the SAP GUI Control Framework and a frontend container. It is not a background-processing output mechanism. For a report that also runs as a job, design output behind an interface: ```text Application produces typed result table │ ├─ dialog renderer → SALV/grid ├─ job renderer → spool/list or file └─ test renderer → assertions on result table ``` In background: - there is no user-driven grid interaction; - frontend-dependent controls are unavailable; - selection variants supply input; - operational evidence belongs in job log, spool, application log, or a deliberately produced file. Do not assume that a SALV call automatically provides the exact background spool behavior the business needs. Test the chosen display mode in the target release and execution environment. --- ## 13. Tree Data Modeling A tree has two distinct concerns: ```text Hierarchy model Display data ------------------------------ -------------------------- node key node text parent/related node key amount/status/attributes relationship type icons and column values ``` With `CL_SALV_TREE`, the application creates nodes individually, relates each node to a parent or sibling, and assigns the node's data row. Node keys are ALV technical identities; keep business keys separately for navigation. Choose a tree only when users need to reason about containment or dependency. If they mainly compare amounts across many orders, a flat grid grouped and sorted by order is usually easier to scan. ### Tree risks - one cyclic or missing parent breaks hierarchy construction; - eager expansion of a huge tree overwhelms users and memory; - totals across levels can double count parent and child values; - a selected node key is still not authorization; - loading every deep child before it is expanded can be unnecessarily costly. --- ## 14. Currency, Quantity, Totals, and Semantics An amount without its currency and a quantity without its unit are incomplete business values. For a grid field catalog, connect amount/quantity components to the output components holding currency/unit via `CFIELDNAME` and `QFIELDNAME`. Prefer DDIC reference fields where available. Do not total values across different currencies merely because ALV permits a numeric total. Either: - group/subtotal by currency; - convert using an explicit business rule and date/rate type; - suppress a meaningless grand total. The same principle applies to incompatible quantity units. --- ## 15. Layout Variants ALV layouts can store presentation preferences such as column order, width, visibility, sorting, filtering, and totals. Variant identity is commonly described using `DISVARIANT` values such as report and handle, with save scope controlled by the ALV API. Keep three ideas separate: ```text Selection variant → input parameters and select-options ALV layout variant → result presentation Business variant → domain-specific configuration, if any ``` An ALV layout filter does not reduce the database query or replace read authorization. The data may already have reached the frontend before the user hides it. When changing an output structure, test existing saved layouts. Renamed or removed columns can make old variants behave unexpectedly. --- ## 16. Performance Model ALV can sort and filter its supplied dataset, but it cannot undo an over-fetching query. ```text Best order of responsibility: 1. database/API restricts rows and columns 2. application derives the exact report grain 3. ALV provides interactive presentation operations ``` For performance diagnosis: 1. measure the data-access phase separately from rendering; 2. inspect SQL with SQL Monitor/ST05 when appropriate; 3. check row count and output width; 4. look for joins that multiply rows; 5. avoid expensive per-row database queries; 6. consider HANA-oriented ALV with IDA for supported large-data scenarios; 7. test frontend rendering and export separately. `CL_SALV_GUI_TABLE_IDA` can support database-oriented paging/filtering on HANA in systems where the class and data source are suitable. It is not a drop-in reason to ignore data authorization, released-object rules, or the target system's API state. --- ## 17. Authorization and Data Protection Apply authorization before sensitive data enters the ALV output model. ```text Wrong boundary: SELECT everything → send to ALV → hide unauthorized column Correct boundary: authorize scope → select allowed data/fields → build output → display ``` For an action or save, authorize again against the current record and requested operation. Read authorization does not imply update, delete, approve, or export authorization. Also consider: - spreadsheet/local-file export; - print/spool access; - saved layout variants; - personal data displayed in diagnostic columns; - transaction navigation from double-click/hotspot events. --- ## 18. Error and Message Design Handle errors at the layer that understands them: | Error | Owning layer | Example response | | ------------------------------ | ---------------------------------- | ------------------------------------------ | | Invalid selection interval | Selection-screen/application input | Field/cross-field message | | User cannot read company code | Authorization/application service | Reject before output | | SALV column not found | ALV configuration | Developer-facing handling/log | | Invalid edited amount | Grid handler + business service | Cell protocol and no save | | Record changed by another user | Persistence/business API | Conflict message and refresh | | Database/API failure | Data-access layer | Logged technical cause + safe user message | An empty result is not always an error. Distinguish “no matching authorized records” from a broken query or swallowed exception. --- ## 19. Common Failure Patterns | Symptom | Likely cause | Diagnostic move | | ----------------------------------- | -------------------------------------- | --------------------------------------------- | | Empty ALV | Query/filter/auth produced no rows | Inspect result table before display | | Wrong/missing columns | Field catalog and line type disagree | Compare `FIELDNAME` with actual components | | Amount displayed without currency | Missing DDIC/currency reference | Set reference metadata/`CFIELDNAME` | | Total is multiplied | Header repeated by item/schedule join | Reconstruct result grain before ALV | | Edit disappears on Save | Pending frontend edit not synchronized | Call `CHECK_CHANGED_DATA` and inspect handler | | Edit appears saved but DB unchanged | Only output internal table changed | Trace explicit persistence call/transaction | | Grid resets on every action | Grid recreated in every PBO | Create once; refresh subsequently | | Handler stops firing | Handler reference went out of scope | Keep handler alive with the control | | Wrong record opened after sort | Original index treated as identity | Resolve current row and use business key | | Background job fails | GUI control requires frontend | Use a background-safe renderer | | Hidden data appears in export | UI hiding treated as security | Do not send unauthorized fields | | Refresh jumps/loses context | Unstable refresh | Use stable row/column options where suitable | --- ## 20. Classic ALV APIs Versus Modern Direction | Technology | Status/use | Main concern | | ------------------------------ | ---------------------------------------------- | ------------------------------------------ | | `REUSE_ALV_LIST_DISPLAY` | Common legacy list reports | Procedural callback and `SLIS_*` patterns | | `REUSE_ALV_GRID_DISPLAY(_LVC)` | Common legacy grid reports | Function-module callbacks and global state | | `CL_SALV_TABLE` | Preferred concise OO display where it fits | Read-only/public display model | | `CL_GUI_ALV_GRID` | Appropriate for rich classic GUI control needs | More lifecycle and event responsibility | | RAP + Fiori elements | Service/UI architecture, not ALV | CDS/behavior/OData/UI annotation lifecycle | When maintaining a legacy report, improve boundaries without rewriting solely for fashion. Extract authorization, query, transformation, and update logic from callbacks first. Then the renderer can be replaced independently if the business case justifies it. --- ## 21. SD Technical-Consultant Example Suppose a report shows sales-order schedule fulfillment. ### Output grain One row per sales order item schedule line: ```text VBELN + POSNR + ETENR ``` ### Flow ```text Selection: sales org, document/date range, status │ ├─ authorize organizational scope ├─ read released CDS/API or appropriate classic source ├─ construct one row per schedule line ├─ preserve order/item/schedule keys ├─ derive open quantity without mixing units └─ render read-only with CL_SALV_TABLE ``` A double-click can navigate to display the business document after a fresh authorization check. If the requirement becomes “mass-change requested dates,” that is not just `EDIT = X`: choose `CL_GUI_ALV_GRID`, capture changes, validate SD rules, call a supported sales-order change contract, handle conflicts and messages, and refresh authoritative results. In clean-core design, prefer released CDS views/APIs and verify API State in the target release. Directly updating `VBAK`, `VBAP`, or `VBEP` is not a valid business update mechanism. --- ## 22. Tools and Debugging Landmarks | Tool/object | Use | | ------------------------------ | --------------------------------------------------- | | `SE38` / `SA38` | Execute or inspect classic reports, where available | | ADT debugger | Break before display, handlers, and save service | | `SE24` | Inspect class interfaces in classic systems | | `DWDM`, `SE83`, `BCALV*` demos | Explore installed Control Framework examples | | `ST22` | Analyze runtime dumps | | `SAT` | Separate query/transformation/rendering time | | `ST05`, SQL Monitor | Diagnose data access, not ALV formatting | | `SU53` / authorization trace | Diagnose authorization failure appropriately | | `SM37` and `SP01` | Background job and spool evidence | Availability and recommended tools vary by edition and authorization. A demo program illustrates an API; it is not automatically a production architecture. --- ## 23. Implementation Checklist ### Before coding - What is one output row? - Is the result flat, exactly two-level, or an arbitrary hierarchy? - Is it read-only or genuinely transactional? - Must it run in background? - Which fields and rows may the user read/export? - What is the supported data/change API in this system edition? ### For `CL_SALV_TABLE` - Build a typed, authorized result table. - Call `FACTORY`, configure subobjects, then `DISPLAY`. - Keep event handlers alive. - Resolve navigation through business keys, not row indexes. - Do not use unsupported SALV-edit hacks. ### For `CL_GUI_ALV_GRID` - Create a custom screen and parent container. - Keep container, grid, handler, and output alive. - Call `SET_TABLE_FOR_FIRST_DISPLAY` once. - Register required events. - Synchronize pending edits before Save. - Validate and authorize in the business layer. - Persist through the supported contract. - Re-read and call `REFRESH_TABLE_DISPLAY`. - Provide a separate output path for background processing. --- 35:T850,1. What ALV Is — and Is Not ALV, the SAP List Viewer, is a presentation framework for structured datasets. It can supply standard user functions such as sorting, filtering, totals, subtotals, layouts, printing, and export. text Database / CDS / released API │ ▼ Application reads, authorizes, and derives data │ ▼ Internal table = report output model │ ▼ ALV renders List, Grid, or Tree │ ▼ User sorts, filters, selects, navigates, or edits ALV does not by itself: - read the correct business data; - authorize a user to see or change that data; - enforce business invariants; - persist edited cells; - fix duplicate rows caused by an incorrect SQL join; - turn a classic report into a Fiori or RAP application. Think of ALV as the report's view and interaction adapter. The internal table is its input model; application methods own the business behavior. --- 2. End-to-End Runtime Flow For a read-only executable report using SALV: text Program/report starts │ ▼ Selection-screen lifecycle │ defaults → dynamic PBO → user input → validation ▼ START-OF-SELECTION │ ├─ authorize requested scope ├─ read through an appropriate CDS view/API/Open SQL ├─ calculate and map the output model └─ return an internal table │ ▼ CLSALVTABLE=FACTORY │ ├─ configure functions, columns, sorts, layout, events └─ DISPLAY │ ▼ User sorts/filters/totals/exports or triggers navigation For an editable GUI grid, the display is only half the workflow: text Application internal table │ ▼ CLGUIALVGRID display │ ▼ User edits a frontend cell │ ├─ REGISTEREDITEVENT / DATACHANGED └─ CHECKCHANGEDDATA transfers/checks pending frontend changes │ ▼ Application validates values and authorization │ ├─ invalid → protocol/message; do not save └─ valid → released update API / BAPI / application service / EML │ ▼ transaction owner commits │ ▼ refresh application data and ALV The decisive point is: an editable cell is not a database update. CHECKCHANGEDDATA is part of synchronizing/validating the grid state; it is not persistence. --- 3. The36:T92f,## 1. What ALV Is — and Is Not ALV, the SAP List Viewer, is a presentation framework for structured datasets. It can supply standard user functions such as sorting, filtering, totals, subtotals, layouts, printing, and export. ```text Database / CDS / released API │ ▼ Application reads, authorizes, and derives data │ ▼ Internal table = report output model │ ▼ ALV renders List, Grid, or Tree │ ▼ User sorts, filters, selects, navigates, or edits ``` ALV does **not** by itself: - read the correct business data; - authorize a user to see or change that data; - enforce business invariants; - persist edited cells; - fix duplicate rows caused by an incorrect SQL join; - turn a classic report into a Fiori or RAP application. Think of ALV as the report's **view and interaction adapter**. The internal table is its input model; application methods own the business behavior. --- ## 2. End-to-End Runtime Flow For a read-only executable report using SALV: ```text Program/report starts │ ▼ Selection-screen lifecycle │ defaults → dynamic PBO → user input → validation ▼ START-OF-SELECTION │ ├─ authorize requested scope ├─ read through an appropriate CDS view/API/Open SQL ├─ calculate and map the output model └─ return an internal table │ ▼ CL_SALV_TABLE=>FACTORY │ ├─ configure functions, columns, sorts, layout, events └─ DISPLAY │ ▼ User sorts/filters/totals/exports or triggers navigation ``` For an editable GUI grid, the display is only half the workflow: ```text Application internal table │ ▼ CL_GUI_ALV_GRID display │ ▼ User edits a frontend cell │ ├─ REGISTER_EDIT_EVENT / DATA_CHANGED └─ CHECK_CHANGED_DATA transfers/checks pending frontend changes │ ▼ Application validates values and authorization │ ├─ invalid → protocol/message; do not save └─ valid → released update API / BAPI / application service / EML │ ▼ transaction owner commits │ ▼ refresh application data and ALV ```5:["$","main",null,{"className":"blog-module__JsT-Oq__blogRoot","children":[["$","$Lf",null,{}],["$","$L10",null,{"documents":[{"slug":"hello-world","language":"vi","title":"Chương 1. Hello World! Tôi đang học cách cảm nhận lại thế giới","part":"Part 1. Hello World","summary":"Tôi đã mất cả tỷ lần trì hoãn chỉ để đắn đo về việc xây dựng một khoảng lặng cho riêng mình. Thì bây giờ đây, chính là nó, JusteeSpace - một không gian, nơi tôi thoải mái ghi lại những câu chuyện, những trải nghiệm sống, là nơi lưu trữ, vừa mang tính cá nhân, vừa mang tính hệ thống. Một quyển nhật ký dành cho tôi ở phiên bản tương lai có thể xem lại những suy nghĩ, bài học mà tôi học được ở hiện tại.","category":"Personal","tags":["introduction"],"publishedAt":"2026-05-09","updatedAt":"$undefined","draft":false,"content":"$11","excerpt":"$12","previewContent":"## Điều gì đã thôi thúc tôi bắt đầu viết blog này?\n\nTôi vốn là một người không giỏi trong việc thể hiện cảm xúc, không giỏi trong việc diễn đạt và trình bày ý tưởng. Và nhìn lại quá khứ, điều đó đã cản trở tôi có thể dấn thân vào làm một việc gì đó hết mình. Những ngày tháng ngồi ở giảng đường Đại học, nếu như Giảng viên không trực tiếp gọi tôi thì có lẽ tôi cũng chả bao giờ phát biểu ý kiến, có lẽ là do sợ sai hay bị chê cười… haha… đúng là đần, mình là người trả tiền sử dụng dịch vụ mà, sợ cái đ’ gì chứ.\n\nCuộc sống của tôi cứ trôi qua êm đềm như vậy. Đến ngày tốt nghiệp, rồi cũng đi thực tập và may mắn có được công việc mà ở đó đã xây dựng lên nền tảng khá vững cho tôi. Bạn đã nghĩ cuộc sống của tôi như vậy là ổn, không có gì để chê đúng không, tốt nghiệp trường top (Bách Khoa), lại công việc ổn định. Cứ thế mà an nhàn đi, suy nghĩ làm gì.","connections":["who-am-i"],"readingMinutes":7,"languages":["vi"],"backlinks":[],"unresolvedReferences":[]},{"slug":"who-am-i","language":"vi","title":"Chương 2. Tôi là ai giữa thế giới này","part":"Part 1. Hello World","summary":"Tôi không định nghĩa bản thân bằng chức danh công việc, bằng những công nghệ mình thành thạo, hay bằng những con số vô hình trên màn hình máy tính. Bản thể của tôi là con người đã được hình thành dựa trên trải nghiệm sống, cách tôi phản ứng với những rào cản, hoài nghi của chính mình.","category":"Personal","tags":["introduction"],"publishedAt":"2026-05-12","updatedAt":"$undefined","draft":false,"content":"$13","excerpt":"$14","previewContent":"## Những thứ định nghĩa sự tồn tại của tôi\n\nMọi người thường nghĩ Dev bọn tôi chỉ biết có màn hình đen và những dòng code khô khan đúng không. Nhưng sau giờ làm, tôi lại ôm đàn, cầm máy ảnh đi lang thang, hoặc ngồi dựng một thước phim ngắn. Tôi còn chả biết có ai giống mình như vậy không. Blog này sinh ra vì tôi không muốn những mảnh ghép đó bị tách rời.\n\nTôi là một cựu sinh viên Bách Khoa K18, chuyên ngành Khoa học máy tính. Vâng, sau 5 năm trầy trật trên giảng đường, cuối cùng tôi cũng có thể tự tin giới thiệu mình là một Kỹ sư máy tính. Nhưng quay ngược thời gian vào thời điểm chọn ngành, bản thân tôi còn chả định nghĩa được 'kỹ sư' là gì. Tôi chỉ biết là xung quanh mọi người ca ngợi nó lắm, nào là ra trường lương nghìn đô, nào là tạo ra nhiều đột phá công nghệ. Năm đó, tôi cũng là một trong số ít học sinh của trường đỗ vào Bách Khoa, cảm giác bước đi mặt vênh lên trời, 'oách xà lách' vô cùng, và cái niềm tự hào âm ỉ ấy tôi vẫn giữ mãi cho đến tận bây giờ.","connections":["nothing-change-if-nothing-change"],"readingMinutes":6,"languages":["vi"],"backlinks":["hello-world"],"unresolvedReferences":[]},{"slug":"nothing-change-if-nothing-change","language":"vi","title":"Chương 3. Không có gì thay đổi nếu không có gì thay đổi","part":"Part 1. Hello World","summary":"Ai trong chúng ta cũng mong muốn trở thành phiên bản tốt hơn của chính mình, nhưng ít ai sẵn sàng thay đổi","category":"Personal","tags":["motivation"],"publishedAt":"2026-05-15","updatedAt":"$undefined","draft":false,"content":"$15","excerpt":"$16","previewContent":"## Chúng ta đang quá tham lam\n\nMạng xã hội ngày nay dựng lên những khung cảnh quá hoàn hảo: một đứa trẻ phát âm tiếng Anh chuẩn bản xứ, những người trẻ chưa đầy ba mươi đã sở hữu nhà riêng, xe sang hay tự do tài chính. Chúng ta lướt qua những lát cắt ấy mỗi ngày và vô tình rơi vào một cái bẫy tâm lý nguy hiểm: nhìn vào kết quả của người khác và gán nó làm tiêu chuẩn cho bản thân.\n\nNhưng sự thật là, những gì bạn thấy chưa chắc đã là 100% sự thật, có những bí mật đằng sau mà bạn chưa nhìn rõ, mọi trạng thái ở hiện tại đều có nguyên do của nó.\nĐằng sau một đứa trẻ nói tiếng Anh lưu khoát có thể là một gia đình có điều kiện, được đầu tư học trường quốc tế và tiếp xúc với ngoại ngữ từ lúc còn chưa sõi tiếng mẹ đẻ. Đằng sau một sự thành công sớm là những nguồn lực ngầm về tài chính, mối quan hệ hoặc xuất phát điểm vượt trội. Tất nhiên vẫn sẽ tồn tại vài trường hợp xuất chúng, nhưng tỷ lệ là dưới 1%.","connections":[],"readingMinutes":6,"languages":["vi"],"backlinks":["who-am-i"],"unresolvedReferences":[]},{"slug":"sap-switching","language":"vi","title":"Chương 1. Từ Kỹ Sư Phần Mềm Đến Hành Trình Mới Với SAP","part":"Part 2. Cú chuyển mình trong sự nghiệp","summary":"Từ 1 software engineer với kỹ năng Database Optimizing và Blockchain, vì sao tôi lại muốn bắt đầu hành trình mới với SAP","category":"Personal","tags":["sap"],"publishedAt":"2026-05-20","updatedAt":"$undefined","draft":false,"content":"$17","excerpt":"$18","previewContent":"## Bước đi chập chững từ các công ty khởi nghiệp\n\nTôi có nhiều năm làm việc với các công ty start up và may mắn được cọ xát với nhiều công nghệ mới, được nhúng tay khá sâu vào các dự án, như là trực tiếp sửa đổi / thiết kế lại hệ thống database của một ứng dụng đang chạy production và kết quả được cải thiện tương đối chỉ với vài kỹ năng cơ bản về Index và partitioning.","connections":["sap-foundation"],"readingMinutes":5,"languages":["vi"],"backlinks":[],"unresolvedReferences":[]},{"slug":"sap-foundation","language":"vi","title":"Chương 2. Đặt nền móng","part":"Part 2. Cú chuyển mình trong sự nghiệp","summary":"Định nghĩa tư duy, lên kế hoạch học tập để xây dựng nền móng vững chắc","category":"Personal","tags":["sap","foundation"],"publishedAt":"2026-05-27","updatedAt":"$undefined","draft":false,"content":"$19","excerpt":"$1a","previewContent":"$1b","connections":["sap-concepts"],"readingMinutes":7,"languages":["vi"],"backlinks":["sap-switching"],"unresolvedReferences":[]},{"slug":"sap-concepts","language":"vi","title":"Chương 3. Hiểu rõ hơn về các khái niệm trong SAP","part":"Part 2. Cú chuyển mình trong sự nghiệp","summary":"Cái nhìn toàn diện về hệ sinh thái SAP, từ tính năng cốt lõi, ngôn ngữ lập trình, hệ thống phân hệ đến cơ chế vận hành chi tiết của kiến trúc 3 lớp R/3 và Application Server.","category":"Personal","tags":["sap","foundation"],"publishedAt":"2026-06-01","updatedAt":"$undefined","draft":false,"content":"$1c","excerpt":"$1d","previewContent":"$1e","connections":["sap-abap"],"readingMinutes":3,"languages":["vi"],"backlinks":["sap-foundation"],"unresolvedReferences":[]},{"slug":"sap-abap","language":"vi","title":"Chương 4. ABAP Fundamentals: Bước Chân Vào Tầng Xử Lý Logic","part":"Part 2. Cú chuyển mình trong sự nghiệp","summary":"Những bài học đầu tiên về Technical trong SAP","category":"Personal","tags":["sap","foundation","abap"],"publishedAt":"2026-06-07","updatedAt":"$undefined","draft":false,"content":"$1f","excerpt":"$20","previewContent":"$21","connections":["sap-abap-1","sap-abap-2","sap-abap-3","sap-abap-4","sap-abap-5","sap-abap-6","sap-abap-7"],"readingMinutes":2,"languages":["vi"],"backlinks":["sap-concepts"],"unresolvedReferences":[]},{"slug":"sap-abap-1","language":"en","title":"ABAP BASIC Statements","part":"ABAP","summary":"ABAP Basic Statements","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-06-10","updatedAt":"$undefined","draft":false,"content":"$22","excerpt":"$23","previewContent":"$24","connections":[],"readingMinutes":5,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]},{"slug":"sap-abap-2","language":"en","title":"ABAP Data Dictionary","part":"ABAP","summary":"ABAP Data Dictionary","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-06-17","updatedAt":"$undefined","draft":false,"content":"$25","excerpt":"$26","previewContent":"$27","connections":[],"readingMinutes":5,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]},{"slug":"sap-abap-3","language":"en","title":"ABAP Open SQL","part":"ABAP","summary":"ABAP Open SQL","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-06-24","updatedAt":"$undefined","draft":false,"content":"$28","excerpt":"$29","previewContent":"$2a","connections":[],"readingMinutes":5,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]},{"slug":"sap-abap-4","language":"en","title":"ABAP Internal Table","part":"ABAP","summary":"ABAP Internal Table","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-06-28","updatedAt":"$undefined","draft":false,"content":"$2b","excerpt":"$2c","previewContent":"$2d","connections":[],"readingMinutes":16,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]},{"slug":"sap-abap-5","language":"en","title":"SAP ABAP Modularization","part":"ABAP","summary":"SAP ABAP Modularization","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-07-06","updatedAt":"$undefined","draft":false,"content":"$2e","excerpt":"$2f","previewContent":"$30","connections":[],"readingMinutes":19,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]},{"slug":"sap-abap-6","language":"en","title":"SAP ABAP Classical Report","part":"ABAP","summary":"SAP ABAP Classical Report","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-07-13","updatedAt":"$undefined","draft":false,"content":"$31","excerpt":"$32","previewContent":"$33","connections":[],"readingMinutes":18,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]},{"slug":"sap-abap-7","language":"en","title":"SAP ABAP ALV Report","part":"ABAP","summary":"SAP ABAP ALV Report","category":"Technical","tags":["sap","abap"],"publishedAt":"2026-07-21","updatedAt":"$undefined","draft":false,"content":"$34","excerpt":"$35","previewContent":"$36","connections":[],"readingMinutes":19,"languages":["en"],"backlinks":["sap-abap"],"unresolvedReferences":[]}],"initialDocument":"$undefined","language":"vi"}]]}] b:[["$","meta","0",{"charSet":"utf-8"}],["$","meta","1",{"name":"viewport","content":"width=device-width, initial-scale=1"}]] 37:I[27201,["/_next/static/immutable/chunks/33v8uwkv4wy50.js"],"IconMark"] 8:null d:[["$","title","0",{"children":"Graph | Thanh's Blog"}],["$","meta","1",{"name":"description","content":"Explore connections between technical and personal documents."}],["$","link","2",{"rel":"shortcut icon","href":"/images/favicon.webp"}],["$","link","3",{"rel":"icon","href":"/images/favicon.webp"}],["$","link","4",{"rel":"apple-touch-icon","href":"/images/favicon.webp"}],["$","$L37","5",{}]] </article></body></html>