CDS Views Part 2: Create Your First CDS View Entity in ADT

📌 KEY POINTS
✅ Create CDS view entities in ADT: New → Data Definition → "Define View Entity".
✅ Give readable CamelCase aliases and label the view with @EndUserText.label.
✅ Set @AccessControl.authorizationCheck deliberately (#CHECK with a DCL role for business data).
💡 Test with Data Preview (F8) and check the SQL with "Show SQL CREATE Statement".

▶ SAP CDS VIEW ENTITY TUTORIAL: CREATE YOUR FIRST CDS VIEW IN ADT

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU WILL BUILD

In Part 1 you learned why CDS view entities matter. In this lesson you will create one from start to finish.

We will build a simple sales-order item view called ZI_SalesOrderItem. It will:

• read from an illustrative custom source table;
• expose clear business field names;
• define a stable key;
• model amount and currency correctly;
• add a simple association;
• activate cleanly in ADT;
• be ready for reuse in RAP, analytics or another CDS layer.

The object and field names below are illustrative. Use released SAP CDS entities instead of direct SAP internal tables when you are working in an ABAP Cloud / clean-core scenario.

━━━━━━━━━━━━━━━━━━━━
▶ PREREQUISITES / PREVIOUS PART

You should know the basic purpose of a CDS view entity from Part 1.

For hands-on work you need:

• ABAP Development Tools (ADT) in Eclipse;
• a package and transport;
• a system release that supports CDS view entities.

━━━━━━━━━━━━━━━━━━━━
▶ 1. START WITH THE BUSINESS QUESTION

Do not begin with syntax.

Ask:

What reusable business dataset am I trying to model?

For this example the answer is:

A reusable list of sales-order items with order number, item number, customer, material, quantity and net value.

That sentence becomes your design boundary.

━━━━━━━━━━━━━━━━━━━━
▶ 2. CHOOSE THE DATA SOURCE

For a training example we will use an illustrative custom table named zso_item.

Assume it contains:

• sales_order
• sales_order_item
• customer_id
• material_id
• order_qty
• sales_unit
• net_amount
• currency_code
• created_at
• last_changed_at

In a real S/4HANA clean-core design, first look for a released CDS interface view or released API that represents the business object you need.

━━━━━━━━━━━━━━━━━━━━
▶ 3. CREATE THE CDS DATA DEFINITION IN ADT

In ADT:

1. Right-click the package.
2. Choose New → Other ABAP Repository Object.
3. Search for Data Definition.
4. Enter a name such as ZI_SalesOrderItem.
5. Add a meaningful description.
6. Assign the transport.
7. Choose a view-entity template if your release provides one.

The naming convention is only an example. What matters is that your project uses a consistent convention.

━━━━━━━━━━━━━━━━━━━━
▶ 4. WRITE THE FIRST VIEW ENTITY

A minimal view entity looks like this:

┏━━ CODE ━━━━━━━━━━━━
┃ @EndUserText.label: 'Sales Order Item'
┃ @AccessControl.authorizationCheck: #CHECK
┃ define view entity ZI_SalesOrderItem
┃ as select from zso_item
┃ {
┃ key sales_order as SalesOrder,
┃ key sales_order_item as SalesOrderItem,
┃ customer_id as Customer,
┃ material_id as Material,
┃ order_qty as OrderQuantity,
┃ sales_unit as SalesUnit,
┃ net_amount as NetAmount,
┃ currency_code as CurrencyCode,
┃ created_at as CreatedAt,
┃ last_changed_at as LastChangedAt
┃ }
┗━━━━━━━━━━━━━━━━━━━

The code is short, but several design decisions matter.

━━━━━━━━━━━━━━━━━━━━
▶ 5. DEFINE THE RIGHT KEY

The key should represent the logical uniqueness of the entity.

In this example:

• Sales order alone is not unique.
• Item number alone is not unique.
• Sales order + item is unique.

So both fields are declared as keys.

Do not mark fields as keys just because the database table has them. Think about the semantic identity of the CDS entity.

An incorrect CDS key can cause problems later in OData, RAP, Fiori Elements, associations and analytical consumption.

━━━━━━━━━━━━━━━━━━━━
▶ 6. USE BUSINESS-FRIENDLY ALIASES

Physical database names often reflect implementation history.

CDS aliases should describe the business meaning.

For example, customer_id as Customer is easier for consumers to understand than exposing a technical database name unchanged.

The CDS layer should make the model easier to consume, not simply mirror persistence.

━━━━━━━━━━━━━━━━━━━━
▶ 7. ADD QUANTITY AND UNIT SEMANTICS

If a quantity has a unit field, tell CDS about the relationship.

┏━━ CODE ━━━━━━━━━━━━
┃ @Semantics.quantity.unitOfMeasure: 'SalesUnit'
┃ order_qty as OrderQuantity,
┃
┃ @Semantics.unitOfMeasure
┃ sales_unit as SalesUnit,
┗━━━━━━━━━━━━━━━━━━━

This is important for downstream consumers.

Without the semantic relationship, a UI or analytical tool sees a number and a unit field but does not know they belong together.

━━━━━━━━━━━━━━━━━━━━
▶ 8. ADD AMOUNT AND CURRENCY SEMANTICS

Do the same for money:

┏━━ CODE ━━━━━━━━━━━━
┃ @Semantics.amount.currencyCode: 'CurrencyCode'
┃ net_amount as NetAmount,
┃
┃ @Semantics.currencyCode
┃ currency_code as CurrencyCode,
┗━━━━━━━━━━━━━━━━━━━

This allows consumers to understand that NetAmount is expressed in CurrencyCode.

━━━━━━━━━━━━━━━━━━━━
▶ 9. ADD A SIMPLE ASSOCIATION

Assume you also have a reusable customer CDS entity called ZI_Customer.

You can associate the item to customer:

┏━━ CODE ━━━━━━━━━━━━
┃ define view entity ZI_SalesOrderItem
┃ as select from zso_item
┃ association [0..1] to ZI_Customer as _Customer
┃ on $projection.Customer = _Customer.Customer
┃ {
┃ key sales_order as SalesOrder,
┃ key sales_order_item as SalesOrderItem,
┃ customer_id as Customer,
┃ material_id as Material,
┃
┃ @Semantics.quantity.unitOfMeasure: 'SalesUnit'
┃ order_qty as OrderQuantity,
┃
┃ @Semantics.unitOfMeasure
┃ sales_unit as SalesUnit,
┃
┃ @Semantics.amount.currencyCode: 'CurrencyCode'
┃ net_amount as NetAmount,
┃
┃ @Semantics.currencyCode
┃ currency_code as CurrencyCode,
┃
┃ _Customer
┃ }
┗━━━━━━━━━━━━━━━━━━━

The association says that for this sales-order item, there may be zero or one matching customer entity.

The cardinality should describe reality. Do not write [0..1] automatically.

━━━━━━━━━━━━━━━━━━━━
▶ 10. ASSOCIATION IS NOT THE SAME AS JOIN

A join combines sources in the query definition.

An association defines a reusable relationship that consumers can navigate when needed.

That difference becomes important in layered CDS models and RAP.

Use the relationship that best represents the business model.

━━━━━━━━━━━━━━━━━━━━
▶ 11. ACTIVATE THE CDS ENTITY

Activate the object.

If activation fails, read the exact syntax/error message instead of changing random annotations.

Common causes include:

• field name does not exist;
• key expression is invalid;
• annotation references the wrong element name;
• association ON condition uses incompatible fields;
• target entity is inactive;
• unsupported syntax for the system release.

━━━━━━━━━━━━━━━━━━━━
▶ 12. PREVIEW THE DATA

Use ADT data preview where available.

Check:

• Are keys unique?
• Are quantities correct?
• Are currency values paired correctly?
• Are aliases understandable?
• Does the association return the expected customer?
• Are there unexpected duplicate rows?

A view that activates but returns wrong business data is not finished.

━━━━━━━━━━━━━━━━━━━━
▶ 13. ADD ONLY THE SEMANTICS THAT BELONG HERE

A reusable interface view should contain business semantics.

Good examples:

• amount/currency;
• quantity/unit;
• associations;
• text relationships;
• business keys.

Be careful with UI-specific annotations in a reusable interface entity.

For Fiori Elements, UI annotations often belong in a projection/consumption layer or metadata extension.

━━━━━━━━━━━━━━━━━━━━
▶ 14. BUILD IN LAYERS

A common clean design is:

Persistence / released source
→ Interface CDS
→ Projection or consumption CDS
→ RAP / OData / Fiori / analytics

Do not force every consumer to use one giant view.

A stable interface layer gives you room to create different consumer contracts later.

━━━━━━━━━━━━━━━━━━━━
▶ 15. CLEAN-CORE CHECK

Before selecting from an SAP standard table, ask:

1. Is there a released CDS entity?
2. Is there a released API?
3. Is the object released for the ABAP language version you are using?
4. Can ATC verify the dependency?

Direct table access may technically work in classic ABAP but still be a poor clean-core design.

━━━━━━━━━━━━━━━━━━━━
▶ 16. TROUBLESHOOTING CHECKLIST

If your CDS result looks wrong:

1. Check the source data.
2. Check the logical key.
3. Check join/association cardinality.
4. Check filter conditions.
5. Check calculated expressions.
6. Check unit/currency semantics.
7. Compare expected versus actual row count.
8. Use SQL trace only after the model itself is understood.

━━━━━━━━━━━━━━━━━━━━
▶ CHECKPOINT

You are ready for the next part when you can create a CDS view entity that:

• activates successfully;
• has the right logical key;
• uses readable aliases;
• models amount/currency and quantity/unit semantics;
• exposes a valid association;
• returns the expected rows in preview.

━━━━━━━━━━━━━━━━━━━━
▶ COMMON MISTAKES

• Copying database keys without checking business uniqueness.
• Using direct SAP tables when a released CDS entity exists.
• Declaring the wrong association cardinality.
• Mixing all UI annotations into the reusable interface layer.
• Forgetting currency/unit semantics.
• Treating activation success as proof that the business result is correct.

━━━━━━━━━━━━━━━━━━━━
▶ TRY IT YOURSELF

Create a ZI_PurchaseOrderItem or ZI_MaterialStock view entity.

Include:

• at least two key fields;
• one amount/currency pair;
• one quantity/unit pair;
• one association;
• one timestamp field.

Then preview the data and explain why each key and annotation exists.

━━━━━━━━━━━━━━━━━━━━
▶ INTERVIEW TAKEAWAY

A strong answer is:

“CDS view entities are reusable semantic models, not just SQL wrappers. I start from the business dataset, define the logical key, expose business-friendly aliases, model amount/currency and quantity/unit semantics, and use associations for reusable relationships. For clean core, I prefer released SAP CDS entities or APIs instead of direct access to internal persistence. After activation, I always validate the result set and cardinality in data preview.”

━━━━━━━━━━━━━━━━━━━━
▶ RELATED DEEP DIVES

For more detail, continue with:

• [CDS Associations: Fundamentals, ON Conditions and Cardinality](/lessons/rap-cds-associations-fundamentals-cardinality-on-condition)
• [CDS Annotation Architecture: Categories, Layers and Propagation](/lessons/rap-cds-annotations-layering-categories-propagation)

These are separate focused series so this core CDS tutorial stays easy to follow.

Model a purchase requisition summary entity exposing requisition number, item, material, plant, quantity and unit from a supported source, then consume it in a higher projection.

• Wrong logical key.
• Incorrect association cardinality.
• Direct access to unreleased SAP persistence in clean-core development.
• Missing amount/currency or quantity/unit semantics.
• Mixing reusable data modeling and consumer-specific UI design in one layer.
• Assuming activation proves correctness.

• Start with the business dataset, not the syntax.
• Prefer released SAP CDS entities and APIs.
• Keep interface entities stable and reusable.
• Use aliases that describe business meaning.
• Validate key uniqueness and row counts.
• Add only meaningful semantic annotations.
• Keep specialized associations and annotation deep dives in their dedicated series.

Explain CDS as a reusable semantic model, not merely a database view. Mention keys, semantics, associations and layering.