sap-cap-architecture-review

SAP CAP Architecture Review

Purpose

Assess the architecture, security posture, and operational quality of SAP Cloud Application Programming Model (CAP) applications. Review CDS data model design for normalization, association correctness, and annotation quality. Assess the service layer for separation of concerns, projection completeness, and anti-pattern avoidance. Review authorization configuration (@requires, @restrict) for correctness and enforcement. Evaluate multitenancy design for tenant isolation, extensibility readiness, and MTX service wiring. Assess draft handling for consistency, activation logic, and side-effect completeness. Review test coverage for CAP-specific test patterns. Does not connect to or mutate any live CAP application, BTP service, or database.

When to use

Use this skill when the user asks to:

• review CDS entity and service definitions for modeling quality, association correctness, projection anti-patterns, or annotation completeness,
• assess CAP authorization annotations (@requires, @restrict) for correctness, missing access controls, or role design gaps,
• evaluate multitenancy architecture: MTX service wiring, tenant onboarding flow, extensibility activation, cds.requires.multitenancy configuration,
• review draft handling design: draft-enabled entities, activation hooks, side effects, draft lock expiry, and cancel behavior,
• audit CAP test coverage: cds.test unit patterns, integration test setup, mock authentication usage, and CDS test environment teardown,
• identify CAP anti-patterns: direct database access bypassing the service layer, missing @readonly on projection fields, incorrect up_ association exposure, or unguarded actions,
• assess CAP application readiness for SAP BTP production deployment: profile configuration, feature toggles, and package.json cds block correctness.

When not to use

• When the request is about ABAP-side RAP business objects or ABAP Cloud compliance — use sap-abap-cloud-rap-review.
• When the request is about Integration Suite iFlow or API Management configuration — use sap-integration-suite-review.
• When the request requires live CAP application inspection, database query execution, or BTP service key access — this skill accepts only user-provided code artifacts, CDS model files, package.json, or written descriptions.
• When the request is about SAP Fiori / UI5 frontend code rather than the CAP backend service layer.

Does not touch live systems

This skill operates on user-provided CDS source files, package.json configuration, srv/ handler files, test file excerpts, MTX configuration, or written descriptions of the CAP application architecture. It does not connect to any BTP subaccount, CAP runtime, HANA database, or deployment pipeline. All live inspection is out of scope.

Lean operating rules

• Classify findings before recommending. Every finding must be assigned to a review domain (CDS Modeling / Service Layer / Authorization / Multitenancy / Draft / Testing / Deployment Config) before remediation is proposed.
• Authorization is non-negotiable. A CAP service or entity with no @requires or @restrict annotation is accessible to any authenticated — or unauthenticated — caller depending on CAP runtime version. An unguarded service exposed to external callers is a critical finding.
• @restrict is preferred over @requires for entity-level access control. @requires on a service grants blanket access; @restrict with grant/to/where clauses gives fine-grained operation-level control. A service using only service-level @requires with no entity-level @restrict is a medium finding when business data sensitivity is high.
• Direct database access in service handlers bypasses CAP authorization enforcement. Any SELECT from db.run(SELECT.from(...)) inside a service handler that circumvents the CAP service layer authorization is a high finding.
• Multitenancy requires explicit MTX wiring. A CAP application configured with cds.requires.multitenancy: true but missing @sap/cds-mtxs dependency, subscriber passcode configuration, or tenant upgrade hooks is a high finding.
• Draft handling activation must be complete. A draft-enabled entity missing an activate action implementation, draftActivate side-effect hook, or proper BeforeSave validation is a high finding for transactional correctness.
• Test isolation is required. CAP integration tests that use a shared cds.test instance without proper beforeAll/afterAll teardown, or that test against a live HANA target rather than in-memory SQLite, are medium findings for test reliability.
• Evidence from official SAP CAP documentation and user-provided artifacts takes precedence over inference.
• Load only the reference needed for the component in scope.

Evidence rules

Label all claims with one of:

• documentation-based — grounded in official SAP CAP documentation (cap.cloud.sap, SAP Help Portal)
• user-provided evidence — CDS model files, service handler code, package.json, test files, or written descriptions provided by the user
• context7-supplementary — grounded in CAP framework docs fetched from Context7 (supplementary to official SAP CAP docs; applies for CDS modeling, authorization, multitenancy, and draft patterns)
• inference — derived reasoning not directly confirmed by official docs or user evidence

Live-environment rules

This skill does not touch live systems. There is no CAP runtime API call, BTP service binding access, HANA database connection, or BTP cockpit access in this skill's execution path. Users must supply CDS source files, handler code excerpts, configuration files, or written descriptions of their CAP application for this skill to review.

References

Load only when needed:

• Workflow and output contract — review domain taxonomy, severity classification, output format.
• Safety checklist — non-negotiables, common CAP mistakes, when to push back.
• Official sources — SAP CAP docs, CDS language reference, authorization guides, multitenancy, draft handling.
• Context7 framework docs — CAP authorization patterns, CDS service modeling, multitenancy, and draft handling (supplementary; strongly applies for this skill).

Response minimum

Return, at minimum:

• Problem classification: review domain(s) in scope and specific finding(s) per domain.
• Evidence used: documentation-based / user-provided evidence / context7-supplementary / inference.
• Risk level: critical (security or data integrity risk) / high (correctness or operational reliability risk) / medium (governance or maintainability gap) / low (best practice deviation).
• Recommended action: specific remediation per finding (add @restrict annotation, wire MTX service, implement draftActivate hook, add test teardown, etc.).
• Refusal / escalation triggers: if live CAP runtime access, BTP service binding, or database inspection is required to complete the review, state that clearly and do not proceed.
• Business impact: security exposure, data integrity risk, multitenancy isolation failure, or test reliability gap.
• Next verification step: validate recommended changes against the current CAP runtime version and BTP deployment target before deploying.