Lesson 18 — RAP Compositions: Parent/Child Business Objects

Until now, the Reservation Business Object has had one node:

Reservation

Today it becomes a composite Business Object:

Reservation
└── Participants

A Participant belongs to exactly one Reservation and cannot exist independently of it.

The architecture becomes:

ZR_RESERVATION_###
        │
        │ composition [0..*]
        ↓
ZR_RESERVATION_PART_###
        │
        └── association to parent

At runtime:

Reservation
├─ root behavior
├─ authorization master
├─ lock master
├─ total ETag
├─ draft table
└─ Participants
   ├─ child behavior
   ├─ authorization dependent
   ├─ lock dependent
   ├─ own ETag
   └─ own draft table

---

Lesson information

Teacher-led time	About 3 hours
Self-practice time	About 3 hours
Environment	SAP BTP ABAP Trial
Prerequisite	Lesson 17
Root entity	ZR_RESERVATION_###
Child entity	ZR_RESERVATION_PART_###
Child active table	ZRESPART_###
Child draft table	ZDRESPART_###
Child projection	ZC_RESERVATION_PART_###
EML test class	ZCL_RESV_COMP_###
Main outcome	Build and expose a draft-enabled two-node RAP BO

Replace:

###

with your own student/group suffix.

---

Learning objectives

After this lesson, you should be able to:

• explain a composite RAP BO;
• distinguish composition from a normal association;
• use composition [0..*] of;
• use association to parent;
• model child persistence;
• add a second entity to one BDEF;
• create child instances through a parent association;
• explain why managed children do not use normal root-style create;;
• use lock dependent by;
• use authorization dependent by;
• give the child its own ETag;
• generate child draft persistence;
• use with draft on BO-internal composition associations;
• create children with EML CREATE BY;
• read children with EML read-by-association;
• explain %target, %cid, %cid_ref, and LINK;
• perform a deep create;
• redirect composition associations in projection views;
• expose child behavior in the projection BDEF;
• expose the child projection in the Service Definition;
• display child data in a Fiori Elements facet;
• explain how root total ETag covers the complete composition tree.

---

1. Composite BO Structure

A RAP BO may contain:

one root
+
one or more child entities

Example:

Sales Order
└── Items

Our BO becomes:

Reservation
└── Participants

One BO instance contains:

exactly one Reservation
zero or more Participants

---

2. Composition vs Normal Association

A normal association connects entities.

A composition expresses:

whole
+
dependent part

For this lesson:

Reservation = whole
Participant = part

The Participant belongs to the Reservation lifecycle.

---

3. Parent and Child Relationship

The parent defines:

composition to child

The child defines:

association to parent

Together:

Reservation
    │
    │ _Participants
    ↓
Participant
    │
    └── _Reservation ──→ Reservation

---

4. Cardinality

A Reservation may contain:

0..*

Participants.

Therefore:

composition [0..*]

The child belongs to exactly one parent.

---

5. Objects Added Today

Create:

ZRESPART_###
ZR_RESERVATION_PART_###
ZDRESPART_###
ZC_RESERVATION_PART_###
Access Control for ZR_RESERVATION_PART_###
Access Control for ZC_RESERVATION_PART_###
Metadata Extension for ZC_RESERVATION_PART_###
ZCL_RESV_COMP_###

Modify:

ZR_RESERVATION_###
base BDEF
ZC_RESERVATION_###
projection BDEF
root Metadata Extension
ZUI_RESERVATION_###

Reuse:

ZUI_RESV_###_O4

---

6. Create Participant Persistence

Create:

ZRESPART_###

Use the same application-table conventions as the existing Reservation table.

Required fields:

client
participant_uuid
reservation_uuid
participant_no
participant_name
participant_email
participant_role
local_last_changed_at

Recommended types:

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

reservation_uuid          : sysuuid_x16 not null;
participant_no            : abap.numc(4);
participant_name          : abap.char(60);
participant_email         : abap.char(100);
participant_role          : abap.char(40);

local_last_changed_at     : abp_locinst_lastchange_tstmpl;

---

7. Child Identity

Use:

ParticipantUuid

as the child technical key.

Use:

ReservationUuid

as the parent reference.

Do not use the parent UUID as the child key because one Reservation can have many Participants.

---

8. Create the Child CDS Entity

Create:

ZR_RESERVATION_PART_###

Use:

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Reservation Participant'

define view entity ZR_Reservation_Part_###
  as select from zrespart_### as Participant

  association to parent ZR_Reservation_### as _Reservation
    on $projection.ReservationUuid = _Reservation.Uuid

{
      _Reservation,

  key Participant.participant_uuid      as ParticipantUuid,
      Participant.reservation_uuid      as ReservationUuid,
      Participant.participant_no        as ParticipantNo,
      Participant.participant_name      as ParticipantName,
      Participant.participant_email     as ParticipantEmail,
      Participant.participant_role      as ParticipantRole,

      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      Participant.local_last_changed_at as LocalLastChangedAt
}

---

9. association to parent

Use:

association to parent

for the child's direct parent relationship.

The ON condition must identify the parent through its complete key.

Our root key is:

Uuid

so:

$projection.ReservationUuid = _Reservation.Uuid

is sufficient.

Expose:

_Reservation

exactly once in the child select list.

---

10. Add the Root Composition

Open:

ZR_RESERVATION_###

Add before the select list:

composition [0..*] of ZR_Reservation_Part_### as _Participants

Expose:

_Participants

inside the root select list.

Conceptually:

define root view entity ZR_Reservation_###
  as select from zresv_### as Reservation

  composition [0..*] of ZR_Reservation_Part_### as _Participants

{
  key Reservation.uuid as Uuid,
      ...
      _Participants
}

The root remains:

ZR_RESERVATION_###

The child is not declared with root.

---

11. Protect Child Reads

The child will later be exposed as its own OData entity set.

Create Access Control for:

ZR_RESERVATION_PART_###

Use the parent ownership rule:

@EndUserText.label: 'Reservation Participant Access'
@MappingRole: true

define role ZR_Reservation_Part_###
{
  grant select on ZR_Reservation_Part_###
    where ( _Reservation.ResponsibleUser ) = aspect user;
}

This keeps:

Participant read access

aligned with:

Reservation ownership

---

12. Add Composition Behavior to the Root

Open the existing base BDEF.

Inside the Reservation root behavior add:

association _Participants { create; with draft; }

This means:

read related Participants
create Participants through Reservation
keep active/draft state consistent

---

13. Why the Child Has No Standard create;

In managed RAP:

root
→ standard create

child
→ create by association

Therefore the child behavior declares:

update;
delete;

but not normal:

create;

Child creation is enabled by:

association _Participants { create; with draft; }

on the parent.

---

14. Add Child Behavior

After the root behavior block, add:

define behavior for ZR_Reservation_Part_### alias Participant
persistent table zrespart_###
draft table zdrespart_###
authorization dependent by _Reservation
lock dependent by _Reservation
etag master LocalLastChangedAt
{
  update;
  delete;

  field ( numbering : managed, readonly )
    ParticipantUuid;

  field ( readonly )
    ReservationUuid,
    LocalLastChangedAt;

  field ( mandatory:create, readonly:update )
    ParticipantNo;

  association _Reservation { with draft; }

  mapping for zrespart_###
  {
    ParticipantUuid    = participant_uuid;
    ReservationUuid    = reservation_uuid;
    ParticipantNo      = participant_no;
    ParticipantName    = participant_name;
    ParticipantEmail   = participant_email;
    ParticipantRole    = participant_role;
    LocalLastChangedAt = local_last_changed_at;
  }
}

---

15. Lock Dependency

Use:

lock dependent by _Reservation

Only the root is the lock master.

A modification to Participant delegates locking to:

its Reservation

This keeps one composition tree inside one lock scope.

---

16. Authorization Dependency

Use:

authorization dependent by _Reservation

Only the root is the authorization master.

For standard child:

create by association
update
delete

authorization is evaluated through the parent Reservation.

The owner policy remains:

ResponsibleUser = current user

---

17. Child ETag

Use:

etag master LocalLastChangedAt

for Participant.

The child can have its own optimistic-concurrency token while still being lock- and authorization-dependent on the root.

---

18. Root Total ETag and the Composition Tree

The root already uses:

LastChangedAt

as:

total ETag

The total ETag represents the complete draft BO.

When active data in any BO node changes:

Reservation change
or
Participant change

the managed runtime updates the root total ETag when the field is correctly annotated and mapped.

---

19. Generate Child Draft Persistence

The child BDEF declares:

draft table zdrespart_###

Place the cursor on the table name.

Use:

Ctrl+1

Generate the draft table.

Activate:

ZDRESPART_###

Do not manually edit its technical draft administration fields.

---

20. Draft-Enabled BO Associations

Use:

association _Participants { create; with draft; }

on the root.

Use:

association _Reservation { with draft; }

on the child.

The intended navigation is:

active parent → active child
draft parent  → draft child

---

21. Activate the Base BO

A safe sequence:

ZRESPART_###
ZR_RESERVATION_PART_###
child Access Control
modified ZR_RESERVATION_###
ZDRESPART_###
modified base BDEF
related behavior artifacts

Use:

Ctrl+F2
Ctrl+F3
Ctrl+Shift+F3

as needed.

---

EML: Create by Association

22. Create the Test Consumer

Create:

ZCL_RESV_COMP_###

Implement:

IF_OO_ADT_CLASSRUN

This is an external consumer.

Do not use:

IN LOCAL MODE

---

23. Find an Owned Reservation

Use a protected read against:

ZR_RESERVATION_###

Find an owned Reservation.

Prefer:

ReservationNo = 99100001

if it still exists from the draft exercise.

Retrieve its:

Uuid

---

24. Create a Participant by Association

Use:

MODIFY ENTITIES OF ZR_Reservation_###
  ENTITY Reservation
    CREATE BY \_Participants
      FIELDS (
        ParticipantNo
        ParticipantName
        ParticipantEmail
        ParticipantRole
      )
      WITH VALUE #(
        (
          Uuid = reservation_uuid
          %target = VALUE #(
            (
              %cid             = 'PART-001'
              ParticipantNo    = '0001'
              ParticipantName  = 'Taylor Reed'
              ParticipantEmail = 'taylor@example.com'
              ParticipantRole  = 'Attendee'
            )
          )
        )
      )
  MAPPED DATA(mapped)
  FAILED DATA(failed)
  REPORTED DATA(reported).

---

25. %target

The outer row identifies:

the parent

%target contains:

the children to create for that parent

Example:

Reservation A
└── %target
    ├── Participant 1
    └── Participant 2

---

26. Child %cid

ParticipantUuid uses managed numbering.

The consumer therefore supplies:

%cid

not the final UUID.

Inspect:

MAPPED-Participant

to retrieve the generated child key.

---

27. Commit the Child

After checking interaction responses:

COMMIT ENTITIES
  RESPONSE OF ZR_Reservation_###
    FAILED DATA(failed_commit)
    REPORTED DATA(reported_commit).

Verify the child exists in:

ZRESPART_###

---

EML: Read by Association

28. Read the Children

Use:

READ ENTITIES OF ZR_Reservation_###
  ENTITY Reservation
    BY \_Participants
      ALL FIELDS
      WITH VALUE #(
        ( Uuid = reservation_uuid )
      )
    RESULT DATA(participants)
    LINK DATA(participant_links)
    FAILED DATA(failed_read).

---

29. RESULT and LINK

RESULT contains:

Participant data

LINK contains:

source parent key
→
target child key

LINK becomes useful when one request reads children for several parents.

---

EML: Deep Create

30. Parent and Children in One Request

A composition supports a deep create.

Create:

one new Reservation
+
two Participants

inside one:

MODIFY ENTITIES

The parent UUID is not yet known.

Use:

parent %cid
child %cid_ref

---

31. Deep Create Pattern

Use a pattern equivalent to:

MODIFY ENTITIES OF ZR_Reservation_###
  ENTITY Reservation
    CREATE FIELDS (
      ReservationNo
      CustomerName
      CustomerEmail
      WorkshopCode
      ReservationDate
      Fee
      CurrencyCode
      Notes
    )
    WITH VALUE #(
      (
        %cid            = 'ROOT-001'
        ReservationNo   = '99180001'
        CustomerName    = 'Composition Student'
        CustomerEmail   = 'composition@example.com'
        WorkshopCode    = 'RAP501'
        ReservationDate = cl_abap_context_info=>get_system_date( )
        Fee              = '450.00'
        CurrencyCode     = 'EUR'
        Notes            = 'Deep create'
      )
    )

    CREATE BY \_Participants
      FIELDS (
        ParticipantNo
        ParticipantName
        ParticipantEmail
        ParticipantRole
      )
      WITH VALUE #(
        (
          %cid_ref = 'ROOT-001'
          %target = VALUE #(
            (
              %cid             = 'CHILD-001'
              ParticipantNo    = '0001'
              ParticipantName  = 'Morgan Lee'
              ParticipantEmail = 'morgan@example.com'
              ParticipantRole  = 'Lead'
            )
            (
              %cid             = 'CHILD-002'
              ParticipantNo    = '0002'
              ParticipantName  = 'Sam Rivera'
              ParticipantEmail = 'sam@example.com'
              ParticipantRole  = 'Attendee'
            )
          )
        )
      )

  MAPPED DATA(mapped_deep)
  FAILED DATA(failed_deep)
  REPORTED DATA(reported_deep).

---

32. %cid_ref

This:

%cid_ref = ROOT-001

connects the child create request to the parent create row whose:

%cid = ROOT-001

RAP resolves the final managed parent UUID.

---

33. Deep Create Proof

Inspect:

mapped_deep-Reservation
mapped_deep-Participant

Then commit.

Verify:

one Reservation
two Participants

with the correct parent relationship.

---

Projection Layer

34. Create Child Projection

Create:

ZC_RESERVATION_PART_###

Use:

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Reservation Participant Projection'
@Metadata.allowExtensions: true

define view entity ZC_Reservation_Part_###
  as projection on ZR_Reservation_Part_###
{
  key ParticipantUuid,
      ReservationUuid,
      ParticipantNo,
      ParticipantName,
      ParticipantEmail,
      ParticipantRole,
      LocalLastChangedAt,

      _Reservation : redirected to parent ZC_Reservation_###
}

---

35. Redirect to Projected Parent

The base child points to:

ZR_RESERVATION_###

The service projection must point to:

ZC_RESERVATION_###

Use:

redirected to parent

---

36. Redirect the Root Composition

Open:

ZC_RESERVATION_###

Expose:

_Participants
  : redirected to composition child ZC_Reservation_Part_###

Now the service-specific hierarchy is:

ZC_RESERVATION_###
└── ZC_RESERVATION_PART_###

---

37. Protect Child Projection Reads

Create Access Control for:

ZC_RESERVATION_PART_###

Use:

@EndUserText.label: 'Reservation Participant Projection Access'
@MappingRole: true

define role ZC_Reservation_Part_###
{
  grant select on ZC_Reservation_Part_###
    where inheriting conditions from entity ZR_Reservation_Part_###;
}

---

Projection Behavior

38. Extend Root Projection Behavior

Inside the root projection behavior add:

use association _Participants { create; with draft; }

---

39. Add Child Projection Behavior

In the same projection BDEF add:

define behavior for ZC_Reservation_Part_### alias Participant
use etag
{
  use update;
  use delete;

  use association _Reservation { with draft; }
}

There is no child:

use create;

Creation is through the root composition.

---

Service Exposure

40. Add the Child to the Service Definition

Open:

ZUI_RESERVATION_###

Use a structure equivalent to:

@ObjectModel.leadingEntity.name: 'ZC_RESERVATION_###'
define service ZUI_RESERVATION_###
{
  expose ZC_Reservation_###      as Reservations;
  expose ZC_Reservation_Part_### as Participants;
  expose I_CurrencyStdVH         as Currencies;
}

For a multi-entity BO projection, expose the child explicitly.

---

41. Reuse the Existing Binding

Keep:

ZUI_RESV_###_O4

Activate the modified Service Definition.

Reload the existing binding:

F5

if necessary.

Do not create a second service binding.

---

Fiori Elements Metadata

42. Add a Child Facet to the Root

Open the metadata extension for:

ZC_RESERVATION_###

Add or extend:

@UI.facet: [
  {
    id: 'Reservation',
    purpose: #STANDARD,
    type: #IDENTIFICATION_REFERENCE,
    label: 'Reservation',
    position: 10
  },
  {
    id: 'Participants',
    purpose: #STANDARD,
    type: #LINEITEM_REFERENCE,
    label: 'Participants',
    position: 20,
    targetElement: '_Participants'
  }
]

---

43. Create Child Metadata

Create a Metadata Extension for:

ZC_RESERVATION_PART_###

Use:

@Metadata.layer: #CORE

annotate entity ZC_Reservation_Part_### with
{
  @UI.lineItem: [ { position: 10, label: 'Participant No.' } ]
  ParticipantNo;

  @UI.lineItem: [ { position: 20, label: 'Name' } ]
  ParticipantName;

  @UI.lineItem: [ { position: 30, label: 'Email' } ]
  ParticipantEmail;

  @UI.lineItem: [ { position: 40, label: 'Role' } ]
  ParticipantRole;
}

---

Draft UI Test

44. Open an Owned Reservation

Launch:

ZUI_RESV_###_O4

Preview:

Reservations

Open a Reservation owned by the current user.

The object page should now contain:

Reservation
Participants

facets.

---

45. Create a Participant in Draft

Choose:

Edit

In the Participants facet, create:

ParticipantNo    = 0001
ParticipantName  = Jordan Kim
ParticipantEmail = jordan@example.com
ParticipantRole  = Attendee

Do not enter:

ParticipantUuid
ReservationUuid

---

46. Inspect Child Draft Persistence

Before Save:

ZRESPART_###
→ no new active Participant

ZDRESPART_###
→ new Participant draft

The child participates in the same draft lifecycle as the parent.

---

47. Save the Composition

Choose:

Save

Expected:

root draft activates
child draft activates
active Participant row appears
child draft row disappears

One Save activates the complete draft BO.

---

48. Discard a Child Change

Edit the Reservation again.

Change or delete a Participant.

Before Save, inspect active/draft persistence.

Choose:

Cancel / Discard

Expected:

active Participant unchanged
pending child draft change removed

---

49. Verify Root Total ETag

Capture root:

LastChangedAt

Change and save only Participant data.

Read the root timestamp again.

Expected:

LastChangedAt changed

The total ETag covers the complete BO composition tree.

---

Common Mistakes

50. Normal Association Instead of Composition

Wrong:

ordinary association from root to child

Correct:

composition [0..*] of ...

Composition models lifecycle dependency.

---

51. Missing To-Parent Association

The composition requires the reverse child relation.

Use:

association to parent

---

52. Child Declared as Root

A BO has one root.

Child:

define view entity

not:

define root view entity

---

53. Standard Child create;

Managed child create is performed through:

CREATE BY association

Do not model the child as independently createable.

---

54. Missing with draft

The BO is draft-enabled.

Use:

with draft

on both BO-internal association behaviors.

---

55. Child as Lock Master

Only the root is lock master.

Use:

lock dependent by _Reservation

---

56. Duplicated Child Authorization

Do not reimplement the same owner check for the child.

Use:

authorization dependent by _Reservation

---

57. Projection Associations Not Redirected

Projection targets must be projection entities.

Use:

redirected to composition child
redirected to parent

---

58. Child Missing from Service Definition

Expose:

Participants

explicitly.

Otherwise the composition hierarchy is incomplete in the OData service.

---

59. Child Missing Read Protection

Protect:

base child CDS
projection child CDS

because the child can be read through its own service entity set.

---

Certification Alignment

60. Practical Composition Skills

A practical RAP task can require you to create or repair:

composition
to-parent association
child persistence
child behavior
create-by-association
lock dependency
authorization dependency
child ETag
draft table
projection redirection
service exposure
Fiori child facet
EML deep create

The main skill is tracing the complete parent/child contract through every RAP layer.

---

Knowledge Check

61. Questions

1. What makes a composition different from a normal association?

2. Why must a child define an association to parent?

3. Why is child create exposed through the parent association?

4. What does lock dependent by mean?

5. What does authorization dependent by mean?

6. Why can the child still be an ETag master?

7. What does the root total ETag cover?

8. What is %target?

9. What problem does %cid_ref solve?

10. What information does LINK return?

11. Why do projection associations need redirection?

12. Why must the child projection be exposed explicitly in the Service Definition?

13. Why does the child need DCL even though the parent has DCL?

14. Why is a line-item facet appropriate for [0..*] Participants?

---

Teacher-Led Completion Checklist

62. Checklist

• ZRESPART_### created.
• Participant UUID is technical key.
• Reservation UUID stored as parent reference.
• ZR_RESERVATION_PART_### created.
• Child is not root.
• Child has association to parent.
• Root has [0..*] composition.
• Base child DCL protects reads.
• Root BDEF create-enables Participants.
• Root composition behavior uses with draft.
• Child behavior added to same BDEF.
• Child uses lock dependency.
• Child uses authorization dependency.
• Child has own ETag master.
• Child UUID numbering is managed.
• Child draft table generated.
• To-parent behavior uses with draft.
• CREATE BY \_Participants works.
• Child UUID appears in MAPPED.
• Read-by-association works.
• LINK works.
• Deep create uses %cid_ref.
• Child projection created.
• Root projection redirects child composition.
• Child projection redirects parent.
• Child projection DCL created.
• Root projection BDEF exposes child create.
• Child projection BDEF exposes update/delete.
• Child added to Service Definition.
• Existing OData V4 binding reused.
• Participants facet appears.
• Child line-item metadata appears.
• New child is draft-only before Save.
• Save activates parent/child draft state.
• Discard leaves active child unchanged.
• Root total ETag changes after active child modification.

---

End-of-Day Mental Model

63. Final Model

                  Reservation BO
                        │
             ┌──────────┴──────────┐
             │                     │
          ROOT                   CHILD
     Reservation              Participant
             │                     │
      lock master           lock dependent
 authorization master   authorization dependent
      total ETag             own ETag
             │                     │
             └──── composition ────┘

Data model:

ZR_RESERVATION_###
        │
        ↓ composition
ZR_RESERVATION_PART_###
        │
        └── association to parent

EML:

Reservation
    ↓
CREATE BY _Participants
    ↓
Participant

Projection:

ZC_RESERVATION_###
        │ redirected to composition child
        ↓
ZC_RESERVATION_PART_###
        │ redirected to parent
        └────────────────────────→ root projection

You now have a:

managed
authorized
draft-enabled
service-ready
multi-node RAP Business Object

The next checkpoint will ask students to prove that architecture with much less guidance.