Describe your changes

Fix: HTTP 500 on plain reads from non-draft services with SDM-annotated attachments
Problem
Bumping SDM from 1.9.x to 1.10.0 caused every OData GET request returning ≥1 row from a non-draft service to fail with HTTP 500:

CdsElementNotFoundException: No element with name 'IsActiveEntity' in
'..fileContent'
(service 'PersistenceService$Default', event 'READ')

at DBQuery.getAttachmentsForUPID(DBQuery.java:57)
at SDMReadAttachmentsHandler.lambda$populateUploadableFlags$3(SDMReadAttachmentsHandler.java:493)
Root cause: populateUploadableFlags is a new @after handler introduced in 1.10.0 that runs on every successful read of any entity whose composition carries @SDM.Attachments.maxCount. When the parent entity returns rows, it calls DBQuery.getAttachmentsForUPID, which unconditionally SELECTs IsActiveEntity. CAP only generates that element on entities under a @odata.draft.enabled service — non-draft services don't have it, so the CQN model resolution throws at query-build time.

The same latent assumption exists in getAttachmentsForUPIDAndRepository and getAttachmentsForFolder, but those methods were only reachable via attachment-side actions (upload/download/delete) which non-draft services typically don't expose. populateUploadableFlags is the first SDM handler to put this assumption on the plain parent-read path.

Fix
Two targeted changes, matching the defensive pattern already established in resolveAttachmentEntityForCount and populateUploadableFlagsViaUp:

SDMReadAttachmentsHandler.populateUploadableFlags

Compute entityHasDraftSupport once per handler invocation using target.findElement("IsActiveEntity").isPresent()
Gate rowIsDraft on that flag — non-draft entities always resolve to false (active) without attempting to read an absent field
DBQuery.getAttachmentsForUPID / getAttachmentsForUPIDAndRepository / getAttachmentsForFolder (active-entity fallback)

Build the SELECT column list dynamically
Only include "IsActiveEntity" when attachmentEntity.findElement("IsActiveEntity").isPresent()

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist before requesting a review

• I follow Java Development Guidelines for SAP
• I have tested the functionality on my cloud environment.
• I have provided sufficient automated/ unit tests for the code.
• I have increased or maintained the test coverage.
• I have ran integration tests on my cloud environment.
• I have validated blackduck portal for any vulnerability after my commit.

Upload Screenshots/lists of the scenarios tested

• I have Uploaded Screenshots or added lists of the scenarios tested in description