AMDP Part 4: Parameters, Internal Tables and Client Handling

📌 KEY POINTS
✅ All AMDP parameters are passed BY VALUE; elementary types and flat internal tables are allowed.
✅ Input internal tables arrive as table variables (read with :it_name); outputs are assigned (et_x = SELECT …).
✅ Client: filter tables with SESSION_CONTEXT('CLIENT'); for CDS views use the CDS SESSION CLIENT option.
⚠️ SQL NULL is not ABAP initial — use COALESCE for aggregates and outer joins.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–3 covered the method types. This part is about the boundary between ABAP and the database.

━━━━━━━━━━━━━━━━━━━━
▶ 1. PARAMETER RULES

• Always "VALUE( … )" — no reference passing.
• Allowed: elementary types, and internal tables with flat (non-nested) line types; no references, no nested structures, no strings in structures on some releases (check the keyword docs of your release).
• Types must be compatible with database types — use DDIC-based or clearly typed fields (dates as d/dats, amounts as p/dec).

━━━━━━━━━━━━━━━━━━━━
▶ 2. INTERNAL TABLES AS INPUT
Passing a list of keys is common (e.g. customers selected in ABAP):

• In ABAP: IMPORTING VALUE(it_customers) TYPE tt_customers.
• In SQLScript it is a table variable: SELECT … FROM zsales_item AS i INNER JOIN :it_customers AS c ON c.customer = i.customer.
• Much better than building an IN list dynamically.

━━━━━━━━━━━━━━━━━━━━
▶ 3. TABLE VARIABLES INSIDE SQLSCRIPT
lt_open = SELECT …; — then use :lt_open in later statements. HANA optimizes the whole block, so steps stay set-based.

━━━━━━━━━━━━━━━━━━━━
▶ 4. NULL AND TYPE DIFFERENCES

• Outer joins and aggregates over no rows return NULL, not 0 or ''. ABAP receives initial values, but calculations inside SQLScript with NULL yield NULL.
• Use COALESCE( SUM( amount ), 0 ).
• Dates: ABAP DATS is 'YYYYMMDD' text in the database; use TO_DATE/DAYS_BETWEEN appropriately.
• Decimal precision: define result types generously and round explicitly.

━━━━━━━━━━━━━━━━━━━━
▶ 5. CLIENT HANDLING

• Tables: add mandt = SESSION_CONTEXT('CLIENT') to every client-dependent table in every statement (including joins).
• Or pass the client as a parameter (sy-mandt from ABAP) and filter on it.
• Reading CDS view entities in SQLScript: use the method option CDS SESSION CLIENT CURRENT (syntax depends on release) so client-dependent CDS views read the current client.

⚠️ WATCH OUT: forgetting one client filter in a join silently mixes data between clients.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Add IMPORTING VALUE(it_customers) to the procedure.
2. Join it in SQLScript as a table variable.
3. Add COALESCE for aggregated amounts.
4. Check every client-dependent source has a client filter.
5. Test with an empty input table and with keys that have no data.

✅ CHECKPOINT: data crosses the ABAP–HANA boundary correctly and safely.

An AMDP report showed customers with no sales as missing, and in one test system some totals were doubled. Two causes: an inner join dropped customers without items, and the join to a customer text table had no client filter, so texts from two clients multiplied rows.
The fix used the input table as the driving table with a LEFT OUTER JOIN and COALESCE, and added client filters to every client-dependent source. The team added a rule to their AMDP review checklist: "count the client filters — one per client-dependent table".

• Forgetting VALUE() in the signature.
• Nested or reference types in parameters.
• Building dynamic IN lists instead of passing an internal table.
• Missing client filter on joined tables.
• Ignoring NULL in aggregates and outer joins.
• Assuming ABAP date/decimal semantics in SQLScript.

• Pass keys as internal tables and join them as table variables.
• Use table variables for readable multi-step logic.
• Filter client on every client-dependent source (or use the CDS session client option).
• Use COALESCE for aggregates and outer joins.
• Test empty inputs and keys without data.

Questions: "How do you pass an internal table to an AMDP?", "How is the client handled in AMDP?", "What about NULL values?"
Strong answer: parameters are passed by value; flat internal tables become table variables used with :name in joins; outputs are assigned from SELECTs; client must be filtered explicitly on each client-dependent table via SESSION_CONTEXT('CLIENT') or a parameter, and CDS views need the CDS session client option; NULLs from outer joins/aggregates need COALESCE.