|
| 1 | +--- |
| 2 | +outline: [2, 4] |
| 3 | +--- |
| 4 | +# RAP |
| 5 | + |
| 6 | +### RAP is a Programming Model — abap2UI5 is Not |
| 7 | + |
| 8 | +**RAP (RESTful Application Programming Model)** is a full-stack programming model. It prescribes how you design, expose, and consume business objects: you define entities with CDS views, declare their behavior in Behavior Definitions (BDEFs), implement handlers in Behavior Implementation classes, and expose everything as an OData V4 service consumed by a Fiori Elements frontend. Every layer is part of the model. |
| 9 | + |
| 10 | +**abap2UI5 is not a programming model.** It is a UI rendering library — a single ABAP interface your class implements. It has no opinion on how you structure your data, which access layer you use, or how your business logic is organized. There is no CDS requirement, no BDEF, no OData service. abap2UI5 simply calls your `main` method on each user interaction and renders whatever view you return. |
| 11 | + |
| 12 | +This distinction matters: RAP defines the architecture *around* your application. abap2UI5 only defines how the UI is built *inside* your ABAP class. |
| 13 | + |
| 14 | +### abap2UI5 is Agnostic |
| 15 | + |
| 16 | +Because abap2UI5 imposes no access layer, you pick whatever fits: |
| 17 | + |
| 18 | +| Access Layer | Works in abap2UI5? | |
| 19 | +|---|---| |
| 20 | +| ABAP SQL (`SELECT`, `INSERT`, …) | ✅ | |
| 21 | +| CDS Views (VDM, custom) | ✅ | |
| 22 | +| EML (`READ ENTITIES`, `MODIFY ENTITIES`) | ✅ | |
| 23 | +| Function modules, BAPIs | ✅ | |
| 24 | +| RAP actions called via EML | ✅ | |
| 25 | +| Direct table access | ✅ | |
| 26 | + |
| 27 | +Nothing is excluded. The abap2UI5 controller is a plain ABAP class — any statement that is valid in ABAP is valid there. |
| 28 | + |
| 29 | +### Using RAP Functionality from Outside |
| 30 | + |
| 31 | +When you call EML from inside the RAP framework (e.g., from a Behavior Implementation), the framework enforces its own rules: no explicit `COMMIT WORK`, no direct database modifications, controlled side effects. |
| 32 | + |
| 33 | +abap2UI5 runs **outside** the RAP framework. This means all RAP restrictions that apply inside the framework do not apply here. You call EML freely: |
| 34 | + |
| 35 | +```abap |
| 36 | +READ ENTITIES OF i_salesordertp |
| 37 | + ENTITY salesorder |
| 38 | + ALL FIELDS WITH VALUE #( ( SalesOrder = `0000000001` ) ) |
| 39 | + RESULT DATA(lt_result). |
| 40 | +``` |
| 41 | + |
| 42 | +```abap |
| 43 | +MODIFY ENTITIES OF i_salesordertp |
| 44 | + ENTITY salesorder |
| 45 | + CREATE FIELDS ( salesordertype salesorganization soldtoparty ) |
| 46 | + WITH VALUE #( ( %cid = `001` %data = VALUE #( ... ) ) ) |
| 47 | + MAPPED DATA(ls_mapped) |
| 48 | + FAILED DATA(ls_failed) |
| 49 | + REPORTED DATA(ls_reported). |
| 50 | +
|
| 51 | +COMMIT ENTITIES BEGIN |
| 52 | + RESPONSE OF i_salesordertp |
| 53 | + FAILED DATA(ls_save_failed) |
| 54 | + REPORTED DATA(ls_save_reported). |
| 55 | +COMMIT ENTITIES END. |
| 56 | +``` |
| 57 | + |
| 58 | +The explicit `COMMIT ENTITIES` is required — and fully permitted — because you are not inside a RAP handler. The same applies to reading CDS views, calling RAP actions, or accessing draft tables directly. |
| 59 | + |
| 60 | +::: tip |
| 61 | +Running outside the RAP framework gives you more control: you decide when to commit, how to handle errors, and how to combine multiple business object operations in one user interaction. |
| 62 | +::: |
0 commit comments