菜单
Handles cross-service $expand and navigation in cds-data-federation. Use when expanding local to remote, remote to local, cross-provider mashups, navigation filters, or association renames across federated entities.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Creates @federation.replicate consumption views for scheduled remote-to-local sync in SAP CAP. Use when copying remote OData or REST data locally, configuring schedule, delta sync, or the replicated aspect.
Registers cds-data-pipeline jobs via addPipeline with correct source and target shapes. Use when creating replicate, materialize, or move-to-service pipelines, configuring delta sync, schedules, or REST/OData sources.
Enables the cds-data-pipeline Pipeline Console UI for the /pipeline management API. Use when adding pipeline monitoring, running pipelines manually, viewing run history, inspecting source/target data, or scaffolding with cds add pipeline-console.
Registers cds-data-pipeline event hooks on DataPipelineService. Use when customizing PIPELINE.READ, PIPELINE.MAP, PIPELINE.WRITE, filtering records, or extending pipeline behavior without forking the engine.
Installs and configures cds-data-pipeline in a SAP CAP project. Use when adding the pipeline plugin, importing tracker schema, exposing the management OData service, or connecting to the pipeline engine.
Creates @federation.delegate consumption views on remote OData entities in SAP CAP. Use when proxying remote data, adding field renames, association renames, read-only defaults, CUD opt-in, or delegate caching.
| name | cross-service-expand |
| description | Handles cross-service $expand and navigation in cds-data-federation. Use when expanding local to remote, remote to local, cross-provider mashups, navigation filters, or association renames across federated entities. |
Every cross-service scenario has the remote side on @federation.delegate. The local side can be a plain db entity or @federation.replicate (materialized local table — query-time equivalent).
@federation.replicate has no expand scenarios of its own; it participates only as the local side.
| Your ask | Scenario | Main entity | Expand / nav target |
|---|---|---|---|
| Expand assoc on same remote provider | Delegated expand | @federation.delegate | @federation.delegate (same provider) |
| Local entity expands to remote | Cross-service expand: local → remote | local or @federation.replicate | @federation.delegate |
| Remote entity expands to local | Cross-service expand: remote → local | @federation.delegate | local or @federation.replicate |
| Multiple remote providers in one expand | Cross-service expand: cross-provider | local or @federation.replicate | @federation.delegate (different providers) |
| Navigate local → remote tail | Cross-service navigation: local → remote | local or @federation.replicate | @federation.delegate |
| Navigate remote → local tail | Cross-service navigation: remote → local | @federation.delegate | local or @federation.replicate |
CAP passes $expand as CQN column objects in req.query.SELECT.columns. The delegate handler must return nested objects — flat results yield empty expands.
The plugin:
If local assoc is buyer but remote is customer, declare the rename in the consumption view:
@federation.delegate
entity Orders as projection on remote.Orders {
customer as buyer,
...
};
Filters like $filter=buyer/name eq 'Acme' translate to remote customer/name.
❌ Wrong — expecting @federation.replicate to proxy live $expand to the remote.
✅ Correct — replicate materializes locally; use it as the local side, delegate on the remote side.
❌ Wrong — @federation.delegate on both sides when providers differ without understanding cross-provider stitching.
✅ Correct — each remote entity is its own delegate view; local entity holds FKs; plugin handles multi-hop expand.
❌ Wrong — hand-splitting expand queries in application code when annotations already define the federation contract.
✅ Correct — model associations in CDS; issue a single OData query with $expand.