Lesson 3 of 6
Remediate or rebuild as Fiori elements
11 min
Listen to this lesson
For each freestyle app with serious findings, Contoso must choose: remediate the existing code, or rebuild the app as SAP Fiori elements, where the framework owns most of the UI and SAP keeps it current. Neither is always right. A rebuild removes years of debt but needs a suitable OData service and changes the user experience; remediation keeps the app familiar but keeps its custom code. This lesson gives Kenji and Priya a way to decide app by app.
What Fiori elements gives you
SAP Fiori elements generates list reports, object pages, overview pages and other floorplans from OData metadata and annotations. The OData V4 version runs on services such as RAP business services or CAP services, and lets you add custom parts through the flexible programming model (lesson 4). The application code you own shrinks to annotations, a manifest and small extensions; the generated UI follows SAP's design, accessibility and framework changes. That is why Contoso's Fiori elements apps had 3 linter findings while the old freestyle apps had hundreds.
| Criterion | Remediate freestyle code | Rebuild as Fiori elements |
|---|---|---|
| Code Contoso owns afterwards | All of it, now modernized | Annotations, manifest, small extensions |
| Needs | Developers who know the old app | An OData V4 service fitting a floorplan (RAP or CAP) |
| User experience | Unchanged | Standard floorplans; some retraining |
| Future framework changes | Contoso keeps paying | Mostly absorbed by SAP |
| Test effort now | Full regression of the old behavior | New acceptance tests, plus data parity |
| Fits when | Highly custom interaction, few findings | Data-centric list and detail work, many findings |
The decision, app by app
- Is the app still used and still needed?No → retire it · Yes → next question
- Is it mostly list, filter, detail and edit of business data?Yes → next question · No (custom canvas, map, heavy interaction) → remediate
- Is there, or can there be, a suitable OData V4 service (RAP or CAP)?Yes → rebuild as Fiori elements, using FPM for custom parts · No → next question
- Are findings mostly fixable by tool and limited to a few files?Yes → remediate · No → plan the service first, then rebuild
Contoso's decisions
| App | Pattern | Decision | Reason |
|---|---|---|---|
| ZCMC_FLEET_STATUS | List and detail of fleet orders | Remediate now, rebuild later | Findings mostly autofixable; CAP service exists on BTP for the rebuild |
| ZCMC_CLAIMS | Warranty claims list, object, edit | Rebuild as Fiori elements V4 | 610 findings, data-centric, Elena's CAP warranty claims service exists |
| ZCMC_DEPOT_MAP | Map of depots with custom drawing | Remediate (rebuild the map view only) | Highly custom canvas; no floorplan fits |
| ZCMC_RETURN_CAPTURE | Scan-and-capture core returns | Retire | Replaced by the RAP core agreement app; 0 launches in 90 days |
Contoso's decisions for four freestyle apps (illustrative).
Remediation in practice: one app
For ZCMC_FLEET_STATUS, remediation followed a fixed sequence. Ravi first brought the OPA5 suite to the Test Starter and confirmed it was green on the old code. Kenji ran the linter's autofix for globals, reviewed the diff and reran the suite. He then implemented IAsyncContentCreation, switched view and fragment loading to async, replaced sap.ui.getCore().byId() with this.byId(), and moved the inline bootstrap script out of index.html. Two journeys failed after the async change: code ran before the view existed. The fix moved that code into the promise of the async load. Each step was a separate commit with a green suite.
Testing a rebuild is not regression testing
When an app is remediated, the old app is the specification: the regression suite proves nothing changed. When an app is rebuilt, the old app is only a reference: the new app behaves differently by design. Priya plans rebuild testing as acceptance testing against the business tasks (create a claim, attach evidence, approve, see status), plus data parity: the same claims, filters and totals must appear in old and new apps for a sample period. The old app stays available, read-only, until the key users sign off the new one.
What goes wrong
- Rebuilding without a service. The Fiori elements app is blocked for months waiting for an OData V4 service nobody planned.
- Forcing a floorplan. A custom interaction squeezed into a list report frustrates users and grows extensions until it is freestyle again.
- Regression-testing a rebuild. Old scripts fail everywhere because the UI is new; the team concludes the rebuild is broken.
- Switching off the old app too early. No fallback when parity fails.
What would you do?
Elena rebuilt ZCMC_CLAIMS as a Fiori elements V4 app. Ravi runs the old OPA5 regression suite against it and 80% of journeys fail. Grace asks whether the rebuild is broken. What should Priya say?
- Remediation keeps the code and the UX; a Fiori elements rebuild hands most UI code to SAP.
- Rebuild when the app is data-centric and a suitable OData V4 service exists or can be built.
- Remediate highly custom interactions; retire what nobody uses.
- Rebuilds are tested by acceptance and data parity, not by the old regression suite.
Check your understanding · not graded
Lesson check
1. When is a Fiori elements rebuild a good fit?
2. What does a rebuilt app need that a remediated one does not?
3. How is a rebuilt app tested?
4. What should happen to the old app during a rebuild's acceptance?
5. Which app should Contoso retire rather than fix?