CDS Views

In complex industries like steel, automotive, or machinery, configuration logic often depends on rich, interconnected master data—such as product forms, specifications, grades, coatings, and packaging. Managing such dependencies using static AVC tools like variant tables can quickly become rigid, error-prone, and disconnected from live business data.

The mdVC CDS connector solves this by linking configuration characteristics directly to CDS views. These views can represent complex dependencies from various data sources—SAP master data, QPPD models, custom logic, or even external systems—evaluated dynamically at runtime. This enables master data–driven configuration with high flexibility and no duplication of logic.

info

While the following example references QPPD Views, the CDS connector is fully generic. It can be used with any data source—internal or external (Custom Entity CDS View).

Why CDS Instead of AVC Logic?

AVC dependencies—especially variant tables—have several limitations:

• Manual maintenance effort
• Risk of inconsistencies
• No reuse outside of AVC
• Disconnected from actual business data

By contrast, CDS views offer:

• Full modeling flexibility (joins, enrichment, filters, semantics)
• Live access to real master data
• Reuse across applications (Fiori apps, reporting, APIs)
• Centralized, declarative business logic

Using CDS makes configuration transparent, data-driven, and scalable—a best practice for S/4HANA-based modeling.

How It Works

A configuration instance is linked to a CDS consumption view, which collects and resolves dependencies. Multiple CDS view groups can be involved (technically, this means multiple CDS tasks). Each view filters valid values or derives characteristic values at runtime.

By default, characteristics are matched to CDS view fields by name. However, field mappings can be customized when defining the task. The CDS view consolidates data from various sources and exposes valid combinations to the configuration process.

Behavior and Scope

The CDS connector task executes the following logic:

• Restrict value help based on current characteristic values
  (e.g. only certain packaging types are valid for "Sea" transport)
• Auto-determine values when only one valid option remains
  info

  Determination only applies if the user hasn’t already entered a value.

• Set characteristics to read-only when only one valid value exists
• Validate uniqueness: the current combination of values must match exactly one CDS row. Otherwise, an error is raised.

This ensures that configuration stays consistent with the actual business logic modeled in master data.

Example with Data

Configuration Instance (User Input)

Characteristic	Value
Product Form	COIL
Product Type	CR
Specification
Specification Extension
Grade Name
Galvanizing Class
Packaging

CDS Consumption View

The following table shows all available combinations. Rows not matching the user input (e.g. invalid product type/form) are excluded from evaluation.

Product Form	Product Type	Specification	Specification Extension	Grade Name	Galvanizing Class
COIL	CR	EN10130:2006		DC01	No
COIL	CR	EN10204	4711	DC01	No
COIL	CR	EN10204		DC03	No
COIL	HDC	EN10168		DC05	A
SHEET	HR	EN10204		DC03	C
PLATE	HR	EN10168		DC03	B

Configuration After CDS Evaluation

With only one matching value for Galvanizing Class, it is determined automatically:

Characteristic	Value
Product Form	COIL
Product Type	CR
Specification
Specification Extension
Grade Name
Galvanizing Class	No
Packaging

However, since more than one row remains, the configuration is still not unique, and an error is raised:

info

Most of the time it’s recommended to wrap the CDS connector task in a Settler Task to re-evaluate logic as values evolve dynamically.

Available Values (Value Help)

Product Form
COIL

Product Type
CR
HDC

Specification
EN10130:2006
EN10204

Specification Extension
4711

... and others ...

Task

To use the CDS connector, instantiate the task class /mxp/vcha_cl_va_cds_link and pass your CDS view name:

new /mxp/vcha_cl_va_cds_link( 'ZC_MY_CONSUMPTION_VIEW' )

By default, all characteristics with name-equal CDS fields are considered. You can optionally define:

• Field mappings (custom characteristic ↔ field name)
• Ignored fields
• Parameter definitions (e.g., THICKNESS as a CDS view parameter P_THICKNESS)

new /mxp/vcha_cl_va_cds_link(
  i_cds_view_name = conv #( cl_abap_structdescr=>describe_by_data( value zc_my_consumption_view( ) )->get_relative_name( ) ) "in order to make where used work, get the name dynamically
  i_parameter_definitions = value #(
    ( characteristic_name = 'THICKNESS'
      cds_parameter_name = 'P_THICKNESS'
      cds_parameter_null_name = 'P_THICKNESS_IS_NULL' ) ) "for integers, it may be an interesting info to check whether the value is assigned or not (null) -> boolean as CDS parameter
  i_field_mappings = value #(
    ( characteristic_name = 'PRODUCT_TYPE'
      cds_field_name = 'ProductType' )
    ( characteristic_name = 'PRODUCT_FORM'
      cds_field_name = '' "initial means, do not respect it although it might exist ) ) ).

This task can be used standalone or embedded in a composite task. Wrapping it in a Settler Task is recommended for resolving interdependent logic.

info

Any CDS view used by a CDS task must be released for system-internal use to comply with clean core principles (contract C1).

In the example shown, the CDS view ZC_MY_CONSUMPTION_VIEW must be explicitly released. This ensures it can be safely consumed by the framework at runtime.

Follow the standard release process: