RAP: Architecture, State & Communication

This page compares RAP (Fiori Elements) with abap2UI5, highlighting their differences in architecture, state handling, developer workflow, and client-server communication patterns.

---

Architecture Comparison

RAP (Fiori Elements)

• Backend: CDS Views, Behaviours, OData V4 services.
• Frontend: UI5 Fiori Elements SPA interprets metadata annotations.
• Rendering: UI is dynamically built in the browser based on OData metadata.
• Communication: OData V4 protocol for data & actions.
• Role of Backend: Supplies data & UI definitions (via annotations).

abap2UI5

• Backend: ABAP Classes define UI5 XML Views & JSON ViewModels.
• Frontend: Static UI5 Shell renders backend-provided Views.
• Rendering: Backend controls UI structure, frontend renders View definition.
• Communication: Simple HTTP requests (Over-the-Wire).
• Role of Backend: Full control of UI structure, state, and logic.

---

State Handling

Aspect	RAP (Fiori Elements)	abap2UI5
State Definition	Handled via RAP Drafts & Managed Transactions	Handled in ABAP ViewModels
Frontend State Management	UI5 controls manage transient state (filters, selections)	Frontend does not manage state independently
Persistence	Draft data persisted via RAP mechanisms	Data/state reflected in backend ViewModels
Interactivity	Client triggers OData actions, state logic often frontend-driven	Events sent to backend, state is updated centrally in ABAP

---

Developer Workflow

Aspect	RAP (Fiori Elements)	abap2UI5
UI Definition	CDS Annotations, OData V4 metadata	ABAP Class (XML View & ViewModel)
Frontend Artifacts	UI5 Fiori Elements runtime (deployed app)	Static UI5 Shell (no separate frontend deployment)
APIs	Typed OData V4 services required	Generic HTTP handler, no OData needed
Development Scope	CDS, Behaviours, Annotations, UI5 Fiori Elements	Pure ABAP Class-based development
Deployment	Backend artifacts + frontend artifacts transported separately	Single backend deployment (abapGit, transport request)
Complexity	Structured, multi-layered	Simplified, backend-centric

---

Client-Server Communication Flow

RAP Flow

1. Browser loads UI5 Fiori Elements SPA.
2. Requests OData V4 $metadata to understand data model & UI annotations.
3. Builds UI dynamically in browser based on metadata.
4. Fetches data via OData entity requests.
5. User interactions trigger OData actions (CRUD, navigation, validation).
6. Backend processes logic, returns OData responses.
7. Client updates UI state accordingly.

Browser (Fiori Elements SPA)
  ├──> OData V4 $metadata Request
  ├──> OData Data Requests
  ├──> UI Rendering from metadata
  └──> OData Calls for user actions (function imports, CRUD)
Backend (RAP Services)
  └──> Processes requests, returns data & actions

abap2UI5 Flow

• Browser loads static UI5 Shell.
• Requests XML View & ViewModel from backend (ABAP Class).
• Frontend renders UI5 controls from provided definitions.
• User events trigger HTTP requests to backend.
• Backend processes events, updates ViewModel.
• Backend returns updated ViewModel.
• Frontend re-binds UI, updating changed controls.

Browser (Static UI5 Shell)
  ├──> HTTP Request: Load View & ViewModel
  ├──> Render UI5 controls from backend definitions
  ├──> User events → Event Request to backend
Backend (ABAP Class)
  └──> Processes events, updates ViewModel, returns changes

Side-by-Side Comparison

Aspect	RAP (Fiori Elements)	abap2UI5
UI Rendering	Client builds UI dynamically from metadata	Frontend renders backend-defined View
Communication	OData V4 (metadata, data, actions)	Simple HTTP event requests & ViewModel updates
State Handling	Mix of frontend & RAP draft mechanisms	Fully backend-driven ViewModel state
Developer Workflow	CDS Views, Behaviours, OData, UI5 annotations	Pure ABAP class development
Frontend Artifacts	Requires UI5 app deployment	Static UI5 Shell, no per-app deployment
Flexibility	Structured, template-based UI, limited runtime changes	Full backend control over UI at runtime
Complexity	High: CDS + OData + UI5 coordination	Low: ABAP-only, Over-the-Wire simplicity

Conclusion

Both RAP and abap2UI5 aim to simplify SAP UI development — but follow different paradigms:

• RAP (Fiori Elements) is ideal for standardized apps with CRUD patterns, leveraging OData and annotations to build structured UIs.
• abap2UI5 enables more runtime flexibility by controlling UI definitions directly in ABAP, reducing frontend complexity and deployment overhead.

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.