Skip to content

Behavior Definitions

Ankit Kumar Singh edited this page Sep 9, 2025 · 2 revisions

⚙️ Behavior Definitions

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.


📂 Root Behavior Definition

The root BO is defined on the interface view ZAKS_I_ROOT_VEHICLE, representing the Vehicle entity.

🚩 Highlights

  • Managed scenario (managed;) — RAP handles all CRUD operations.
  • Root entity: Vehicle — can be created, updated, and deleted.
  • Compositions:
    • Trips (_Trip)
    • Maintenance (_Maintenance)
  • Read-only and system fields:
    • VehicleId is read-only
    • VehicleUUID is auto-numbered (managed UUID)

Example

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;
  }
}

🛠️ Child Behaviors

📝 Maintenance (Child Entity)

  • 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;
  }
}

🚚 Trip (Child Entity)

  • Dependent on Vehicle (lock dependent by _Vehicle)
  • Created only via Vehicle composition
  • Key fields (VehicleId, VehicleUUID, TripId) are read-only
  • Computed field total_trip_cost is 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

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;
}

🔑 Key Takeaways

  • 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: 📐 Projection Layer

Clone this wiki locally