Code Generation

SAP Code Generation

This skill enforces clean, cloud-ready, fully tested SAP code generation. It makes generating non-compliant, untested, or undocumented code structurally impossible.

Iron Laws

1. ALWAYS USE ABAP CLOUD RESTRICTED SYNTAX FOR CLOUD DEPLOYMENTS. Code targeting ABAP Cloud (BTP ABAP Environment, S/4HANA Public Cloud, or any tier marked Cloud-ready) must use only the ABAP Cloud restricted language subset. No classic ABAP statements incompatible with the cloud runtime. Verify via ATC with ABAP Cloud check variant before delivery.
2. NEVER ACCESS DATABASE TABLES DIRECTLY — USE RELEASED APIS. Custom code must never SELECT directly from SAP-delivered application tables (BKPF, BSEG, VBAK, EKKO, MARA, and equivalent). Access data through released CDS entities, released function modules, or released OData/RAP APIs. Direct table access creates upgrade risk and clean core violations.
3. ALWAYS INCLUDE ERROR HANDLING. Every CALL METHOD, CALL FUNCTION, database operation, and external call must have explicit error handling — checked exceptions, SY-SUBRC evaluation, or TRY/CATCH blocks. Silent failures are defects delivered as features.
4. ALWAYS GENERATE UNIT TESTS. Every class and every method generated must have a corresponding ABAP Unit test class (LOCAL FRIENDS if needed for private method access). Untested code is unverified code — it may work or it may not, and you cannot tell which.
5. FOLLOW Z/Y NAMING CONVENTIONS. All generated objects use Z or Y prefix (or registered customer namespace). Generated classes: ZCL_, interfaces: ZIF_, CDS views: Z_, RAP business objects: ZI_ (interface) / ZC_ (consumption) / ZA_ (abstract) / ZR_ (restricted). No SAP namespace pollution.

Rationalization Table

Red Flags

Watch for these phrases in your own reasoning — each one signals non-compliant code is about to be generated:

• "I'll just SELECT from the table directly..." → Iron Law 2. Find the released CDS entity or API. If one does not exist, escalate — do not create a clean core violation.
• "Tests can be added later..." → Iron Law 4. Later means never. Tests are generated with the code, in the same step, in the same transport.
• "Classic ABAP is fine here..." → Confirm the target platform. If ABAP Cloud, it is not fine. If on-premise, document the decision.
• "This is just a prototype, error handling can be skipped..." → Iron Law 3. Prototypes become production code. Generate it right the first time.
• "The naming convention makes the class name too long..." → Iron Law 5. SAP allows 30-character class names. Use them. Abbreviate thoughtfully and consistently.
• "We don't need an interface, just the class..." → Clean OO design uses interfaces. Generate the interface first. The class implements it. This costs 10 minutes and saves weeks of refactoring.
• "I'll hardcode the value for now..." → No hardcoded values. Constants class or customizing table. Always.

Generation Process

Step 1 — Establish Platform and Standards

Confirm the target deployment platform before writing a single line:

• ABAP Cloud (BTP ABAP Environment / S/4HANA Public Cloud): Restricted ABAP syntax, released APIs only, RAP for transactional services, CDS for data exposure, ABAP Unit mandatory, ATC Cloud check variant.
• S/4HANA On-Premise / Private Cloud: Full ABAP syntax available but clean core compliance strongly recommended. Released APIs preferred. Classic enhancements acceptable where RAP/CDS equivalents do not exist.
• BTP CAP (Cloud Application Programming Model): Node.js or Java CAP service, CDS data model, OData V4 exposure, Jest or JUnit tests, SAP BTP service bindings.
• Fiori Elements: OData V4 + RAP back-end, Fiori Elements floor plan selection (List Report, Object Page, Worklist, Analytical List Page), no custom frontend JavaScript unless unavoidable.

Evidence: Platform confirmation documented. Language standard and API restriction level recorded. Gate: Platform confirmed. Correct standard applied. No cross-platform ambiguity.

Step 2 — Design Data Model and API Dependencies

Before generating code, document:

• Entities being read or modified (with released CDS name or API name — not physical table name)
• Key fields and relationships
• Authorization objects required for data access
• External dependencies (RFC destinations, OData services, message channels)

For RAP: define the business object structure (root entity, child entities, associations), key determination strategy, and draft handling requirement. For CDS: define view hierarchy (basic interface view → composite interface view → consumption view) and required annotations. For CAP: define the CDS data model (.cds schema) and service definition before generating handlers.

Evidence: Data model diagram or written entity/relationship description. Released API list with SAP transaction TAANA or API Business Hub reference. Gate: No physical table names in the design (released CDS entities or API names only). All authorization objects identified.

Step 3 — Generate Structure Before Logic

Generate the structural skeleton before any business logic:

• ABAP OO: Interface first (ZIF_), then class declaration (ZCL_) implementing the interface, then empty method implementations with correct signatures.
• RAP: Behavior definition (BDEF) and behavior implementation class (ZBEH_) before projection layer.
• CDS: Basic interface view first, then composite/TP view, then consumption view with annotations.
• CAP: Service definition (.cds) and entity definitions before event handler implementations.

Evidence: Skeleton generated and compiles without syntax errors. All method signatures match the interface. No business logic yet — structure only. Gate: Structure compiles clean. Naming follows Iron Law 5. No implementation logic until structure is approved.

Step 4 — Generate Unit Tests in Parallel with Logic

For every method containing business logic, generate the test class in the same step:

• Test class structure: CLASS zcl_[name]_test DEFINITION FOR TESTING RISK LEVEL HARMLESS DURATION SHORT.
• Cover: happy path, empty input, boundary conditions, error conditions (authorization failure, not-found, invalid data).
• Use test doubles for dependencies: CL_ABAP_TESTDOUBLE for class mocking, CDS_TEST_ENVIRONMENT for CDS unit tests, IF_OSQL_TEST_ENVIRONMENT for ABAP SQL test doubles.
• For RAP: use CL_BOTD_MOCKEMLAPI_BO_TEST_ENV for behavior unit tests.

Evidence: Test class generated alongside implementation class. All methods have at least happy path and one error path test. Tests execute and pass. Gate: Tests execute without syntax errors. Tests pass for the generated logic. Test coverage includes at minimum the public interface methods.

Step 5 — Generate Implementation Logic

Implement business logic following these non-negotiable patterns:

• Error handling: Every external call uses TRY/CATCH or checks SY-SUBRC immediately. No call without handling.
• Database access: Released CDS entities via ABAP SQL only (SELECT FROM zcds_entity). No SELECT from physical tables.
• Internal tables: SORTED TABLE with unique/non-unique key for sorted access, HASHED TABLE for keyed lookup, STANDARD TABLE only for sequential processing. Declare at point of use.
• String handling: String templates `|{ lv_field }|` preferred over CONCATENATE for modern ABAP. CONCATENATE only for downward compatibility targets.
• Constants: All literal values that could change are in a constants interface (ZIF_[DOMAIN]_CONSTANTS) or customizing table. No magic numbers or strings in logic.
• Commit control: COMMIT WORK only in the outermost caller (application program or RAP save sequence). Never inside methods, function modules, or class constructors.

Evidence: Implementation compiles and passes all unit tests. ATC run with no P1/P2 findings. Gate: Unit tests pass. ATC P1/P2 clean. No hardcoded values. Error handling present on every external call.

Step 6 — Generate Documentation

Every generated object requires inline documentation:

• Class header: purpose, author, creation date, key dependencies.
• Method header: purpose, parameters description, raised exceptions, usage example if non-obvious.
• Complex logic blocks: "why" comment, not "what" (the code states what, the comment explains why the design decision was made).

Evidence: All public methods have documentation headers. Complex blocks have explanatory comments. Gate: No public method without documentation header. Documentation is meaningful — not auto-generated boilerplate restating the parameter names.

Generated Code Deliverable Template

GENERATED CODE RECORD
=====================
Request ID: [Task/ticket number]
Platform: [ABAP Cloud / S/4HANA On-Premise / BTP CAP / Fiori Elements]
Generated by: [Developer name]
Date: [Date]
ATC Variant: [Cloud / Standard / Custom - used for check]

OBJECTS GENERATED
-----------------
[Object type] | [Object name] | [Description]
[e.g., Class | ZCL_INVOICE_PROCESSOR | Core invoice processing logic]
[e.g., Interface | ZIF_INVOICE_PROCESSOR | Public interface for invoice processor]
[e.g., Test Class | ZCL_INVOICE_PROCESSOR_TEST | Unit tests for invoice processor]
[e.g., CDS View | ZI_INVOICE_HEADER | Interface view on I_JournalEntryItem]

DATA DEPENDENCIES
-----------------
Released API / CDS Entity: [Name] → [Purpose]
Authorization object: [Object] → [Activity / Field values required]
RFC destination: [Destination name] → [Purpose] (if applicable)

ATC RESULTS
-----------
ATC run date: [Date]
Check variant: [Variant name]
P1 findings: [Count — must be 0]
P2 findings: [Count — must be 0]
P3 findings: [Count + disposition]

UNIT TEST RESULTS
-----------------
Test class: [Name]
Methods tested: [List]
Pass: [Count] / Fail: [Count]
Coverage: [%] (target: all public methods)

TRANSPORT
---------
Transport number: [DEVK9XXXXX]
Objects included: [List]

Verification

This skill is complete ONLY when ALL of the following are true:

• Target platform confirmed and appropriate language standard applied
• All data access uses released CDS entities or APIs — no direct physical table access
• Class/interface structure follows naming conventions (ZCL_, ZIF_, ZI_, ZC_)
• All external calls have explicit error handling — no unhandled calls
• Unit test class generated with tests for all public methods
• Unit tests pass — zero failures
• ATC run completed with zero P1 and P2 findings
• No hardcoded values — constants class or customizing for all literals
• Documentation headers generated for all public methods and classes
• Generated code record completed with all objects, dependencies, and test results

Evidence required: ATC results export showing P1/P2 clean, unit test run results showing all passing, generated code record, transport number.

Next Skill

After completing this skill, invoke: code-review Conditions for handoff: After all generated code compiles, passes unit tests, and is ATC-clean, submit the transport for code-review. Attach the generated code record as context — the reviewer needs the platform, API dependencies, and ATC results to conduct an efficient review.

Cross-References

• Use code-review to review all generated code before transport release
• Use troubleshooting if generated code produces runtime errors during testing
• Use performance-tuning if generated code shows performance issues under test data volume
• Use development-workflow for transport creation and management