How to Extend SAP RAP Apps: Choosing the Right Strategy

I once worked on a requirement to extend standard SAP RAP applications - Manage Credit Accounts and Manage Credit Limit Requests.

Extending a RAP-based app isn’t a one-size-fits-all activity. You have multiple options, and choosing the right approach is crucial to keeping your system stable, upgrade-safe, and clean.

This work was done on an SAP S/4HANA On-Premise 2022 system

---

💡 The Requirement

In the Manage Credit Accounts app, the business asked for the following:

1. Field addition in Credit Segment (a child object page):
   
   
   Fields needed to be added to the Limit section. If not possible, a new section like Credit Limit Details could be created.

2. A new section for Payment Terms

   • Display a list of Payment Terms linked to each Business Partner and Credit Segment.

   • This requires a new child entity (composition node).

3. An Additional Information section

   • To show more fields appended to the parent entity.

4. Field mode control

   • In Manage Credit Accounts: all custom fields must be read-only.

   • In Manage Credit Limit Requests: the same fields must be editable.

---

🔧 What Extensions Were Needed?

1. Field additions to the root entity

   • Extend CDS view

   • Create a higher-priority metadata extension to expose fields to the UI

2. New child entity for Payment Terms

   • Introduce a new composition CDS view

3. Make fields read-only

   • Extend behavior definition to set field control

Sounds simple? It’s not - because we’re working with standard RAP apps, not custom ones. Let’s go through each approach.

---

🧭 Approach 1: Key User Extensibility (Adapt UI)

This is always the first option to evaluate.

✅ Pros

• Quick to use

• No custom development

❌ Limitations

• Can only add fields via Adapt UI

• Cannot create new sections or table controls

• No support to make fields conditionally read-only

• No BAdIs or behavior extensions available

Since our requirement involved making fields read-only, we checked whether it could be achieved using developer extensibility, particularly through behavior definition extensions.

Unfortunately, both:

• R_CRDTMBUSINESSPARTNERTP and

• R_CREDITLIMITREQUESTTP

are not extensible behavior definitions, which rules out clean developer extensibility as well.

---

🧩 Approach 2: UI5 Adaptation Project – Add Fields and Sections

🔄 Steps

1. Create a UI5 Adaptation Project

2. Switch to Advanced Mode to make fields read-only

3. Add a table control for Payment Terms

4. Create a custom OData service

   • Use a custom table for Payment Terms

5. Extend C_CREDITMGMTACCOUNTTP BO to include additional fields

6. Create a metadata extension for new fields

7. Add new Tile and Target Mapping in the Fiori Launchpad

8. Map standard app to the custom adaptation project

❌ Limitations

• Advanced Mode is not guaranteed upgrade-safe

• UI5 extension points are missing

• Results in two separate apps (standard + adapted)

• Requires additional OData/CDS enhancements

• Navigation from Manage Business Partners also needs to be enhanced

---

🔗 Approach 3: UI5 Adaptation Project – Add Navigation to Custom App

🔄 Steps

1. Create a UI5 Adaptation Project

2. Add a navigation link/button to open a custom app

3. Implement two custom apps:

   • One read-only (for Manage Credit Accounts)

   • One editable (for Manage Credit Limit Requests)

4. Create and expose custom tables and OData services

5. Add new Tile and Target Mapping in the FLP

6. Map the adapted app with relevant standard apps

❌ Limitations

Same as Approach 2, including potential upgrade instability, dual app management, and navigation complexity.

---

🚀 Approach 4: RAP-Based Intent Navigation to Custom App

Here we extend the RAP BO to include a dummy field (BP2) and assign intent-based navigation using metadata extension.

🔄 Steps

1. Extend R_CREDITMGMTACCOUNTTP to include dummy field (e.g., BP2)
   

2. Extend C_CREDITMGMTACCOUNTTP to include navigation association
   

3. Extend UKM_ACCOUNT_DR (draft table) to include BP2
   

4. Extend R_CREDITMGMTACCOUNTDRAFT for new field
   

5. Create metadata extension to enable navigation on BP2
   

Repeat similar steps for Manage Credit Limit Requests app as well.

Result:

• Users click the navigation link (BP2)

• Object page opens in a custom RAP app
  
  
  

---

✅ Final Architecture

We built two custom RAP apps:

• One with CUD operations enabled (for Manage Credit Limit Requests)

• One in read-only mode (for Manage Credit Accounts)

Both apps reuse the same BO and UI but differ in behavior via configuration and launch context.

Why not just one custom app❓

You might wonder, why not combine everything into a single custom app and control the field behavior dynamically?

The reason is:

When navigating from standard apps to a custom app, we don't receive any context about where the navigation originated.

Since we can’t detect whether the user came from Manage Credit Accounts or Manage Credit Limit Requests, we can’t dynamically switch fields between editable and read-only modes.

That’s why we had to create two separate apps, each with its own field control behavior.

---

🎯 Summary: Choosing the Right RAP Extension Strategy

Approach	Upgrade-Safe	Field Add	New Section	Read-only Logic	Navigation
Key User Extensibility	✅	✅	❌	❌	❌
UI5 Adaptation (Direct Change)	❌	✅	✅	⚠️ (Advanced Mode)	❌
UI5 Adaptation (Link to Custom App)	❌	✅ (in custom app)	✅	✅	✅
Custom RAP-based App	✅	✅	✅	✅	✅

---

Let me know if you'd like help implementing similar extensions, or just want to learn how to build RAP apps from scratch!

📩 Connect with me on Topmate

📚 Explore More on RAP

If you're exploring more on SAP RAP from basics to advanced use cases, check out the complete blog series here:
👉 https://sachinartani.com/blog/sap-rap-series