# Sap Commerce Task Development

> Use for backend SAP Commerce implementation work that must stay project-agnostic and extension-driven: service/facade/controller layering, items.xml and beans.xml contract changes, Spring XML wiring, ImpEx/patch updates, and build verification. Trigger for feature delivery, refactors, integrations, OCC backend APIs, cronjobs, and data-model updates. Exclude frontend/storefront work and extension scaffolding.

- Skill: `commerce-cloud-integrations/sap-commerce-task-development` (Agent Skill, multi-file: 65 files)
- Install (CLI): `npx skillmds@latest add commerce-cloud-integrations/sap-commerce-task-development`
- Raw SKILL.md: https://api.skillmd.com/api/skills/commerce-cloud-integrations/sap-commerce-task-development/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: commerce-cloud-integrations (https://skillmd.com/u/commerce-cloud-integrations)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/commerce-cloud-integrations/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](references/backend-basics.md) - layering, package ownership, service/facade/controller rules
- [references/model-and-contracts.md](references/model-and-contracts.md) - `items.xml`, `beans.xml`, DTO generation, mapping
- [references/spring-impex-checklist.md](references/spring-impex-checklist.md) - Spring wiring and ImpEx/patch placement
- [references/verification-and-done.md](references/verification-and-done.md) - verification flow, done checks, reporting format
- [references/gotchas.md](references/gotchas.md) - frequent SAP Commerce implementation failure modes
- [references/guides-index.md](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](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.