Attachments
Storing a file somebody uploaded next to the record it belongs to, and getting it back out — where the bytes actually live, who may read them, and what the UI shows while they are being scanned.
Showing artifacts, examples and content with confirmed Java applicability. View All CAP
Overview
Adds attachment storage and handling to CAP Java through an Attachments aspect. The base Maven dependency stores content in the database; com.sap.cds:cds-feature-attachments-oss selects AWS, Azure or Google Object Store storage.
Stores CAP Java attachments in an SAP Document Management repository through an Attachments aspect. It documents draft handling and direct attachment creation on active entities.
A Java coverage assessment has not been written. View all flavors
No community artifact is confirmed here for Java.
A Java coverage assessment has not been written. View all flavors
Artifacts
Tasks
Keep attachment content out of the application database
A deployed CAP application keeps uploaded file content in an object store or a document repository, and keeps only the metadata and a reference in its own database.
Choosing between AWS, Azure and Google, and entitlement to any of them, are project questions and are not assessed. Moving content already written to the database is not covered by any source read here. Nothing here establishes that a deployment was run.
com.sap.cds:cds-feature-attachmentsThe base dependency stores attachments in the database. A separate module, cds-feature-attachments-oss, puts them in an AWS, Azure or Google object store instead and keeps only a reference in the database.
Conditions: The cds-feature-attachments-oss module is used as the storage target module. A valid Object Store service binding exists for the application.
Remaining work: Add the oss module and provision the binding. The base dependency alone leaves the content in the database, which is the state this task is trying to leave.
com.sap.cds:sdmThe Java counterpart of the same route: the documents go to an SAP Document Management repository the application is bound to.
Conditions: An SAP Document Management integration option service instance and key exist and the application is bound to the instance. A repository is onboarded with those credentials and its id is added to the deployment descriptor.
Remaining work: Create the instance and key, bind the application to it and onboard the repository before anything is stored.
Keep each subscriber's attachments apart in a multitenant CAP application
Each subscriber of a multitenant CAP application uploads and reads only its own attachments, and that tenant's content is removed when it unsubscribes.
Tenant isolation in the database, and the subscription mechanics themselves, belong to multitenancy and are assessed there. Whether a subaccount is entitled to one Object Store instance per tenant is a project question. Nothing here establishes that a subscription or an unsubscription was observed.
com.sap.cds:sdmOffers onboarding and offboarding APIs for repositories in a multitenant CAP SaaS application, so a tenant gets a repository rather than a share of one. What an unsubscription does when the repository cannot be deleted is stated: it fails, unless the repository was not found.
Remaining work: Call those APIs from the application's own subscription handling.
com.sap.cds:cds-feature-attachmentsWith an object store as the storage target, one bucket serves every tenant, keys are prefixed with the tenant id and a tenant's data is cleaned up on unsubscribe. With SAP HANA as the target the README puts multitenancy on the consuming application.
Conditions: An object store is the storage target, and the package is at version 1.5.0 or later. With SAP HANA as the storage target, multitenancy support depends on the consuming application.
Remaining work: On the SAP HANA target the application provides the isolation itself, and the README names a schema per tenant as the usual arrangement without specifying what the package does about it.
Keep version history for an attached document
A document attached to a business record keeps its earlier versions, so a reader can see what the file was before it was replaced.
Change tracking of the record's own fields is a different concern. Whether a customer is entitled to SAP Document Management is a project question. Versioning inside a bucket, configured on the storage service rather than by the application, is outside what these packages document. Nothing here establishes that any alternative route was built or run.
SAP Document Management service, integration optionThe service under both plugins names versioning among the document management capabilities it offers, and offers its APIs for an application to build its own document management layer on.
Remaining work: Build the record association and the upload path against those APIs. Neither CAP plugin covers a versioned repository, so this route leaves the Attachments aspect behind.
com.sap.cds:sdmStates the same exclusion in the same words as its Node.js counterpart, so switching runtime does not open the route.
Remaining work: Either drop the version requirement, or reach the document management APIs from the application without this plugin in the path.
com.sap.cds:cds-feature-attachmentsThe pinned README documents storage targets, the scanner and multitenancy. Re-read on 2026-09-20, it states nothing about replacing the content of an existing attachment and nothing about earlier versions, so the Node.js answer cannot be carried across.
Remaining work: Establish what happens to the previous content on replacement, from the plugin's model or the CAP Java documentation.
Scan an uploaded attachment before anyone can download it
A file a user uploads is scanned for malware, and a file that was never scanned does not reach a reader carrying the same status as one that was.
How well a scanner detects anything is not assessed. What the application does with an infected file, and the wording it shows a user, are its own handling. Nothing here establishes that a scan was observed running.
com.sap.cds:cds-feature-attachmentsDownload is tied to the status here too: only an attachment marked Clean is accessible. With no scanner available the attachments are marked Clean automatically, so a file nobody scanned reaches a reader through the same gate as a scanned one.
Remaining work: Bind a service instance labelled malware-scanner. Until then a Clean status says nothing about the file, which is the fact this flavor has to be checked for.
com.sap.cds:sdmNames malware scan and Trend Micro scan on repositories onboarded with virus scanning, and puts a size limit on what is scanned: only attachments up to 400 MB.
Conditions: The repository is onboarded with virus scanning enabled. Only attachments up to 400 MB are scanned.
Remaining work: Decide what happens to a file above the scanned size. The README's localization example ships a message key telling a user that files larger than 400 MB cannot be uploaded to a virus-scan repository, and states the outcome nowhere else.
Upload an attachment from a client that is not SAP Fiori elements
A caller that is not an SAP Fiori elements UI, such as a test client, a custom front end or another service, creates an attachment record against an existing business record and uploads its content.
The upload control and the client code that drives it are a UI question and are not assessed here. Who may read the file afterwards belongs to authorization. Nothing here establishes that any of these paths was run end to end.
com.sap.cds:sdmStates that attachments can be created directly on active, non-draft entities: the leading application triggers the insert on the attachment entity and the plugin picks the content up from there.
Conditions: The leading application triggers an INSERT on the attachment entity through the ApplicationService, or the DraftService that extends it. An SAP Document Management integration option service instance and key exist, the application is bound to the instance and a repository is onboarded.
Remaining work: Implement that insert in the leading application. The README documents the entry point, not the calling client.
com.sap.cds:cds-feature-attachmentsThe pinned README documents storage targets, the malware scanner and multitenancy. Re-read on 2026-09-20, it names no draft annotation, no DraftService and no request sequence, so what a caller outside SAP Fiori elements has to send is not stated. Absence of a statement is not a refusal.
Remaining work: Retrieve the CAP Java attachments documentation on capire and the plugin's own draft handling before this flavor can be answered.
Content
Details
Coverage
Comparison properties
These are the questions used to compare what the artifacts do. Values come from their documentation and may apply to a particular ecosystem or runtime. Each recorded value in the comparison opens its statement and sources.
For your agent
- Ref
capability:attachments- JSON
- /capabilities/attachments.json
- MCP
- Connecting an agent