Sap Commerce Task Development

SAP Commerce Task Development

Overview

Use this skill for backend SAP Commerce delivery with strict boundaries, predictable architecture, and maintainable implementation.

Keep the workflow project-agnostic: align to repo conventions, isolate ownership per extension, and preserve SAP Commerce layering.

Trigger Checklist

Use this skill when one or more are true:

• implementing or refactoring SAP Commerce backend logic
• changing service/facade/controller flows
• changing *-items.xml, *-beans.xml, Spring XML, or ImpEx patches
• adding or updating OCC backend endpoints
• implementing integrations, cronjobs, or model-driven features

Out Of Scope

Do not use this skill for:

• storefront/frontend work (Spartacus, Angular, JSP/UI)
• extension scaffolding/generation guidance (extgen, extension templates)
• generic testing tutorials or framework primers
• script-driven skill workflows

Progressive Disclosure

Keep this file focused on workflow; load detail files only when needed:

• references/backend-basics.md - layering, package ownership, service/facade/controller rules
• references/model-and-contracts.md - items.xml, beans.xml, DTO generation, mapping
• references/spring-impex-checklist.md - Spring wiring and ImpEx/patch placement
• references/verification-and-done.md - verification flow, done checks, reporting format
• references/gotchas.md - frequent SAP Commerce implementation failure modes
• references/guides-index.md - curated deep reference catalog + backend template map

Curated Guides Library

A curated SAP Commerce guides set is available under references/guides/ and references/templates/.

Use it when task scope needs deeper examples, but stay backend-only.

Explicit exclusions are enforced:

• no extension-structure scaffolding
• no frontend/storefront assets
• no testing-guide content
• no scripts workflows

Delivery Workflow

1. Clarify scope, acceptance criteria, and extension ownership.
2. Confirm layer boundaries before coding (controller/facade/service/DAO/model).
3. Implement model and contract changes (items.xml, beans.xml) where needed.
4. Implement business logic in service/facade layers; keep controllers orchestration-only.
5. Update Spring XML wiring and mappings in the owning extension.
6. Update ImpEx/patch artifacts in the project-defined location.
7. Run project-standard verification commands for the changed scope.
8. Report changes, decisions, verification evidence, and remaining risks.

Non-Negotiable Standards

• Keep business logic out of controllers.
• Keep interface + impl structure for services/facades/clients/strategies.
• Prefer generated DTO/Data artifacts from *-beans.xml over handwritten classes when generation is available.
• Keep items.xml types, enums, and attribute descriptions explicit and stable.
• Use explicit Spring bean wiring; add aliases only for real overrides.
• Keep methods cohesive and low-complexity; extract helpers instead of nesting.

Gotchas

Use references/gotchas.md when implementation drifts. Record the issue and the mitigation in your task notes.

Completion Output

At the end of delivery, report:

1. Files changed and rationale.
2. Architectural decisions and tradeoffs.
3. Verification commands executed and outcomes.
4. Build/test status for changed scope.
5. Remaining risks and follow-up actions.