Lesson 8 — Custom Persistence Modeling

Until now, you have worked mainly with SAP-owned demo data:

/DMO/CARRIER
/DMO/AIRPORT
/DMO/CONNECTION
/DMO/FLIGHT
/DMO/BOOKING

You could:

read it
filter it
join it
associate it
annotate it
aggregate it

But you did not own the persistence.

Today that changes.

You will design and create your first application database table.

The goal for today is deliberately narrow:

Build persistence that is ready to become a RAP business object later.

You will not write INSERT, UPDATE, or DELETE yet.

Those operations belong to Lesson 9.

---

Lesson information

Teacher-led time	About 3 hours
Self-practice time	About 3 hours
Environment	SAP BTP ABAP Trial
Development tool	Eclipse with ABAP Development Tools (ADT)
Prerequisites	Lessons 1–7
Domain	ZDM_RSTAT_###
Data Element	ZDE_RSTAT_###
Database Table	ZRESV_###
Main outcome	Activated RAP-ready persistence

Replace:

###

with your student/group suffix.

---

Learning objectives

After the teacher-led part, you should be able to:

• explain the difference between persistence and a CDS query model;
• define the grain of an application table;
• distinguish a technical key from a business-facing identifier;
• explain why a UUID is useful as a technical key;
• explain the roles of Domains and Data Elements;
• create and activate a Domain in ADT;
• define fixed values for a Domain;
• create a Data Element based on a Domain;
• create a source-based ABAP Dictionary database table;
• explain the main table annotations used in this course;
• define a client-dependent primary key;
• explain implicit client handling;
• distinguish SQL NULL from an ABAP initial value;
• add amount/currency semantics to a table field;
• recognize the standard RAP administrative field types;
• explain why LocalLastChangedAt and LastChangedAt are both kept;
• activate the table and inspect it with Data Preview;
• explain how today's persistence prepares for RAP.

---

Certification alignment

This lesson deliberately covers data-modeling skills from SAP's current ABAP Cloud learning path:

ABAP Dictionary
database tables
Domains
Data Elements
field labels
primary keys
client handling
application-table annotations
amount/currency semantics
UUID technical keys
RAP administrative fields

SAP's current data-modeling learning content still teaches source-based tables with:

define table

and recommends Data Elements for business fields because they combine technical typing with reusable semantic information.

Modern ABAP Cloud also supports:

define table entity

That newer persistence model is discussed in the Companion, but today we use the source-based Dictionary table model because it remains important certification knowledge and fits the RAP sequence we are building.

---

1. Where Lesson 8 fits

The course has now reached a major transition.

Lessons 1–7:

SAP-owned persistence
        ↓
ABAP SQL / CDS
        ↓
read-oriented applications

Lesson 8:

Your design
   ↓
Your Domain / Data Element
   ↓
Your database table

Later:

Your database table
        ↓
RAP business object
        ↓
EML / business service

Today is about the bottom layer:

Persistence

---

2. Persistence vs CDS

A database table stores state.

Database Table
=
stored application rows

A CDS View Entity describes a queryable model over data.

CDS View Entity
=
modeled/queryable result

For example:

define view entity ...
  as select from ...

does not itself mean:

create a new physical application table.

In this lesson, you create actual persistence.

---

3. Start with the row grain

Before choosing field names, answer:

What does one row represent?

For today's model:

One row = one workshop reservation

That decision is the table's grain.

Every field should describe that one reservation.

Examples:

reservation number
customer name
workshop code
reservation date
status
fee
currency

This design habit connects directly to the output-grain reasoning from Lesson 7.

---

4. The Reservation scenario

We will create:

ZRESV_###

A reservation contains:

UUID
Reservation Number
Customer Name
Customer Email
Workshop Code
Reservation Date
Status
Fee
Currency
Notes
RAP administrative fields

The table will eventually sit underneath a RAP business object.

---

5. Technical key vs business identifier

The table contains two identifiers:

UUID
Reservation Number

They serve different purposes.

UUID

technical identity
stable key
not intended for humans

Reservation Number

business-facing identifier
human-readable
may follow future business numbering rules

The technical primary key will use the UUID.

The Reservation Number remains a normal business field.

---

6. Why use a UUID key?

The UUID field uses:

SYSUUID_X16

This is a reusable SAP Data Element representing a 16-byte UUID.

A UUID works well for RAP because later the managed RAP provider can generate a suitable UUID key automatically during create processing.

That gives us a clean separation:

Uuid
=
technical identity

ReservationNo
=
business identity

---

7. Why is the table name short?

ABAP Dictionary database-table names have stricter length limits than many modern ABAP repository objects.

Use:

ZRESV_###

Example:

ZRESV_017

Do not design a long table name first and discover the repository limit later.

Practical certification work often rewards simple, safe naming.

---

8. Reusable business types

The Reservation Status has business meaning.

Possible values:

N = New
C = Confirmed
X = Cancelled

Instead of typing the field only as:

CHAR(1)

we will model it using:

Domain
   ↓
Data Element
   ↓
Table Field

Objects:

ZDM_RSTAT_###
ZDE_RSTAT_###

---

9. Domain responsibility

A Domain primarily defines technical characteristics and a value range.

For this lesson:

Domain: ZDM_RSTAT_###
Type:   CHAR
Length: 1

Fixed values:

Value	Meaning
N	New
C	Confirmed
X	Cancelled

Think:

Domain
=
technical type + allowed-value metadata

---

10. Fixed values are not your whole business logic

The Domain advertises the expected value range.

That can support:

metadata
input assistance
framework checks
developer understanding

But do not think:

Domain fixed values automatically implement every future reservation-state rule.

Later RAP validation can express rules such as:

A cancelled reservation cannot be confirmed again.

That is behavior, not just type metadata.

---

11. Data Element responsibility

A Data Element adds reusable semantic meaning to a technical type.

Our Data Element:

ZDE_RSTAT_###

will use:

ZDM_RSTAT_###

and carry labels such as:

Short:   Status
Medium:  Reservation Status
Long:    Reservation Status
Heading: Status

Think:

Domain
=
technical foundation

Data Element
=
reusable field meaning + labels

---

12. SAP's Data Element recommendation

For business fields, SAP recommends Data Elements because they preserve semantic information and reusable field labels.

In a production model, many fields could therefore use dedicated or released reusable Data Elements.

To keep this first persistence lesson focused, the course uses:

custom Data Element for Status
SAP reusable Data Elements for UUID/admin fields
predefined ABAP types for several simple local fields

The simplification is intentional.

Do not interpret it as:

predefined types are always preferable for business fields.

---

13. Create the Status Domain

In Project Explorer, right-click your package.

Choose:

New
  → Other ABAP Repository Object
  → Dictionary
  → Domain

Use:

Name:        ZDM_RSTAT_###
Description: Reservation Status

Choose your transport if required.

Finish the wizard.

---

14. Configure the Domain

Set:

Data Type: CHAR
Length:    1

Then add fixed values:

Value	Description
N	New
C	Confirmed
X	Cancelled

Activate:

Ctrl + F3

---

15. Create the Data Element

Right-click the package:

New
  → Other ABAP Repository Object
  → Dictionary
  → Data Element

Use:

Name:        ZDE_RSTAT_###
Description: Reservation Status

Configure it as Domain-based.

Domain:

ZDM_RSTAT_###

Maintain useful labels.

Activate it.

---

16. Why not use the Domain directly?

A Domain is the foundation for a Data Element.

The normal semantic chain is:

Domain
   ↓
Data Element
   ↓
Table field

So the table field will use:

ZDE_RSTAT_###

not:

ZDM_RSTAT_###

---

17. Create the database table

Create:

ZRESV_###

Right-click your package:

New
  → Other ABAP Repository Object
  → Dictionary
  → Database Table

Use:

Name:        ZRESV_###
Description: Workshop Reservations

Finish the wizard.

ADT opens the source-based Dictionary editor.

---

18. Source-based table syntax

A source-based table has the shape:

@Annotations...
define table ztable {
  ...
}

This is ABAP Dictionary DDL.

Do not confuse it with:

define view entity

which creates a CDS query entity.

---

19. Table annotations used today

Use:

@EndUserText.label : 'Workshop Reservations'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED

The important ideas are:

transparent application table
application data
restricted generic maintenance
not designed for extension in this exercise

You do not need to memorize every possible annotation value today.

---

20. Full Reservation table

Use:

@EndUserText.label : 'Workshop Reservations'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zresv_### {

  key client                : abap.clnt not null;
  key uuid                  : sysuuid_x16 not null;

  reservation_no            : abap.numc(8) not null;
  customer_name             : abap.char(60) not null;
  customer_email            : abap.char(100);
  workshop_code             : abap.char(10) not null;
  reservation_date          : abap.dats not null;
  status                    : zde_rstat_### not null;

  @Semantics.amount.currencyCode : 'zresv_###.currency_code'
  fee                       : abap.curr(10,2);

  currency_code             : abap.cuky;
  notes                     : abap.char(255);

  local_created_by          : abp_creation_user;
  local_created_at          : abp_creation_tstmpl;
  local_last_changed_by     : abp_locinst_lastchange_user;
  local_last_changed_at     : abp_locinst_lastchange_tstmpl;
  last_changed_at           : abp_lastchange_tstmpl;

}

Replace every ###.

---

21. Read the table as a design

Do not treat the previous source as something to copy blindly.

Read it in groups:

technical key
business data
semantic amount/currency pair
RAP administrative fields

That grouping is useful when you later diagnose a table you did not create yourself.

---

22. Client-dependent persistence

The first field is:

key client : abap.clnt not null;

A key field of type:

CLNT

makes this normal application table client-dependent.

Normal ABAP SQL access then uses implicit client handling.

Conceptually:

one physical table
+
logical client separation

Client separation is not the same as user authorization.

---

23. Why client is the first key

The primary key is:

client + uuid

For this client-dependent table:

client

is the first key field.

Within the current client:

uuid

identifies the reservation.

---

24. Why ReservationNo is not the primary key

A business number can eventually depend on:

number ranges
business rules
regional rules
formatting
external integration

A technical UUID avoids coupling physical identity to those rules.

Later we can change how a Reservation Number is assigned without changing the technical key strategy.

---

25. NOT NULL does not mean "not initial"

SQL NULL and an ABAP initial value are different concepts.

Examples of ABAP initial values:

''   character
0    numeric
00000000 date-like storage

A field marked:

NOT NULL

cannot contain SQL NULL.

That does not automatically mean:

the business value can never be empty or zero.

Business mandatory-field rules are a separate concern.

---

26. Amount/currency semantics

The table stores:

fee
currency_code

The amount is annotated:

@Semantics.amount.currencyCode : 'zresv_###.currency_code'
fee : abap.curr(10,2);

This says:

interpret fee using the currency stored in this row's currency_code.

This connects directly to Lesson 6 semantics and Lesson 7's warning about aggregating amounts.

---

27. Why the currency reference is qualified

At table level, the semantic reference uses the table field reference:

zresv_###.currency_code

Example:

zresv_017.currency_code

Do not mechanically copy CDS View Entity annotation syntax into a Database Table definition.

The artifact type matters.

---

28. RAP administrative fields

The table already contains fields that future RAP behavior can manage.

local_created_by
local_created_at
local_last_changed_by
local_last_changed_at
last_changed_at

Types:

Field	Reuse Data Element
local_created_by	ABP_CREATION_USER
local_created_at	ABP_CREATION_TSTMPL
local_last_changed_by	ABP_LOCINST_LASTCHANGE_USER
local_last_changed_at	ABP_LOCINST_LASTCHANGE_TSTMPL
last_changed_at	ABP_LASTCHANGE_TSTMPL

---

29. Local last change vs total last change

Two timestamps can look redundant at first.

Local instance timestamp

local_last_changed_at

Later this is useful for:

local ETag / optimistic concurrency

Total last-change timestamp

last_changed_at

Later this becomes relevant for:

total ETag / draft scenarios

Keeping both now prevents redesigning the persistence later.

---

30. Administrative fields are intentionally early

You have not learned RAP behavior yet.

So why include RAP-ready fields now?

Because persistence design should anticipate how the table will be used.

The future sequence is:

Lesson 8
Design persistence
     ↓
Lesson 9
Manipulate persistence directly
     ↓
Lesson 10
Model RAP BO structure
     ↓
Lesson 11
Add managed RAP behavior

The table should not need to be redesigned every day.

---

31. Syntax check and activation

Run:

Ctrl + F2

Resolve every error.

Then activate:

Ctrl + F3

Activation creates/updates the corresponding database definition in your BTP ABAP Trial system.

---

32. Open Data Preview

With the database table open, use:

Alt + F8

or:

Open With
  → Data Preview

The result should contain:

0 rows

That is a successful result.

You created storage, but nothing has written application data yet.

---

33. Today's finish line

At the end of the teacher-led lesson you should have:

ZDM_RSTAT_###   active
        ↓
ZDE_RSTAT_###   active
        ↓
ZRESV_###       active
        ↓
Data Preview    empty

Stop here.

Do not add a SQL write class yet.

That is tomorrow's learning objective.

---

34. Current ABAP Cloud direction: CDS table entities

Modern ABAP Cloud also supports persistent CDS Table Entities:

define table entity ...

They are an important newer direction.

Today's hands-on exercise still uses:

define table

because it gives you direct experience with:

ABAP Dictionary
Domains
Data Elements
client fields
source-based tables
RAP reuse fields

These remain useful certification knowledge.

The Companion compares both persistence models at a high level.

---

35. Common mistakes

Mistake 1 — Using the Domain as the table field type

Wrong idea:

status : ZDM_RSTAT_###

Use the Data Element:

ZDE_RSTAT_###

---

Mistake 2 — Using reservation_no as the only technical key

That mixes business numbering with technical identity.

Use:

client + uuid

for this course design.

---

Mistake 3 — Forgetting the currency reference

An amount without its currency relationship loses important semantics.

---

Mistake 4 — Forgetting the client field

Then the table would not follow the client-dependent application-table model used in this course.

---

Mistake 5 — Treating Domain fixed values as complete business validation

Later behavior rules still belong in RAP.

---

Mistake 6 — Creating only one last-change timestamp

The course deliberately keeps both:

LocalLastChangedAt
LastChangedAt

for different later RAP scenarios.

---

Mistake 7 — Writing data today

Today's target is:

correct persistence design

not:

SQL DML

---

36. Knowledge check

1. What does one row in ZRESV_### represent?

Show answer

One workshop reservation.

2. What is the technical key?

Show answer

client + uuid.

3. Why is ReservationNo not the technical primary key?

Show answer

It is a business-facing identifier whose numbering rules may evolve independently of technical row identity.

4. What does a Domain primarily provide?

Show answer

Technical typing and value-range metadata.

5. What does a Data Element add?

Show answer

Reusable semantic meaning and labels on top of technical typing.

6. Does a Domain fixed-value list replace future RAP validations?

Show answer

No. Fixed values describe a value range; business-state rules still belong in behavior logic.

7. Why is fee linked to currency_code?

Show answer

An amount needs the currency that gives the numeric value business meaning.

8. Which field is planned for the local ETag later?

Show answer

local_last_changed_at.

9. Which field becomes important for a future total ETag/draft scenario?

Show answer

last_changed_at.

10. What should Data Preview show at the end of Lesson 8?

Show answer

An active table with zero rows.

---

37. Lesson summary

Today you moved from:

modeling SAP-owned data

to:

designing persistence you own

You created:

ZDM_RSTAT_###
      ↓
ZDE_RSTAT_###
      ↓
ZRESV_###

The table contains:

client-dependent key
technical UUID
business identifier
business fields
amount/currency semantics
RAP administrative fields

The central idea is:

Good RAP development starts with deliberate persistence design.

---

38. What comes next?

Lesson 9 asks:

How does ABAP code create, read, change, and delete rows in the persistence we just designed?

You will build:

ZCL_RESV_SQL_###

and use:

INSERT
SELECT
UPDATE
DELETE
sy-dbcnt

That will teach the mechanics that RAP later abstracts.