A full-stack RESTful ABAP Programming Model (RAP) transactional application built on SAP BTP ABAP Environment, demonstrating a modern, clean-core-compliant approach to developing custom business objects in ABAP Cloud.
The application implements a simplified Sales Order Management system — the kind of transactional app a company might build for an internal ordering portal, a B2B partner self-service channel, or any scenario that needs order capture and approval without the full complexity of standard SAP Sales & Distribution (SD).
Typical users:
| Role | What they do |
|---|---|
| Sales Representative | Creates orders, adds line items, saves drafts, edits in progress |
| Sales Manager | Approves or cancels orders; large orders are routed for manager approval |
| Fulfillment / Operations | Monitors open orders using the aging (criticality) indicator |
| Finance | Reviews order totals, calculated automatically from line items |
| IT / Admin | Maintains the number range, product master data, and the nightly criticality refresh job |
The Business Object follows the standard two-layer RAP pattern (Interface View + Consumption View), with root and child behavior defined for the Header/Item composition tree.
Database Tables (persistent + draft)
│
▼
Interface Views (ZI_*) ──► Behavior Definition (managed, draft-enabled)
│
▼
Consumption Views (ZC_*) ──► Behavior Definition (projection)
│
▼
Service Definition ──► Service Binding (OData V4 – UI) ──► Fiori Elements
Sales Order (root)
└── Sales Order Item (composition child, 1..*)
- Managed RAP implementation with Draft capability (Edit / Activate / Discard / Resume)
- Header–Item composition with deep create support
- Row-level Access Control (DCL) — users only see orders they created (
CreatedBy = $session.user)
- Number Range Object (buffered) for concurrency-safe, human-readable Order IDs (
SO_2026_00001) - Automatic, per-order sequential Item Numbering (10, 20, 30…)
- Automatic default values (Order Status, Order Date, Product ID prefix)
Item Amount = Quantity × Unit Price— calculated automaticallyTotal Amount= sum of all item amounts — kept in sync via a shared internal action, triggered from both header and item-level determinations- RAP Side Effects for instant, save-free UI recalculation
- Careful handling of the RAP restriction that only
on savedeterminations can react to delete operations
- Quantity must be greater than zero
- Unit Price cannot be negative
- Customer ID must follow the required naming convention
- Product ID must exist in the product master (referential integrity, validated with bulk
FOR ALL ENTRIESlookups)
Approve,Cancel, andRequest Approvalactions with dynamic feature control (buttons enable/disable based on order status and amount)- Multi-step approval: orders below a configurable threshold can be approved directly; orders at or above the threshold require manager approval instead
- Order Age Criticality — color-coded aging indicator (green / yellow / red) based on days since order date, ignoring closed orders
- Status Criticality — color + icon indicator on the Overall Status column, matching common Fiori status-column conventions
- A background "refresh" utility class simulates the nightly batch job pattern real SAP systems use for date-driven status recalculation
- Value Help for Product ID, sourced from a dedicated product master CDS view
- Sorted list report (by Order ID, ascending)
- Secondary database index on the item table's parent-key field
- Bulk, set-based SQL patterns throughout (no row-by-row database calls inside loops)
- ABAP Unit Tests using the CDS Test Double Framework and SQL Test Double Framework — one positive (happy path) test and four negative tests validating that invalid data is correctly rejected
| Category | Objects |
|---|---|
| Database Tables | ZSOL_ORDER, ZSOL_ORDER_ITEM, ZSOL_PRODUCT, draft tables |
| Data Elements | ZSOL_ORDER_UUID, ZSOL_ORDER_ID, ZSOL_CUSTOMER_ID, ZSOL_PRODUCT_ID, ZSOL_ORDER_STATUS, ZSOL_QUANTITY, ZSOL_PRICE_AMOUNT, ZSOL_ORDER_DATE, and more |
| Interface Views | ZI_SALESORDER_OD, ZI_SALESORDERITEM_OD, ZI_PRODUCT_VH_OD |
| Consumption Views | ZC_SALESORDER_OD, ZC_SALESORDERITEM_OD |
| Metadata Extensions | UI annotations for both consumption views |
| Behavior Definitions | Interface-level (managed, draft) and projection-level, for both Header and Item |
| Access Controls | ZI_SALESORDER_OD, ZC_SALESORDER_OD |
| Service Definition / Binding | ZSALESORDER_OD_UI, OData V4 – UI |
| Classes | ZBP_I_SALESORDER_OD (behavior implementation + unit tests), ZCL_SOL_CRITICALITY_HELPER, ZCL_REFRESH_ORDER_CRITICALITY, ZCL_INSERT_PRODUCTS |
| Number Range Object | ZSOL_ORDNR |
| Database Index | ZSOL_ORDER_ITEM~PAR |
- ABAP Cloud on SAP BTP ABAP Environment
- RAP (RESTful ABAP Programming Model) — managed, draft-enabled business objects
- CDS (Core Data Services) — Interface Views, Consumption Views, Metadata Extensions, Access Control (DCL)
- OData V4 UI Service, consumed via SAP Fiori Elements
- ABAP Unit with the CDS Test Double Framework and SQL Test Double Framework
- Eclipse ABAP Development Tools (ADT)
This project intentionally focuses on demonstrating RAP concepts end-to-end. A production deployment would additionally need:
- Authorization based on real PFCG roles / authorization objects, not just a single DCL condition
- Integration with real Business Partner and Material Master data instead of simplified custom tables
- The criticality-refresh job running as an actual scheduled background job, with error handling and restart-ability
- Change Document / audit history for full field-level change tracking
- Integration events (e.g., notifying Finance or Logistics when an order is approved)
- Broader ABAP Unit coverage, including tests for the Access Control layer and action feature control
This project was built step by step while studying for the SAP Certified Associate – Back-End Developer – ABAP Cloud certification, with a deliberate focus on using only current, SAP-recommended ABAP Cloud patterns (managed RAP, CDS-based data modeling, clean-core principles) rather than classic ABAP techniques.