Skip to content

Commit 0bb0532

Browse files
oblomov-devoblomov-dev
authored
Create rap.md
1 parent 3ec4bb6 commit 0bb0532

File tree

1 file changed

+107
-0
lines changed

1 file changed

+107
-0
lines changed

‎docs/advanced/technical/rap.md

+107
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,107 @@
1+
# RAP vs abap2UI5: Architecture, State, Workflow & Communication
2+
3+
This page compares **RAP (Fiori Elements)** with **abap2UI5**, highlighting their differences in architecture, state handling, developer workflow, and client-server communication patterns.
4+
5+
---
6+
7+
## Architecture Comparison
8+
9+
### RAP (Fiori Elements)
10+
- **Backend**: CDS Views, Behaviours, OData V4 services.
11+
- **Frontend**: UI5 Fiori Elements SPA interprets metadata annotations.
12+
- **Rendering**: UI is dynamically built in the browser based on OData metadata.
13+
- **Communication**: OData V4 protocol for data & actions.
14+
- **Role of Backend**: Supplies data & UI definitions (via annotations).
15+
16+
### abap2UI5
17+
- **Backend**: ABAP Classes define UI5 XML Views & JSON ViewModels.
18+
- **Frontend**: Static UI5 Shell renders backend-provided Views.
19+
- **Rendering**: Backend controls UI structure, frontend renders View definition.
20+
- **Communication**: Simple HTTP requests (Over-the-Wire).
21+
- **Role of Backend**: Full control of UI structure, state, and logic.
22+
23+
---
24+
25+
## State Handling
26+
27+
| Aspect | RAP (Fiori Elements) | abap2UI5 |
28+
|--------|----------------------|----------|
29+
| **State Definition** | Handled via RAP Drafts & Managed Transactions | Handled in ABAP ViewModels |
30+
| **Frontend State Management** | UI5 controls manage transient state (filters, selections) | Frontend does not manage state independently |
31+
| **Persistence** | Draft data persisted via RAP mechanisms | Data/state reflected in backend ViewModels |
32+
| **Interactivity** | Client triggers OData actions, state logic often frontend-driven | Events sent to backend, state is updated centrally in ABAP |
33+
34+
---
35+
36+
## Developer Workflow
37+
38+
| Aspect | RAP (Fiori Elements) | abap2UI5 |
39+
|--------|----------------------|----------|
40+
| **UI Definition** | CDS Annotations, OData V4 metadata | ABAP Class (XML View & ViewModel) |
41+
| **Frontend Artifacts** | UI5 Fiori Elements runtime (deployed app) | Static UI5 Shell (no separate frontend deployment) |
42+
| **APIs** | Typed OData V4 services required | Generic HTTP handler, no OData needed |
43+
| **Development Scope** | CDS, Behaviours, Annotations, UI5 Fiori Elements | Pure ABAP Class-based development |
44+
| **Deployment** | Backend artifacts + frontend artifacts transported separately | Single backend deployment (abapGit, transport request) |
45+
| **Complexity** | Structured, multi-layered | Simplified, backend-centric |
46+
47+
---
48+
49+
## Client-Server Communication Flow
50+
51+
### RAP Flow
52+
1. **Browser loads UI5 Fiori Elements SPA**.
53+
2. **Requests OData V4 $metadata** to understand data model & UI annotations.
54+
3. **Builds UI dynamically in browser** based on metadata.
55+
4. **Fetches data via OData entity requests**.
56+
5. **User interactions trigger OData actions** (CRUD, navigation, validation).
57+
6. Backend processes logic, returns OData responses.
58+
7. Client updates UI state accordingly.
59+
60+
```plaintext
61+
Browser (Fiori Elements SPA)
62+
├──> OData V4 $metadata Request
63+
├──> OData Data Requests
64+
├──> UI Rendering from metadata
65+
└──> OData Calls for user actions (function imports, CRUD)
66+
Backend (RAP Services)
67+
└──> Processes requests, returns data & actions
68+
```
69+
70+
## abap2UI5 Flow
71+
- Browser loads static UI5 Shell.
72+
- Requests XML View & ViewModel from backend (ABAP Class).
73+
- Frontend renders UI5 controls from provided definitions.
74+
- User events trigger HTTP requests to backend.
75+
- Backend processes events, updates ViewModel.
76+
- Backend returns updated ViewModel.
77+
- Frontend re-binds UI, updating changed controls.
78+
79+
```plaintext
80+
Browser (Static UI5 Shell)
81+
├──> HTTP Request: Load View & ViewModel
82+
├──> Render UI5 controls from backend definitions
83+
├──> User events → Event Request to backend
84+
Backend (ABAP Class)
85+
└──> Processes events, updates ViewModel, returns changes
86+
```
87+
88+
## Side-by-Side Comparison
89+
90+
| Aspect | RAP (Fiori Elements) | abap2UI5 |
91+
|--------|----------------------|----------|
92+
| **UI Rendering** | Client builds UI dynamically from metadata | Frontend renders backend-defined View |
93+
| **Communication** | OData V4 (metadata, data, actions) | Simple HTTP event requests & ViewModel updates |
94+
| **State Handling** | Mix of frontend & RAP draft mechanisms | Fully backend-driven ViewModel state |
95+
| **Developer Workflow** | CDS Views, Behaviours, OData, UI5 annotations | Pure ABAP class development |
96+
| **Frontend Artifacts** | Requires UI5 app deployment | Static UI5 Shell, no per-app deployment |
97+
| **Flexibility** | Structured, template-based UI, limited runtime changes | Full backend control over UI at runtime |
98+
| **Complexity** | High: CDS + OData + UI5 coordination | Low: ABAP-only, Over-the-Wire simplicity |
99+
100+
## Conclusion
101+
102+
Both RAP and abap2UI5 aim to simplify SAP UI development — but follow different paradigms:
103+
104+
- **RAP (Fiori Elements)** is ideal for standardized apps with CRUD patterns, leveraging OData and annotations to build structured UIs.
105+
- **abap2UI5** enables more runtime flexibility by controlling UI definitions directly in ABAP, reducing frontend complexity and deployment overhead.
106+
107+
For projects where rapid development, backend-driven UI control, and simplified architecture are key, **abap2UI5 offers a pragmatic alternative** to the more SPA-centric RAP approach.

0 commit comments

Comments
 (0)