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 ​

Developer Workflow ​

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 ​

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.

What is RAP – and How Does It Compare? ​

The RESTful Application Programming Model (RAP) is SAP's official architecture for building cloud-ready ABAP applications. It is based on:

• CDS Views for data modeling (design-time)
• Behavior Definitions for logic and validations
• OData Services for standardized CRUD operations
• Fiori Elements for automatic UI generation

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.

How abap2UI5 Differs From RAP ​

abap2UI5 follows a distinct architectural approach:

• No CDS, no OData, no Behavior Definitions
• Uses a generic, static UI5 freestyle app
• All UI logic is controlled from ABAP backend classes
• Dynamic data models, even at runtime via RTTI
• Minimal tooling requirements, no metadata layers

Despite not using RAP, abap2UI5 is fully within the boundaries of ABAP Cloud and leverages only released objects and compliant techniques.

🔒 Future-Proof: abap2UI5 avoids design-time model rigidity, reduces learning curve, and remains flexible—while still being clean-core and cloud-ready.

Summary Comparison ​