Three RAP Patterns I Had to Re-Discover While Building My Learning Hub App
Three RAP Patterns I Had to Re-Discover While Building My Learning Hub App
While I was working on my skill-management app (the same one I mentioned in the post From Templates to Real Projects: Practicing RAP on Something That Matters), a real project task suddenly came up and took quite some time to figure out the “right” implementation approach.
And — looking ahead — this is exactly what I meant in that post: until you have a real functional goal in your app, you never fully discover what is possible, what pitfalls appear, and what patterns you’ll inevitably need.
Below are three patterns I implemented in my Learning Hub app, all inspired by a real project scenario.
And — looking ahead — this is exactly what I meant in that post: until you have a real functional goal in your app, you never fully discover what is possible, what pitfalls appear, and what patterns you’ll inevitably need.
Below are three patterns I implemented in my Learning Hub app, all inspired by a real project scenario.
Hiding Child Entity Fields When a Parent Field Changes
In my setup, the parent entity is Course, and the child entity is Material.
I added a Released flag to the Course, meaning the course is already published, learners have started taking it, and therefore major structural changes should not be allowed.
Once Released is checked:
To achieve this, I added feature control to the child entity.
I added a Released flag to the Course, meaning the course is already published, learners have started taking it, and therefore major structural changes should not be allowed.
Once Released is checked:
- new materials must not be created
- existing materials must not allow changes to fields like Name or Type
To achieve this, I added feature control to the child entity.
But simply placing feature control on child fields is not enough: changing a parent field does not update the child entity automatically.
The missing piece is a side effect on the parent entity.
The missing piece is a side effect on the parent entity.
When Released changes, the side effect forces permission recalculation, which triggers feature control and authority checks on the child fields.
The same logic hides the “Create” button for Materials — managed via feature control on the parent.
The same logic hides the “Create” button for Materials — managed via feature control on the parent.
Clearing Child Records When a Parent Field Changes
I extended the Course with:
Automating Constant Class Generation from Domain Values in ABAP
Both fields influence what materials should exist.
So the rule is:
If Course Type or Skill Category changes, Materials must be cleared.
I implemented this with a determination on the Course entity, deleting all child records whenever either field is modified.
- Course Type (self-paced, offline, online, master class, etc.)
- Skill Category (hard vs soft skill)
Automating Constant Class Generation from Domain Values in ABAP
Both fields influence what materials should exist.
So the rule is:
If Course Type or Skill Category changes, Materials must be cleared.
I implemented this with a determination on the Course entity, deleting all child records whenever either field is modified.
Validation When Saving a Parent Without Any Child Records
A validation that checks “at least one child exists” works during creation.
But if the user enters Edit mode, deletes all children, and saves without touching the parent — the validation won’t fire, because the parent hasn’t changed.
To fix this, the validation must run always.
In the prepare section of the validation, the execution mode should be ALWAYS, ensuring it triggers even when only child data changed.
But if the user enters Edit mode, deletes all children, and saves without touching the parent — the validation won’t fire, because the parent hasn’t changed.
To fix this, the validation must run always.
In the prepare section of the validation, the execution mode should be ALWAYS, ensuring it triggers even when only child data changed.
Before moving on to the plans:
👉 The code for all these features is available on my GitHub:
https://github.com/JuliaBerteneva/LearningHubRAP.git
👉 The code for all these features is available on my GitHub:
https://github.com/JuliaBerteneva/LearningHubRAP.git
Plans for What’s Next
🔹 Moderator WorkspaceA dedicated moderator interface is needed. Moderators should be able to:
🔹 Roles & Test UsersI also want to introduce a more conscious role separation — learner, moderator, admin — and assign proper authorizations to test users to simulate real scenarios more accurately.
🔹 Clean ABAP & Code QualityI recently installed Code Pal to enforce Clean ABAP rules, so a separate post about developer tooling and code quality is coming soon.
If you need the implementation logic, check the GitHub repo https://github.com/JuliaBerteneva/LearningHubRAP.git.
- create new courses
- see and manage only their courses
- have a compact workspace panel
🔹 Roles & Test UsersI also want to introduce a more conscious role separation — learner, moderator, admin — and assign proper authorizations to test users to simulate real scenarios more accurately.
🔹 Clean ABAP & Code QualityI recently installed Code Pal to enforce Clean ABAP rules, so a separate post about developer tooling and code quality is coming soon.
If you need the implementation logic, check the GitHub repo https://github.com/JuliaBerteneva/LearningHubRAP.git.
