Virtual Elements in CDS Views

A virtual element is a field declared on a CDS view or projection that has no backing database column and no expression evaluated by the database. Instead it is annotated to point at an ABAP class implementing a calculation exit, and that class is invoked by the SADL runtime while assembling an OData or RAP response, receiving the key fields of the requested rows and returning the computed values to be merged in. The one fact that explains most of the confusion: this calculation only happens inside the SADL read path used by OData/RAP services. Query the same CDS view with a plain SELECT, run it through a table function, open it in a data browser, or hit it from a background report, and the virtual element field comes back blank or initial, because none of those access paths go through the exit class. Developers who expect it to behave like a normal computed column in every context are consistently surprised by this.

Reach for a virtual element when the value genuinely cannot be expressed inside the CDS view definition itself: something dependent on the current user, the current date and time at the moment of the request, an external system call, or a business rule too irregular for a CASE expression or arithmetic in SQL. Typical cases are a status icon derived from a combination of fields plus a runtime condition, or an overdue flag computed against today's date. Do not use it as a substitute for logic that CASE, arithmetic, currency conversion functions, or a table function can already express inside the view; those execute in the database and are far cheaper. Also avoid it when the field needs to be filtered or sorted by the consuming app, or when the same calculated value is needed outside an OData/RAP context, such as in a background job or an IDoc mapping.

Below the virtual element sits the CDS view entity or projection view carrying the annotation, and below that the exit class doing the actual computation. Above it sits the service definition and service binding, or the RAP business object's projection layer, through which the SADL runtime is triggered when an OData or RAP consumer requests the field. It sits alongside, but is not the same mechanism as, RAP determinations: a determination computes and persists a value as part of a transactional save, while a virtual element computes a transient value fresh on every read and never touches the database. It effectively replaces older patterns from classic SEGW-based OData services where the same 'calculate on read' logic lived in generated DPC extension class methods; virtual elements move that logic into a declared, annotated exit class attached directly to the CDS layer instead of hand-written provider class code.

A sales order item CDS projection needs an OverdueFlag field that is true when the requested delivery date has passed and the item is still open, a condition not worth persisting because it changes every day without any write happening. The field is declared on the projection with a virtual element annotation and a reference to a calculation class. When a Fiori list report requests the field in its $select, the SADL runtime collects the key fields of the rows on the current page and calls the class once with that batch, not once per row. The class reads the delivery date and status from the keys passed in, applies the date comparison, and returns a table of computed values keyed the same way, which SADL merges back into the OData response before it reaches the UI. Nothing about this logic exists in the database; it recomputes on every page fetch. If the same flag were needed in a background report driving order cleanup, that report would need its own logic, because it never goes through SADL and the virtual element stays blank there.

Virtual elements remain a supported mechanism in S/4HANA and are the standard implementation behind several key-user-defined custom fields flagged as calculated rather than stored. For developer-managed extensibility, clean core guidance discourages attaching custom virtual-element exit classes to standard SAP-delivered CDS views through append-style modification; the supported path is a CDS view extension in the customer namespace with its own registered class. In a public cloud ABAP environment, the exit class and any base interface it implements must be built against released APIs, since reliance on internal SADL classes or unreleased interfaces is a known source of upgrade breakage. Directly modifying a standard SAP exit class to add logic is discouraged regardless of environment.

This is a developer-level implementation decision, but an architect should sign off on it early, since choosing a virtual element over a push-down calculation affects filtering, sorting, and clean core compliance. Functional consultants flag the business need for a computed, non-persisted field; the handover to development should state the annotation, the exit class name, and any known limitation on filter or sort support for that field.

Compare against determinations and validations in RAP to decide between a transient calculated field and a persisted one computed at save. Review CDS annotations and where they take effect to understand why the annotation driving a virtual element only activates in specific consumption paths. Check OData query options and server-side paging before promising filter or sort support on a virtual field, and read CDS view entities versus classic CDS DDIC views for the broader context of what belongs in the view layer versus the exit class.