Rejecting bad input before it reaches the database. While this can be done manually inside a handler, there are solutions in place to derive type, range, enum and mandatory checks from the model definitions.
@sap/cds Enforces @mandatory, @assert.range, @assert.format, @assert.target and @assert with a CXL case expression whenever data is written: the static checks on the input, the expressions collected into one query and run in the database, and a failure rejects the request and rolls the transaction back.
com.sap.cds:cds-services-bom Enforces declarative @assert and @mandatory constraints whenever data is written, and translates the resulting validation error messages out of the box.
Not covered: It stops at what a range, a regular expression or a CXL expression run in the database can say about an entity's elements: @assert.format takes a pattern and has no named format such as email or uri, and @assert.target does not check across services or against a target created in the same deep insert. Past that the check is a before handler of the developer's own, or a second vocabulary: JSON Schema keywords per element, evaluated by AjvAjvA JSON Schema validator for JavaScript. Where something here validates against JSON Schema rather than against the CDS model, Ajv is what compiles the schema and runs it., in sap-cap-validator-pluginsap-cap-validator-pluginA CAP plugin that checks incoming data against JSON Schema rules written as @Validator annotations on model elements, evaluated by Ajv, with no handler to register.independent, cap, and Zod schemas registered in a before handler in cds-validatecds-validateA package that runs Zod schemas as CAP validation middleware, so one schema replaces the hand-written checks at the top of a handler and failures come back as OData 422 errors per field.independent, cap. capire's own advice at that edge is to try the declarative constraints first and to write the before handler only past them; in CAP Java the Before phase is the one meant for validating the incoming parameters.
In ABAP the rules sit in ABAP Dictionary, on domains, data elements and check tables, and the screen applies them. Code that takes data in without a screen calls a check of its own, by type in abap-data-validator or against fixed values in abapDomCheck.
On a classic dynpro, fields that refer to ABAP Dictionary are checked before PAI runs: a value must exist in its check table and be one of its domain's fixed values. In RAP, a validation declared in the behavior definition runs in the save sequence and can reject an instance, with its check written in the behavior pool.
Not covered: At the screen. Data that reaches the system through an upload, an RFC call or a program passes no dictionary check, and a RAP validation checks only what its author implemented.
In a UI5 app input is checked in the browser, against the type of the property it is bound to, before it reaches the model; the service behind it still checks what it receives.
Data types check user input on its way into the model: a type's constraints, the maximum of an Integer say, are validated when the input is parsed, the OData types carry the property facets as constraints, and a custom type implements validateValue. With handleValidation set in the manifest or on the component, a failed check becomes a validation message on the control's property.
Not covered: At the input of one bound property: the documentation places the check in parsing what was entered and creates the message when the data changes, and it describes no check of a whole form at once.
No community artifact is documented here.
Neither the package manifest nor the repository tree declares a licence.
@assert.range accepts open intervals, a min or max wrapped in parentheses, and an underscore for infinity. Before this release a range was a closed [min, max] and a one-sided bound needed a case expression or a handler. CAP Java gained the same in 3.5.0.
Advice that @assert.range cannot express 'strictly positive' or an unbounded side, and the before handlers written for that.
capability:input-validation