Root Entity, Child Entity and Composition

Explanation

RAP models transactional business objects using root entities and child entities. The root entity represents the main object, such as Travel, Sales Order, Purchase Request or Claim. Child entities represent dependent data such as items, texts, notes or attachments. Composition means the child lifecycle belongs to the root. If the root is deleted, child records usually follow the root lifecycle. This modeling is important for Fiori object pages, deep create, draft handling and transactional consistency.

Code example

@EndUserText.label: 'Claim Root'define root view entity ZI_Claim as select from zclaim composition [0..*] of ZI_ClaimItem as _Item{ key claim_id as ClaimId, customer as Customer, status as Status, _Item} @EndUserText.label: 'Claim Item'define view entity ZI_ClaimItem as select from zclaim_item association to parent ZI_Claim as _Claim on _Claim.ClaimId = zclaim_item.claim_id{ key claim_id as ClaimId, key item_no as ItemNo, material as Material, quantity as Quantity, _Claim} * Root entity owns the business object.* Child entity belongs to root through composition.* This enables deep object modeling in RAP.

Real project scenario

A claim management app used Claim as root entity and ClaimItem as child composition. Users could create a claim and add multiple claim items in one Fiori object page.

Common mistakes

- Using normal association where composition is required. - Modeling child entity without parent relationship. - Using wrong keys for root and child. - Not understanding lifecycle dependency.

Best practices

- Use composition for dependent child entities. - Define stable keys. - Keep child lifecycle aligned with root. - Test deep create and delete behavior.

Interview angle

A strong RAP answer should explain root, child, composition and parent association.