When building applications with the RESTful ABAP Programming Model (RAP), the same business logic often needs to serve different consumers: desktop users via Fiori apps and mobile users via lightweight applications.
In this post, we demonstrate how to reuse a single RAP Business Object and expose it as two optimized OData V4 services:
- A draft-enabled service for Fiori Elements (desktop)
- A lightweight, non-draft service for mobile apps using SAP Mobile Services and MDK
This approach allows you to keep one consistent backend while tailoring the API to the needs of each consumer.
Step 1 – Create or Reuse a RAP Business Object
Start by creating a RAP Business Object or reusing an existing one.
In this example, we used the OData UI Service from Scratch Generator to generate a complete RAP application from an empty package. This includes:
- CDS views
- Behavior definitions
- Service definition and binding
- Fiori Elements UI
Step 2 – Create a Mobile-Specific Projection (Without Draft)
For mobile scenarios, draft handling is often unnecessary and adds complexity.
Instead of modifying the existing BO, create a separate projection layer:
- ZC_EVENT_M (mobile projection)
- Based on the same root entity
- Without draft behavior
Example behavior definition:
projection;
strict (2);
define behavior for ZC_EVENT_M alias Event
{
use create;
use update;
use delete;
}
This provides a clean CRUD API without draft semantics. This avoids unnecessary draft handling in mobile scenarios and simplifies the API consumption in MDK.
Step 3 – Expose a Dedicated Mobile Service
We created a separate service for mobile consumption:
- Service Definition: ZUI_EVENT_MOBILE
- Service Binding: ZUI_EVENT_MOBILE_O4
define service ZUI_EVENT_MOBILE {
expose ZC_EVENT_M as Event;
}
This ensures:
- No draft endpoints
- Lightweight API for mobile apps
Step 4 – Add UI Annotations for Mobile Preview
Without dedicated UI annotations, the MDK wizard may not generate the expected columns – either showing too many fields or missing the intended selection and order.
Reason:
- UI annotations were only defined for the Fiori projection (ZC_EVENT000)
- The mobile service exposes ZC_EVENT_M
Solution:
- Create a separate Metadata Extension for ZC_EVENT_M
Example:
annotate view ZC_EVENT_M with
{
@ui.lineItem: [{ position: 10 }]
EventID;
@ui.lineItem: [{ position: 20 }]
EventName;
@ui.lineItem: [{ position: 30 }]
DateFrom;
@ui.lineItem: [{ position: 30 }]
DateTo;
}
After this step, the mobile preview correctly displays the list report.
Step 5 – Backend Communication Setup
On the backend, create the communication scenario and communication arrangement to expose your OData service.
This step provides the service URL, which will be consumed from SAP BTP.
Step 6 – Create the SAP BTP Destination
Next, create a destination in SAP BTP pointing to your RAP OData service.
Configure the destination according to your authentication setup (e.g. OAuth 2.0 / token exchange).
This acts as the connection layer between RAP and Mobile Services.
Step 7 – Create the Mobile Services Application
Create a new Mobile Services application connected to your destination.
Before proceeding further, test your OData service here.
This is a crucial checkpoint to ensure:
- the destination works
- authentication is correct
- the service is reachable
- metadata loads successfully
Testing here early avoids debugging issues later in MDK.
Step 8 – Build the MDK App in BAS
In SAP Business Application Studio, create a new project:
New Project from Template → MDK
When selecting the template type, choose CRUD.
This is important because:
- the CRUD template enables create, update, and delete operations
- otherwise, the app may behave as read-only
From here, you can:
- bind the app to your OData service
- define pages and navigation
- implement mobile-specific UI logic
Architecture Overview
Fiori App Preview:
Mobile App:
Lessons Learned
The most challenging part was getting the OData service to work smoothly within the MDK application. Additional OData vocabulary references generated by the RAP system caused issues in the MDK app.
These references had to be ignored in the CDS configuration, which took some time to identify.
Key Takeaways
- RAP allows you to reuse one BO for multiple channels
- Draft is useful for Fiori, but often not required for mobile
- A separate projection + service is a clean design for mobile scenarios
- UI annotations must match the exposed entity
- Always test your service in Mobile Services before MDK development
- Use the MDK CRUD template to enable full interaction
#SAPCHANNEL