- generator: budget floor (2x oracle activations, 3x calls), static checks for CDS $parameters and UNION annotation - harness/mutation.py: deterministic mutants of the reference; hidden tests must fail - G0022 revalidated with harness fixes: oracle 100, null 0 - results in docs/faz1-tasarim.md 11f Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
38 lines
1.4 KiB
Markdown
38 lines
1.4 KiB
Markdown
# 1. Goal
|
|
Two tables hold partner lists. A report and an OData service must read one
|
|
single list of all partners. Each row must show from which table it comes.
|
|
|
|
# 2. Open questions
|
|
None.
|
|
|
|
# 3. Context
|
|
- Table {{P}}PART_A (partner list A), package $TMP. Key: PARTNER_ID (CHAR 10).
|
|
Fields: NAME (CHAR 40), CITY (CHAR 40).
|
|
- Table {{P}}PART_B (partner list B), package $TMP. It has the same structure.
|
|
- A partner ID can be in both tables.
|
|
|
|
# 4. Contract
|
|
- Create the CDS view entity {{P}}I_PARTNER_ALL in package $TMP.
|
|
- Elements, with these names: PARTNER_ID (key), NAME, CITY, SOURCE.
|
|
- SOURCE is one character.
|
|
- No authorization check (#NOT_REQUIRED).
|
|
|
|
# 5. Business rules
|
|
1. The view shows every partner of {{P}}PART_A and every partner of
|
|
{{P}}PART_B. No partner is missing.
|
|
2. SOURCE is 'A' for a row from {{P}}PART_A. SOURCE is 'B' for a row from
|
|
{{P}}PART_B.
|
|
3. NAME and CITY are the values of the table that the row comes from.
|
|
4. If the same PARTNER_ID is in both tables, the view shows two rows for this
|
|
partner. One row has SOURCE 'A'. The other row has SOURCE 'B'.
|
|
5. A partner that is only in one table is shown one time.
|
|
|
|
# 6. Constraints
|
|
- Release target: 8.16.
|
|
- Out of scope: do not change {{P}}PART_A, {{P}}PART_B and {{P}}SEED_PARTNER.
|
|
|
|
# 7. Acceptance
|
|
- The view is active and has no syntax error.
|
|
- The hidden tests pass.
|
|
- Write ABAP Unit tests with CL_CDS_TEST_ENVIRONMENT in a global test class.
|