Introduction
Standard Fiori apps usually display static tiles. But what if your business users want something more dynamic?
Imagine maintaining tile text, tooltip, and navigation links inside a custom table — and having the Fiori app automatically generate tiles based on that data.
No hardcoding. No redeployment for every change. Just clean backend-driven UI behavior.
In this article, you’ll learn how to create multiple dynamic tiles inside a single SAP Fiori application using:
Custom table configuration
ABAP logic (FM)
OData/CDS service
SAPUI5 dynamic tile creation
Let’s build it step by step.
Business Scenario
The requirement is simple:
Maintain tile text, tooltip, and navigation path in a custom table
Fetch the data via OData
Dynamically generate multiple tiles inside one Fiori app
Navigate based on backend configuration
This allows functional teams to change tile behavior without modifying UI5 code.
Step 1: Create Custom Table for Tile Configuration (SE11)
First, create a custom table to store tile-related configuration.
Maintain fields similar to:
Tile Header (Title Text)
Tooltip Text
Navigation Link / Target URL
Any additional identifier if required
Activate the table after maintaining technical settings.
If technical settings were maintained in a separate screen:
This table becomes the backend control center for all tiles.
Step 2: Maintain Sample Data in the Custom Table (SM30)
After activation, generate Table Maintenance (if required) and maintain entries.
Add multiple records — each record represents one tile.
For example:
Record 1 → Header A, Tooltip A, Link A
Record 2 → Header B, Tooltip B, Link B
Now the backend configuration is ready.
Step 3: Create ABAP Logic to Fetch Table Data
Create a Function Module or class method that:
Selects all entries from the custom table
Moves data into exporting structure
Prepares data for OData exposure
Keep logic clean and avoid unnecessary processing.
Example flow:
SELECT * FROM custom_table INTO internal table
Loop and append to export structure
This logic acts as the data provider layer.
Step 4: Implement the Behavior Logic
Create the behavior implementation class.
Inside the action method:
Read incoming data
Perform validations
Prepare data for update
This is the best place to:
Check mandatory fields
Validate values
Reject invalid records gracefully
Step 5: Save Logic – Let RAP Handle the Commit
The SAVE method is responsible for updating the database table.
Important things to remember:
Do not use
COMMIT WORKRAP framework handles commits automatically
Perform updates in a controlled way
Any errors should be captured into the REPORTED internal table.
Step 6: Create Service Definition
Create a service definition on top of the behavior definition.
Expose:
The CDS root entity
This makes the entity available for consumption via OData.
Step 7: Create and Publish Service Binding
Create a service binding for the service definition.
Choose based on your requirement:
OData V2 →
/IWFND/MAINT_SERVICEOData V4 →
/IWFND/V4_ADMIN
Publish the service binding after creation.
Step 8: Test the API Action
Use the Service Test option to trigger the action.
The action URL format will look like:
<service_name>/<root_entity_alias>(<key>)/SAP__self.<action>
Pass multiple records in the request payload to verify:
Successful updates
Proper error handling
Common Mistakes Developers Make
❌ Using managed behavior for complex mass updates
This limits control and complicates validations.
❌ Calling COMMIT WORK manually
RAP already manages the transaction lifecycle.
❌ Updating the database inside action methods
Always perform DB updates in the SAVE method.
❌ Ignoring error reporting
Use the REPORTED table to return meaningful messages.
Frequently Asked Questions
Can this API update thousands of records at once?
Yes. The action parameter supports table types designed for mass processing.
Is this approach safe for integrations?
Absolutely. RAP ensures transactional consistency and error handling.
Should I use managed behavior instead?
Use managed behavior only when standard CRUD operations are sufficient.
🎉 Final Thoughts
You learned how to build a RAP-based API to update custom table data in bulk using unmanaged behavior and actions.
This approach avoids unsafe commits, supports validations, and scales cleanly for real-world integration scenarios.
If this API will be consumed by external systems, understanding SAP CPI integration flows is essential.
“SAP solution architect with a strong problem-solving mindset, sharing practical SAP S/4HANA and ABAP insights from real-world projects.”
