Skip to content

Commit 87bdc63

Browse files
oblomov-devoblomov-dev
authored
Update rap.md
1 parent fb1b2d5 commit 87bdc63

File tree

1 file changed

+70
-119
lines changed
  • docs/technical/technology

1 file changed

+70
-119
lines changed

‎docs/technical/technology/rap.md

Lines changed: 70 additions & 119 deletions
Original file line numberDiff line numberDiff line change
@@ -1,151 +1,102 @@
1-
# RAP: Architecture, State & Communication
1+
# RAP vs. abap2UI5: Architecture, State & Developer Experience
22

3-
This page compares **RAP (Fiori Elements)** with **abap2UI5**, highlighting their differences in architecture, state handling, developer workflow, and client-server communication patterns.
3+
This page provides a structured technical comparison between **RAP (Fiori Elements)** and **abap2UI5**, focusing on architecture, state management, developer workflow, and communication models.
44

5-
---
5+
## 1. Architectural Paradigms
66

7-
## Architecture Comparison
7+
| Aspect | RAP (Fiori Elements) | abap2UI5 |
8+
|-------------------|------------------------------------------------------------------|------------------------------------------------------------|
9+
| **Backend Stack** | CDS Views, Behavior Definitions, OData V4 services | ABAP Classes generating XML Views and JSON ViewModels |
10+
| **Frontend Stack**| UI5 Fiori Elements SPA | Static UI5 Shell |
11+
| **Rendering** | Client interprets metadata and builds UI dynamically | UI structure defined by backend, rendered in frontend |
12+
| **UI Definition** | Annotations in CDS & metadata | XML Views created directly in ABAP |
13+
| **Communication** | OData V4 (metadata, data, actions) | Simple HTTP requests (Over-the-Wire) |
14+
| **Runtime Control**| UI logic partly on frontend, backend provides metadata | Full control over UI and logic in backend |
815

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).
1516

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
17+
## 2. State Management
2618

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 |
19+
| Aspect | RAP (Fiori Elements) | abap2UI5 |
20+
|----------------------------|-------------------------------------------------------|-----------------------------------------------------|
21+
| **State Definition** | Managed via RAP drafts and transaction control | Centralized in ABAP ViewModels |
22+
| **Frontend Involvement** | UI5 components manage transient state | Frontend has no independent state management |
23+
| **Persistence** | Via RAP persistence layer | Reflected through ViewModel updates |
24+
| **User Interaction Flow** | Triggers OData actions, state managed across layers | Triggers backend events, state is updated in ABAP |
3325

34-
---
26+
## 3. Developer Workflow
3527

36-
## Developer Workflow
28+
| Aspect | RAP (Fiori Elements) | abap2UI5 |
29+
|----------------------------|------------------------------------------------------|--------------------------------------------------------|
30+
| **Languages/Artifacts** | CDS, BDEF, UI annotations, UI5 app | ABAP class for both View and logic |
31+
| **Frontend Deployment** | UI5 Fiori Elements runtime app deployed separately | Shared static UI5 Shell (no app-specific deployment) |
32+
| **Tooling Requirements** | ADT, Fiori Tools, metadata layers | Any ABAP IDE (including SE80), no additional tools |
33+
| **Transport** | Separate transport for backend and frontend | Single backend deployment via transport or abapGit |
34+
| **Development Style** | Declarative, metadata-driven | Programmatic, ABAP-centric |
35+
| **Complexity** | High: multiple layers & technologies | Low: one language, one layer |
3736

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 |
4637

47-
---
38+
## 4. Client–Server Communication Flow
4839

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.
40+
### RAP
5941

6042
```plaintext
6143
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)
44+
├──> OData $metadata request
45+
├──> OData entity requests
46+
├──> Renders UI from metadata
47+
├──> Triggers OData actions (CRUD, validation)
6648
Backend (RAP Services)
67-
└──> Processes requests, returns data & actions
49+
└──> Processes requests, returns data/actions
6850
```
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-
51+
### abap2UI5
7952
```plaintext
8053
Browser (Static UI5 Shell)
81-
├──> HTTP Request: Load View & ViewModel
82-
├──> Render UI5 controls from backend definitions
83-
├──> User events → Event Request to backend
54+
├──> HTTP request: Load XML View + ViewModel
55+
├──> Renders UI5 controls as defined by backend
56+
├──> Sends event requests on interaction
8457
Backend (ABAP Class)
85-
└──> Processes events, updates ViewModel, returns changes
58+
└──> Processes event, updates ViewModel, returns changes
8659
```
8760

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
61+
## 5. Flexibility & Runtime Capabilities
10162

102-
Both RAP and abap2UI5 aim to simplify SAP UI development — but follow different paradigms:
63+
| Aspect | RAP (Fiori Elements) | abap2UI5 |
64+
|---------------------------|---------------------------------------------|------------------------------------------|
65+
| **UI Customization** | Limited to what annotations support | Fully flexible via ABAP logic |
66+
| **Runtime Model Dynamics**| Static, metadata-bound | Dynamic via RTTI and runtime logic |
67+
| **Use Case Fit** | Ideal for standard CRUD applications | Suitable for dynamic, backend-driven UIs |
68+
| **Learning Curve** | Steep (new concepts, multiple layers) | Flat (ABAP-only, no metadata tooling) |
10369

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.
10670

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.
71+
## 6. Cloud Readiness & Compliance
10872

73+
| Feature | RAP | abap2UI5 |
74+
|----------------------------|-----------------------------|-------------------------------|
75+
| **ABAP Cloud Compliant** | ✅ Yes | ✅ Yes |
76+
| **CDS/OData Dependency** | ✅ Required | ❌ Not used |
77+
| **Clean Core Compliance** | ✅ Yes | ✅ Yes |
78+
| **Runtime Flexibility** | ❌ Rigid, design-time focus | ✅ Fully runtime-capable |
10979

80+
> 🔒 **Both frameworks are cloud-ready and clean-core compliant.** abap2UI5 achieves this **without CDS or OData**, relying solely on released ABAP APIs.
11081
11182

112-
## What is RAP – and How Does It Compare?
113-
114-
The **RESTful Application Programming Model (RAP)** is SAP's official architecture for building cloud-ready ABAP applications. It is based on:
115-
116-
- **CDS Views** for data modeling (design-time)
117-
- **Behavior Definitions** for logic and validations
118-
- **OData Services** for standardized CRUD operations
119-
- **Fiori Elements** for automatic UI generation
120-
121-
RAP is tightly integrated with ABAP Cloud and follows all required guidelines. However, RAP is an **architectural model**, not a requirement for cloud readiness. A solution can be fully **cloud-compliant without using RAP**, as long as it respects the technical boundaries defined by SAP.
122-
123-
## How abap2UI5 Differs From RAP
124-
125-
**abap2UI5 follows a distinct architectural approach**:
126-
127-
- No CDS, no OData, no Behavior Definitions
128-
- Uses a generic, static UI5 freestyle app
129-
- All UI logic is controlled from ABAP backend classes
130-
- Dynamic data models, even at runtime via RTTI
131-
- Minimal tooling requirements, no metadata layers
132-
133-
Despite not using RAP, abap2UI5 is fully within the boundaries of **ABAP Cloud** and leverages only released objects and compliant techniques.
134-
135-
> 🔒 **Future-Proof**: abap2UI5 avoids design-time model rigidity, reduces learning curve, and remains flexible—while still being clean-core and cloud-ready.
83+
## Conclusion
13684

137-
---
85+
- **RAP (Fiori Elements)** is best suited for standardized, metadata-driven applications using CDS, OData, and annotations.
86+
- **abap2UI5** provides runtime flexibility, backend control, and lower complexity — ideal for dynamic UIs and fast iterations.
13887

139-
## Summary Comparison
14088

141-
| Feature | RAP | abap2UI5 |
142-
|---------------------------|----------------------------------|----------------------------------|
143-
| Cloud Ready | ✅ Yes | ✅ Yes |
144-
| Uses CDS | ✅ Yes | ❌ No |
145-
| Model Definition | Declarative, design-time | Programmatic, runtime-capable |
146-
| UI Technology | Fiori Elements (SAP) | UI5 Freestyle (static) |
147-
| Runtime Dynamic Models | ❌ No | ✅ Yes (via RTTI) |
148-
| Clean Core Compliance | ✅ Yes | ✅ Yes |
149-
| Best for CRUD apps | ✅ Yes | ✅ Yes |
150-
| Learning Curve | High (RAP-specific concepts) | Low (pure ABAP) |
89+
## Summary Table
15190

91+
| Category | RAP (Fiori Elements) | abap2UI5 |
92+
|--------------------------|-------------------------------|-----------------------------------|
93+
| UI Architecture | Metadata-based SPA | Backend-driven Over-the-Wire |
94+
| Data & Actions | OData V4 | Simple HTTP |
95+
| State Handling | RAP Draft + Frontend | Central ABAP ViewModel |
96+
| UI Customization | Limited by annotations | Fully dynamic |
97+
| Tooling | ADT, Fiori Tools | Any ABAP IDE |
98+
| Cloud Readiness | ✅ Yes | ✅ Yes |
99+
| Clean Core | ✅ Yes | ✅ Yes |
100+
| Use Case Fit | Standardized CRUD Apps | Dynamic, backend-controlled UIs |
101+
| Learning Curve | High | Low |
102+
| Deployment | Split backend/frontend | Unified backend class |

0 commit comments

Comments
 (0)