Everything in CAP / Java
3 of 741
Domain
Signals: 2
Content
Java: Answers in Java
More: 2
Group by: Capability
EntryBySignalsLast activity
Serve your application over MCPSAP only
Model Context Protocol Adapter — CAP guideModel Context Protocol Adapter — CAP guideDocuments @cap-js/mcp and com.sap.cds:cds-adapter-mcp, service annotations, generated describe/query/call tools and local client setup. The guide records Java doc-comment configuration, unbound-action-based data changes, incomplete XSUAA PKCE support and the adapter’s governance boundaries.
LLM integrationSAP only
What an AI infra engineer sees when opening SAP's AI stack (1/3): the model gatewayWhat an AI infra engineer sees when opening SAP's AI stack (1/3): the model gatewayA first look at SAP AI Core's Generative AI Hub from someone who builds gateways outside SAP for a living: the orchestration service harmonizes provider calls onto one API (a model name string switches providers, and SAP Note 3437766 carries the current model list, token rates and deprecation dates), runs a fixed, non-reorderable module pipeline — templating, masking through SAP Data Privacy Integration, grounding, content filtering, then the model call — and retries down an ordered fallback list whose entries can each carry their own model and rules. It places @sap-ai-sdk/orchestration among the official JavaScript, Java and Python SDKs, and notes SAP's own LiteLLM provider as a way to put a different gateway in front of it.amishkush, published 2026-09-30
Under no capability
The Full Picture: Federating, Replicating, and Caching Remote Data in CAP — Part 1The Full Picture: Federating, Replicating, and Caching Remote Data in CAP — Part 1Part one of two, and the concepts half: terminology, what CAP already does, and what a project still has to write. It fixes a vocabulary — federation is the umbrella for making remote data part of your model, delegation forwards each request to the remote at query time, replication is a scheduled copy into the local database, and caching is an option on either rather than a third strategy — which collides with CAP's own, since what this series calls replication is what the CAP-level Data Federation guide calls federation. From the ground the Service Integration guide covers, it lists what is left to hand-write: cross-service $expand, navigation filters across the boundary, write forwarding, timeouts and retries, then scheduling, delta detection, backoff, a guard for two app instances sharing one schedule, idempotent writes, and knowing whether the last run succeeded. That list is why the edge to cds-data-federation holds: the second half maps it onto @federation.delegate and @federation.replicate and says which package carries which part — annotations in cds-data-federation, the scheduled engine in cds-data-pipeline, response caching through cds-caching — so it is the design rationale for the annotations, not the API reference. The gap list and the plugins answering it come from the same person who maintains them; cap-replication-demo and SAP's xtravels sample are cited as the hand-written form of the same work. Part 2 is announced as a walkthrough of a demo application and is not covered here.
