abapgit-agent 1.15.1 → 1.15.3

package/abap/guidelines/cds-testing.md

@@ -1,28 +1,250 @@
 ---
 layout: default
 title: CDS Testing
-nav_order: 22
+nav_order: 10
 parent: ABAP Coding Guidelines
 grand_parent: ABAP Development
 ---
 
 # CDS Testing
 
-### Use CDS Test Double Framework for CDS View Tests
+**Searchable keywords**: CDS test double, CL_CDS_TEST_ENVIRONMENT, IF_CDS_TEST_ENVIRONMENT, insert_test_data, clear_doubles, create_for_multiple_cds, class_setup, class_teardown, aggregation test, CDS unit test
 
-**When creating unit tests for CDS views, use the CDS Test Double Framework (`CL_CDS_TEST_ENVIRONMENT`).**
+## TOPICS IN THIS FILE
+1. When to Use CDS Test Doubles - line 22
+2. Basic Setup Pattern - line 30
+3. Testing CDS Views with Aggregations - line 100
+4. Testing CDS Views that Select from Another CDS View - line 130
+5. Key Classes and Methods - line 170
+6. Important Usage Notes - line 190
+
+---
+
+## 1. When to Use CDS Test Doubles
 
 ```
 ❌ WRONG: Use regular AUnit test class without test doubles
 ✅ CORRECT: Use CL_CDS_TEST_ENVIRONMENT to create test doubles for CDS views
 ```
 
-**Why**: CDS views read from database tables. Using test doubles allows:
-- Injecting test data without affecting production data
-- Testing specific scenarios that may not exist in production
-- Fast, isolated tests that don't depend on database state
+Use the CDS Test Double Framework (`CL_CDS_TEST_ENVIRONMENT`) whenever:
+- A class under test calls `SELECT FROM <cds_view>` directly or via a helper
+- You need controlled test data (not production data)
+- You need to test CDS view logic with specific scenarios
+
+**Why**: CDS views read from database tables. Using test doubles allows injecting test data
+without affecting production data, and keeps tests fast and isolated.
+
+---
+
+## 2. Basic Setup Pattern
+
+The test class lives in `<classname>.clas.testclasses.abap`. The CDS view itself has no
+`.testclasses` file — test it through a regular ABAP class that reads it.
+
+```abap
+"-------------------------
+" CLASS DEFINITION
+"-------------------------
+CLASS ltcl_cds_test DEFINITION FOR TESTING RISK LEVEL HARMLESS DURATION SHORT FINAL.
+
+  PRIVATE SECTION.
+    " IMPORTANT: Use interface type, not class type!
+    DATA mo_cds_env TYPE REF TO if_cds_test_environment.
+
+    " IMPORTANT: class_setup/teardown must be CLASS-METHODS (static)!
+    CLASS-DATA mo_cds_env_static TYPE REF TO if_cds_test_environment.
+
+    METHODS setup.
+    METHODS test_cds_with_doubles FOR TESTING.
+
+    CLASS-METHODS: class_setup,
+                   class_teardown.
+
+ENDCLASS.
+
+"-------------------------
+" CLASS IMPLEMENTATION
+"-------------------------
+CLASS ltcl_cds_test IMPLEMENTATION.
+
+  METHOD class_setup.
+    " Create CDS test environment — framework auto-creates doubles for dependencies
+    mo_cds_env_static = cl_cds_test_environment=>create(
+      i_for_entity = 'ZC_MY_CDS_VIEW' ).
+  ENDMETHOD.
+
+  METHOD class_teardown.
+    " Clean up test environment
+    mo_cds_env_static->destroy( ).
+  ENDMETHOD.
+
+  METHOD setup.
+    " IMPORTANT: Assign static env to instance and clear doubles before each test
+    mo_cds_env = mo_cds_env_static.
+    mo_cds_env->clear_doubles( ).
+  ENDMETHOD.
+
+  METHOD test_cds_with_doubles.
+    " IMPORTANT: Must declare table type first — cannot inline in VALUE #()!
+    DATA lt_test_data TYPE TABLE OF zc_my_cds_view WITH EMPTY KEY.
+    lt_test_data = VALUE #(
+      ( field1 = 'A' field2 = 100 )
+      ( field1 = 'B' field2 = 200 ) ).
+
+    " Insert test data using named parameter
+    mo_cds_env->insert_test_data( i_data = lt_test_data ).
+
+    " Select from CDS view
+    SELECT * FROM zc_my_cds_view INTO TABLE @DATA(lt_result).
+
+    " Verify results
+    cl_abap_unit_assert=>assert_not_initial(
+      act = lt_result
+      msg = 'Result should not be empty' ).
+
+    cl_abap_unit_assert=>assert_equals(
+      act = lines( lt_result )
+      exp = 2
+      msg = 'Expected 2 rows' ).
+  ENDMETHOD.
+
+ENDCLASS.
+```
+
+---
+
+## 3. Testing CDS Views with Aggregations (SUM, COUNT, GROUP BY)
+
+For CDS views with aggregations, insert test data into the **base tables** (SFLIGHT, SCARR,
+SBOOK, etc.), not directly into the CDS view. The framework routes the inserts through the
+aggregation pipeline.
+
+```abap
+METHOD test_aggregation.
+  " Insert data into base tables via CDS test doubles
+  DATA lt_scarr TYPE TABLE OF scarr WITH EMPTY KEY.
+  lt_scarr = VALUE #( ( carrid = 'LH' carrname = 'Lufthansa' currcode = 'EUR' ) ).
+  mo_cds_env->insert_test_data( i_data = lt_scarr ).
+
+  DATA lt_sflight TYPE TABLE OF sflight WITH EMPTY KEY.
+  lt_sflight = VALUE #( ( carrid = 'LH' connid = '0400' fldate = '20240115'
+                          seatsmax = 200 seatsocc = 100 ) ).
+  mo_cds_env->insert_test_data( i_data = lt_sflight ).
+
+  DATA lt_sbook TYPE TABLE OF sbook WITH EMPTY KEY.
+  lt_sbook = VALUE #(
+    ( carrid = 'LH' connid = '0400' fldate = '20240115' bookid = '0001' forcuram = 1000 )
+    ( carrid = 'LH' connid = '0400' fldate = '20240115' bookid = '0002' forcuram = 2000 )
+    ( carrid = 'LH' connid = '0400' fldate = '20240115' bookid = '0003' forcuram = 3000 ) ).
+  mo_cds_env->insert_test_data( i_data = lt_sbook ).
+
+  " Select from CDS view — aggregations will use test double data
+  SELECT * FROM zc_flight_revenue INTO TABLE @DATA(lt_result).
+
+  cl_abap_unit_assert=>assert_equals(
+    exp = 3
+    act = lt_result[ 1 ]-numberofbookings
+    msg = 'Should have 3 bookings' ).
+
+  cl_abap_unit_assert=>assert_equals(
+    exp = '6000.00'
+    act = lt_result[ 1 ]-totalrevenue
+    msg = 'Total revenue should be 6000.00' ).
+ENDMETHOD.
+```
+
+---
+
+## 4. Testing CDS Views that Select from Another CDS View
+
+> **Note:** This pattern applies when your design **already has** a CDS view that selects from
+> another CDS view. It does NOT mean you should split a single view into two — use a single
+> CDS view with GROUP BY / JOIN when the business logic fits.
+
+When your CDS view selects from **another CDS view** (not a base table), `create` raises
+`CX_CDS_FAILURE`. Use `create_for_multiple_cds` instead and list all CDS entities in the
+dependency chain.
+
+```abap
+METHOD class_setup.
+  " ZC_TopView selects from ZC_IntermediateView (another CDS view entity)
+  " → must use create_for_multiple_cds and list all CDS entities
+  mo_cds_env_static = cl_cds_test_environment=>create_for_multiple_cds(
+    i_for_entities = VALUE #(
+      ( 'ZC_TOPVIEW' )           " the view under test
+      ( 'ZC_INTERMEDIATEVIEW' )  " the CDS view it selects from
+    ) ).
+ENDMETHOD.
+```
+
+Insert test data into the **intermediate CDS view** (not the base tables), because that is
+what the top-level view reads:
+
+```abap
+METHOD test_read.
+  DATA lt_source TYPE TABLE OF zc_intermediateview WITH EMPTY KEY.
+  lt_source = VALUE #(
+    ( field1 = 'A' field2 = 100 )
+    ( field1 = 'B' field2 = 200 ) ).
+  mo_cds_env->insert_test_data( i_data = lt_source ).
+
+  SELECT * FROM zc_topview INTO TABLE @DATA(lt_result).
+
+  cl_abap_unit_assert=>assert_equals(
+    exp = 2  act = lines( lt_result )  msg = 'Expected 2 rows' ).
+ENDMETHOD.
+```
+
+**Rules:**
+- List the view under test **and all CDS views it depends on** in `i_for_entities`
+- Insert data into the **direct source** of the top-level view (the intermediate CDS view)
+- Order in `i_for_entities` does not matter
+- If `create` raises `CX_CDS_FAILURE`, switch to `create_for_multiple_cds`
+
+---
+
+## 5. Key Classes and Methods
+
+| Item | Type / Usage |
+|------|-------------|
+| `CL_CDS_TEST_ENVIRONMENT` | Class — entry point, use its `CREATE` / `CREATE_FOR_MULTIPLE_CDS` methods |
+| `IF_CDS_TEST_ENVIRONMENT` | Interface — declare your variable with this type |
+| `CLASS-METHODS class_setup` | Must be static (`CLASS-METHODS`, not `METHODS`) |
+| `CL_ABAP_UNIT_ASSERT` | Standard AUnit assertion class |
+
+| Method | Purpose |
+|--------|---------|
+| `CL_CDS_TEST_ENVIRONMENT=>create( i_for_entity = ... )` | Environment for a CDS view over base tables |
+| `CL_CDS_TEST_ENVIRONMENT=>create_for_multiple_cds( i_for_entities = ... )` | Environment when CDS view selects from another CDS view |
+| `insert_test_data( i_data = ... )` | Inject test rows into a test double |
+| `clear_doubles( )` | Remove all test rows — call in `setup` before each test |
+| `destroy( )` | Tear down the environment — call in `class_teardown` |
+
+---
+
+## 6. Important Usage Notes
+
+1. **Declare with interface type**: `DATA mo_cds_env TYPE REF TO if_cds_test_environment` —
+   `create` returns an interface reference, not a class reference.
+
+2. **Static lifecycle methods**: `class_setup` and `class_teardown` must be `CLASS-METHODS`
+   (not `METHODS`). The environment is expensive to create — build it once per class run.
+
+3. **Table type before VALUE #()**: Must declare `DATA lt_tab TYPE TABLE OF <type> WITH EMPTY KEY`
+   before using `VALUE #()` — inline declaration inside `VALUE #()` is not supported here.
+
+4. **Auto-created dependencies**: When the CDS view selects only from base tables, the framework
+   auto-creates test doubles — do not specify an `i_dependency_list`. When the CDS view selects
+   from another CDS view, use `create_for_multiple_cds` (see section 4).
+
+5. **Aggregations**: For CDS views with SUM/COUNT/GROUP BY, insert test data into the base tables
+   (SFLIGHT, SCARR, etc.), not the CDS view itself.
+
+6. **Clear doubles**: Always call `clear_doubles` in `setup` to ensure test isolation.
+
+7. **Enable associations**: Set `test_associations = 'X'` in `create` only when explicitly
+   testing CDS association navigation.
 
-See `abapgit-agent ref --topic testing` for full code examples including:
-- Basic CDS test double setup
-- Testing CDS views with aggregations (insert into base tables)
-- Testing CDS views that select from another CDS view (`create_for_multiple_cds`)
+8. **Exception handling**: Declare test methods with `RAISING cx_static_check` if the code
+   under test raises checked exceptions.

package/abap/guidelines/cds.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: CDS Views
-nav_order: 5
+nav_order: 9
 parent: ABAP Coding Guidelines
 grand_parent: ABAP Development
 ---

package/abap/guidelines/classes.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Classes & Objects
-nav_order: 6
+nav_order: 4
 parent: ABAP Coding Guidelines
 grand_parent: ABAP Development
 ---

package/abap/guidelines/comments.md

@@ -0,0 +1,249 @@
+---
+layout: default
+title: Documentation Comments
+nav_order: 6
+parent: ABAP Coding Guidelines
+grand_parent: ABAP Development
+---
+
+# ABAP Documentation Comments
+
+**Searchable keywords**: ABAP DOC, "! comment, shorttext synchronized, @parameter, @raising, inline comment, CDS comment, // comment, program header, *&---, documentation comment
+
+## TOPICS IN THIS FILE
+1. Two Types of Comments - line 18
+2. OO Class Documentation (CLAS) - line 37
+3. Interface Documentation (INTF) - line 101
+4. Program Header (PROG) - line 120
+5. CDS View Comments (DDLS) - line 137
+6. When NOT to Comment - line 161
+7. Quick Decision Table - line 182
+
+---
+
+## 1. Two Types of Comments
+
+ABAP has two distinct comment styles with different purposes:
+
+**`"!` (ABAP DOC)** — parsed by the ABAP system; surfaced in ADT and SE24 as F2 help.
+Use for API-level documentation: class declarations, interface declarations, and method signatures.
+This is the equivalent of Javadoc. The system reads it — it is metadata, not decoration.
+
+**`"!` is only valid immediately before these statements:**
+`CLASS ... DEFINITION`, `INTERFACE`, `METHODS`, `CLASS-METHODS`, `EVENTS`, `DATA`, `CLASS-DATA`, `CONSTANTS`.
+
+**`"!` before `TYPES` is a syntax error** — the Code Inspector reports "ABAP Doc comment is in the wrong position."
+Use a regular `"` comment to describe type structures instead.
+
+**`"` (regular inline comment)** — source-only; not parsed by the ABAP system.
+Use inside method bodies to explain non-obvious logic, and to label `TYPES` blocks.
+Never use `"!` inside method implementations — it has no effect there.
+
+**Default behaviour (when to add automatically vs. only on request):**
+
+| Comment Type | Default Behaviour |
+|---|---|
+| `"! <p class="shorttext synchronized">` on CLASS/INTF | **Always auto-add** — synced to XML `<DESCRIPT>`; it IS object metadata |
+| `@EndUserText.label` on CDS view | **Always auto-add** — same: it IS the CDS description |
+| `"!` + `@parameter` on INTF public methods | **Always auto-add** — interfaces are the contract; self-documenting |
+| `"!` + `@parameter` on CLAS public methods | **Auto-add** when creating a new class from scratch |
+| `"!` on existing CLAS private/protected methods | **Only if requested** — adding to existing code is refactoring |
+| `"` inline comments inside method bodies | **Only when non-obvious** — never add redundant comments |
+| `*&---` program header | **Always auto-add** — standard for every PROG |
+
+---
+
+## 2. OO Class Documentation (CLAS)
+
+### Class-level shorttext
+
+Place the `"!` shorttext immediately before `CLASS ... DEFINITION`:
+
+```abap
+"! <p class="shorttext synchronized">Pull ABAP objects from a remote git repository</p>
+CLASS zcl_abgagt_agent DEFINITION PUBLIC FINAL CREATE PUBLIC.
+```
+
+This shorttext is **synced to the XML `<DESCRIPT>` field** by abapGit. Creating a class without
+it means the XML description is blank and the object cannot be searched by description in SE24/SE80.
+**Always add it** when creating any new class.
+
+**Note on `*"*` auto-header:** When a class has local definitions or inherits from another class,
+abapGit writes a 3-line `*"*"` block at the top of the `.clas.abap` file:
+
+```abap
+*"* use this source file for the definition and implementation of
+*"* local helper classes, interface definitions and type
+*"* temporary on-the-fly implementation
+```
+
+In that case, the `"!` shorttext goes on line 4 (after the block), not line 1.
+
+### Method documentation
+
+Place `"!` documentation in the DEFINITION section, PUBLIC SECTION only, immediately before the
+`METHODS` statement:
+
+```abap
+"! Pull files from remote and activate them
+"! @parameter it_files | List of files to activate (relative paths)
+"! @parameter rv_success | True if all objects activated successfully
+"! @raising zcx_abapgit_exception | If pull or activation fails
+METHODS pull_files
+  IMPORTING it_files          TYPE string_table
+  RETURNING VALUE(rv_success) TYPE abap_bool
+  RAISING   zcx_abapgit_exception.
+```
+
+**Rules:**
+
+- **ALWAYS add** `"! <p class="shorttext synchronized">` when creating any new CLASS — no exceptions.
+- **ALWAYS add** `"!` + `@parameter` for all PUBLIC methods when creating a new class from scratch.
+- When **modifying existing** code, only add or update comments if explicitly asked.
+- `@parameter <name> | <description>` — one line per IMPORTING/EXPORTING/RETURNING/CHANGING param.
+- `@raising <exception> | <reason>` — one line per RAISING exception.
+- PRIVATE and PROTECTED methods: optional; add only if the purpose is non-obvious.
+- Place ONLY in the DEFINITION section — do NOT repeat `"!` in the IMPLEMENTATION section.
+
+**Full example:**
+
+```abap
+"! <p class="shorttext synchronized">Syntax checker for ABAP class source</p>
+CLASS zcl_abgagt_syntax_chk_clas DEFINITION PUBLIC FINAL CREATE PUBLIC.
+  PUBLIC SECTION.
+    INTERFACES zif_abgagt_syntax_checker.
+
+    "! Create a new syntax checker instance
+    "! @parameter ii_agent | Agent used for HTTP communication
+    CLASS-METHODS create
+      IMPORTING ii_agent        TYPE REF TO zif_abgagt_agent
+      RETURNING VALUE(ro_check) TYPE REF TO zif_abgagt_syntax_checker.
+
+  PRIVATE SECTION.
+    DATA mi_agent TYPE REF TO zif_abgagt_agent.
+ENDCLASS.
+```
+
+---
+
+## 3. Interface Documentation (INTF)
+
+Interfaces follow the same `"!` pattern as classes. The shorttext goes immediately before
+`INTERFACE ... PUBLIC`, and every method gets `"!` + `@parameter`.
+
+```abap
+"! <p class="shorttext synchronized">Contract for all syntax checker implementations</p>
+INTERFACE zif_abgagt_syntax_checker PUBLIC.
+
+  "! Check the syntax of ABAP source code
+  "! @parameter iv_source | Full ABAP source text to check
+  "! @parameter rv_result | JSON-encoded result with errors list
+  "! @raising zcx_abapgit_exception | On communication failure
+  METHODS check_syntax
+    IMPORTING iv_source        TYPE string
+    RETURNING VALUE(rv_result) TYPE string
+    RAISING   zcx_abapgit_exception.
+
+ENDINTERFACE.
+```
+
+**Canonical example:** `zif_abgagt_syntax_checker.intf.abap` in this repository.
+
+**Rules:**
+- **ALWAYS add** `"! <p class="shorttext synchronized">` for every new interface.
+- **ALWAYS add** `"!` + `@parameter` for every method — interfaces are the published contract.
+- No exceptions for "obvious" method names — document them anyway.
+
+---
+
+## 4. Program Header (PROG)
+
+Programs use the traditional `*&---` block, NOT ABAP DOC. Place it before the `REPORT` statement:
+
+```abap
+*&---------------------------------------------------------------------*
+*& Report Z_MY_PROGRAM
+*&---------------------------------------------------------------------*
+*& Brief description of what the program does
+*&---------------------------------------------------------------------*
+REPORT z_my_program.
+```
+
+**Rules:**
+- **ALWAYS add** this header block when creating any new program.
+- Do NOT add `"! <p class="shorttext synchronized">` before `REPORT` — it is not parsed there.
+- Inline comments inside `START-OF-SELECTION` and other events use the regular `"` style.
+
+---
+
+## 5. CDS View Comments (DDLS)
+
+CDS DDL source (`.ddls.asddls`) uses a completely different comment syntax from ABAP:
+
+- Line comment: `// text`
+- Block comment: `/* text */`
+
+**Never use ABAP-style `"` inside CDS source** — it causes a CDS syntax error.
+
+### `@EndUserText.label` — the CDS equivalent of shorttext
+
+This annotation IS the object description. Always include it before the view entity definition:
+
+```cds
+@EndUserText.label: 'Revenue summary by carrier'
+define view entity ZC_FlightRevenue
+  as select from sflight
+{
+  key carrid,         // IATA carrier code
+  key connid,         // Connection number
+  sum( price ) as TotalRevenue
+}
+```
+
+**Rules:**
+- **ALWAYS add** `@EndUserText.label` when creating any new CDS view entity.
+- Add `// text` line comments after non-obvious field names.
+- Use `/* ... */` for multi-line block comments if needed (e.g., explaining a complex join).
+- No `"!` or `"` comments anywhere in `.ddls.asddls` files.
+
+---
+
+## 6. When NOT to Comment
+
+The guiding principle: **comments explain *why*, not *what***.
+
+```abap
+" BAD — repeats the code, adds no value
+ls_params-mode = 'abort'.   " Set mode to abort
+
+" GOOD — explains a non-obvious rule
+ls_params-mode = 'abort'.   " INITIAL means abort (caller omitting the field = abort semantics)
+```
+
+**Do NOT add comments when:**
+- The comment would just restate the variable name or method call.
+- A private helper method simply delegates to an interface method (the name is self-explanatory).
+- `@parameter` description would be identical to the parameter name (e.g., `"! @parameter iv_name | Name`).
+- You are modifying existing code and the task did not ask for documentation changes.
+
+**DO add comments when:**
+- The logic involves a non-obvious ABAP-specific behaviour or workaround.
+- There is a caller precondition that cannot be expressed in the method signature.
+- A COND/SWITCH mapping table needs to explain the business rule behind each branch.
+- A loop exit or CONTINUE has a non-obvious condition.
+
+---
+
+## 7. Quick Decision Table
+
+| Object | Where | Style | Required? |
+|--------|-------|-------|-----------|
+| CLAS (global) | Before `CLASS DEFINITION` | `"! <p class="shorttext synchronized">` | **Always** |
+| CLAS public method | Before `METHODS` in DEFINITION | `"! desc` + `"! @parameter` | Yes (new objects) |
+| CLAS private/protected method | Before `METHODS` in DEFINITION | `"! desc` | Only if non-obvious |
+| INTF method | Before `METHODS` in interface | `"! desc` + `"! @parameter` | **Always** |
+| PROG | First lines before `REPORT` | `*&---` block | **Always** |
+| DDLS view entity | Before `define view entity` | `@EndUserText.label` annotation | **Always** |
+| DDLS field | After field name | `// text` | For non-obvious fields |
+| Method body | Inside `METHOD...ENDMETHOD` | `" text` | Only for non-obvious logic |
+| TYPES block | Before `TYPES:` in interface/class | `" text` | Optional — `"!` is invalid here |

package/abap/guidelines/common-errors.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Common ABAP Errors
-nav_order: 14
+nav_order: 12
 parent: ABAP Coding Guidelines
 grand_parent: ABAP Development
 ---

package/abap/guidelines/debug-dump.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Dump Analysis Guide
-nav_order: 16
+nav_order: 19
 parent: ABAP Coding Guidelines
 grand_parent: ABAP Development
 ---

package/abap/guidelines/debug-session.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Debug Session Guide
-nav_order: 15
+nav_order: 18
 parent: ABAP Coding Guidelines
 grand_parent: ABAP Development
 ---

package/abap/guidelines/index.md

@@ -20,6 +20,7 @@ This folder contains detailed ABAP coding guidelines that can be searched using
 | `cds.md` | CDS Views |
 | `classes.md` | ABAP Classes and Objects |
 | `objects.md` | Object Naming Conventions |
+| `naming-limits.md` | Naming Length Limits (30/16/40 char rules per type) |
 | `json.md` | JSON Handling |
 | `abapgit.md` | abapGit XML Metadata Templates |
 | `unit-testable-code.md` | Unit Testable Code Guidelines (Dependency Injection) |
@@ -31,6 +32,7 @@ This folder contains detailed ABAP coding guidelines that can be searched using
 | `object-creation.md` | Object Creation (XML metadata, local classes) |
 | `cds-testing.md` | CDS Testing (Test Double Framework) |
 | `abaplint.md` | abaplint Rule Guidelines (prefer_inline trap, safe patterns) |
+| `comments.md` | Documentation Comments (ABAP DOC, shorttext, @parameter, CDS //) |
 
 ## Usage
 

package/abap/guidelines/json.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: JSON Handling
-nav_order: 8
+nav_order: 11
 parent: ABAP Coding Guidelines
 grand_parent: ABAP Development
 ---