- 
                Notifications
    
You must be signed in to change notification settings  - Fork 1
 
Behavior Definitions
        Ankit Kumar Singh edited this page Sep 9, 2025 
        ·
        2 revisions
      
    Behavior Definitions in RAP specify the business object (BO) behavior: which operations are available (create, update, delete), how entities are composed, and which fields are system- or framework-controlled.
This project uses the Managed Scenario. RAP auto-generates standard persistence logic and lifecycle handling, so you focus on business logic and structureβnot on boilerplate CRUD code.
The root BO is defined on the interface view ZAKS_I_ROOT_VEHICLE, representing the Vehicle entity.
- 
Managed scenario (
managed;) β RAP handles all CRUD operations. - Root entity: Vehicle β can be created, updated, and deleted.
 - 
Compositions:
- 
Trips (
_Trip) - 
Maintenance (
_Maintenance) 
 - 
Trips (
 - 
Read-only and system fields:
- 
VehicleIdis read-only - 
VehicleUUIDis auto-numbered (managed UUID) 
 - 
 
managed; // implementation in class zbp_aks_i_root_vehicle unique;
define behavior for ZAKS_I_ROOT_VEHICLE
persistent table zaks_vehicle
lock master
{
  create;
  update;
  delete;
  field ( readonly ) VehicleId;
  field ( readonly, numbering : managed ) VehicleUUID;
  association _Maintenance { create; }
  association _Trip { create; }
  mapping for zaks_vehicle {
    VehicleUUID   = vehicle_uuid;
    VehicleId     = vehicle_id;
    RegdNo        = regd_no;
    VehicleType   = vehicle_type;
    Brand         = brand;
    Model         = model;
    FuelType      = fuel_type;
    CostPrice     = cost_price;
    Capacity      = capacity;
    CapacityUnit  = capacity_unit;
    Plant         = plant;
    PurchaseDate  = purchase_date;
    Status        = status;
    CreatedBy     = created_by;
    CreatedOn     = created_on;
    Currency      = currency;
  }
}- 
Dependent on Vehicle (
lock dependent by _Vehicle) - Created only via Vehicle composition
 - Key fields (
VehicleId,VehicleUUID,MaintId) are read-only 
define behavior for ZAKS_I_CDS_MAINTENANCE
persistent table zaks_maintenance
lock dependent by _Vehicle
{
  update;
  delete;
  field ( readonly ) VehicleId, VehicleUUID, MaintId;
  association _Vehicle;
  mapping for zaks_maintenance {
    MaintId          = maint_id;
    VehicleUUID      = vehicle_uuid;
    VehicleId        = vehicle_id;
    ServiceDate      = service_date;
    ServiceType      = service_type;
    WorkshopName     = workshop_name;
    ServiceCost      = service_cost;
    Currency         = currency;
    OdometerReading  = odometer_reading;
    PartsChanged     = parts_changed;
    WarrantyClaim    = warranty_claim;
    NextServiceDate  = next_service_date;
    MaterialNumber   = material_number;
    VendorNumber     = vendor_number;
    CreatedBy        = created_by;
    CreatedOn        = created_on;
  }
}- 
Dependent on Vehicle (
lock dependent by _Vehicle) - Created only via Vehicle composition
 - Key fields (
VehicleId,VehicleUUID,TripId) are read-only - Computed field 
total_trip_costis read-only 
define behavior for ZAKS_I_CDS_TRIP
persistent table ZAKS_TRIP
lock dependent by _Vehicle
{
  update;
  delete;
  field ( readonly ) VehicleId, VehicleUUID, TripId;
  association _Vehicle;
  mapping for ZAKS_TRIP {
    TripId       = trip_id;
    VehicleUUID  = vehicle_uuid;
    VehicleId    = vehicle_id;
    DriverId     = driver_id;
    Origin       = origin;
    Destination  = destination;
    StartDate    = start_date;
    EndDate      = end_date;
    DistanceKm   = distance_km;
    CargoType    = cargo_type;
    CreatedBy    = created_by;
    CreatedOn    = created_on;
  }
  field ( readonly ) total_trip_cost;
}Behavior Projections expose only the relevant subset of operations to consumers (via projection views).
- 
Root Projection (
ZAKS_P_ROOT_VEHICLE): allows create, update, delete, and composition creation for Trips & Maintenance - Trip & Maintenance Projections: allow update, delete
 
projection;
define behavior for ZAKS_P_ROOT_VEHICLE {
  use create;
  use update;
  use delete;
  use association _Maintenance { create; }
  use association _Trip { create; }
}
define behavior for ZAKS_P_CDS_MAINTENANCE {
  use update;
  use delete;
  use association _Vehicle;
}
define behavior for ZAKS_P_CDS_TRIP {
  use update;
  use delete;
  use association _Vehicle;
}- Managed Scenario: No manual CRUD codeβRAP auto-handles all persistence.
 - Vehicle is the root entity; Trips and Maintenance are strict compositions (cannot exist independently).
 - Child entities are dependent and can only be created via their parent Vehicle.
 - Read-only fields ensure integrity for technical keys and computed values.
 - Behavior Projections control what operations are externally available, keeping internal logic clean.
 
π Next: π Service Layer