Leveraging HANA DB subscriptions on SAP BTP alongside the CAP model is one of the most robust combinations for developing resilient applications. Consider a scenario where the Integration Suite fails to post data—whether it’s HR data or another document posting. In such cases, error details and the associated payload can be logged into tables on BTP. A front-end UI can then be quickly built to analyze these errors and re-trigger the process without any need for customization in S4. This scenario is likely familiar to many of you, as handling failures effectively is a common business challenge.
When posting data to the CAP model via oData V4, you might encounter error code 413, which signifies that the request payload is too large. While the fix has been implemented in the npm package "@sap/cds" version "^8.1" (so make sure to upgrade your npm), it is still important—considering both performance and scalability—to set a maximum limit on the payload size. Although the recommended size limit may vary depending on specific application requirements, the default value is generally suggested to help minimize DoS attack vectors. If only a single endpoint needs to handle larger payloads, it is best to configure that endpoint individually rather than applying a global change.
The most common risk with oversized payloads is the potential to exhaust the service’s memory, which can cause a crash. Therefore, a payload limit of 10 MB is often an optimal choice that meets most requirements. You can specify this limit directly in your service file with an annotation, like so:
annotate <CatalogService>.<Entity> with @cds.server.body_parser.limit: '10mb';
Alternatively, you can set it in the project.json file as follows:
"server": { "body_parser": { "limit": "10mb" } } Personally, I prefer using the annotation method. I hope this information proves helpful, and I look forward to sharing more insights in future blogs.
Bluesky
