SAP Fiori & UI5基礎
SAP Fiori Upgrade Version Management Basics: A Practical Runbook
Learn how to assess SAP Fiori upgrade impact, check UI5 and backend compatibility, validate custom apps, and manage launchpad changes through a controlled operational process.
On this page
SAP Fiori upgrade work is a coordinated change across the launchpad, SAPUI5 libraries, backend services, catalogs, spaces or pages, roles, themes, and custom applications. A reliable process starts with an inventory and ends with user-focused validation rather than treating the upgrade as a single frontend deployment.
The central operational task is to connect each planned software change to its effect on navigation, authorizations, application behavior, and support procedures. Use this runbook to establish a baseline, assess compatibility, test representative journeys, and control the production cutover.
Define the upgrade scope
Record the current SAP Fiori landscape before changing anything. Include the launchpad deployment model, SAPUI5 version, backend product and release, activated OData services, catalogs, spaces or pages, business roles, custom themes, custom applications, and integrations used by critical tiles.
Capture the target versions and the source of each change. Separate frontend library updates, backend support packages, application changes, security changes, and content updates so that a failed test can be traced to a specific workstream. The scope should also identify development, test, and production systems and the transport path between them.
Review the SAP Fiori overview to align the inventory with the main launchpad components and application types. This gives the team a common vocabulary before detailed testing begins.
Build a version compatibility baseline
Create a matrix that relates the SAPUI5 version, backend release, application type, OData service version, browser support, and custom code dependencies. For each application, record whether it is a standard SAP application, an adaptation, or a fully custom app. Include the component or application ID, target mapping, catalog, role, and primary business process.
A compatible version baseline covers more than the UI5 runtime. Check the following areas together:
- SAPUI5 libraries and application descriptor dependencies
- OData service availability, metadata, and authorization
- Launchpad content and target mappings
- Business roles, catalogs, spaces, and pages
- Custom controls, formatters, themes, and extensions
- Browser behavior and supported corporate device profiles
- Integrations such as attachments, workflows, analytics, and document links
Treat version compatibility as a testable relationship. A tile can still appear correctly while its service, authorization, navigation intent, or custom extension fails at runtime.
Assess launchpad upgrade impact
Compare the existing and target launchpad content before importing or activating changes. Identify renamed or retired applications, changed semantic objects and actions, altered parameters, duplicate target mappings, and content that is no longer assigned to the expected roles.
Check the user experience from the perspective of a complete business role. Validate the home page or spaces, navigation, search, intent-based navigation, personalization, notifications, and application back navigation. An upgrade is operationally incomplete when users can launch an application but cannot reach the next step in their process.
Use the SAP Fiori launchpad administration setup guide when reviewing launchpad administration tasks, content assignment, and administrative ownership. Keep the comparison results as a deployment artifact so that changed content can be explained after go-live.
Test SAPUI5 and custom applications
Start with a representative application set rather than testing only the most frequently used tile. Select applications that cover transactional processing, analytical reporting, object navigation, attachments, value helps, draft handling, and custom extensions.
For each application, test the complete path from launchpad entry to save or submission. Inspect browser developer tools for failed resources, JavaScript exceptions, failed OData calls, authorization responses, and incompatible custom dependencies. Verify that busy indicators, messages, dialogs, tables, filters, date handling, and navigation behave as expected.
Custom applications need focused review of the application descriptor, component initialization, library dependencies, manifest changes, reused components, custom controls, and theme assumptions. Rebuild and deploy them through the same controlled pipeline used for the target environment, then test with representative roles rather than a broad administrator account.
Validate roles and authorizations
A launchpad tile, target mapping, backend service, and business authorization are separate control points. Test them separately and then as one user journey. Record the test user, assigned role, catalog or page, application intent, service call, and expected business action.
Check both positive and negative access cases. An authorized user should see and complete the intended process, while an unauthorized user should receive the designed restriction without exposing business data through direct navigation or service calls.
For role-dependent work, use the SAP Fiori role and catalog assignment guide as a companion procedure. Recheck roles after content transport because a technically successful import can still leave missing assignments or obsolete references.
Control caches and deployment order
Plan the deployment sequence for backend content, frontend libraries, custom applications, launchpad content, roles, and related integrations. The exact order depends on the landscape, but every dependency should have an owner and a validation step.
Include cache handling in the runbook. After deployment, clear or refresh the relevant application and launchpad caches according to the landscape procedure, then test from a clean browser session. Test once with a new session and once with a representative existing user session because cached resources can produce different symptoms.
Do not use cache clearing as a substitute for correcting an incorrect resource path, stale application descriptor, missing transport, or failed deployment. Capture the time, operator, affected system, and validation result for each cache operation.
Run a controlled cutover
Use a written cutover checklist with entry criteria, named owners, timestamps, validation evidence, communication points, and rollback actions. Freeze unrelated launchpad content changes during the cutover window so that a failure has a bounded change set.
Before production deployment, confirm that the target versions are available in the approved repositories, transports are sequenced, backups or recovery procedures are available, and business testers are ready. During the window, record deployment output and stop when a defined blocking test fails.
After deployment, validate the highest-value journeys first: launchpad sign-in, role visibility, application launch, read access, create or change processing, save or submit, navigation to related objects, and error handling. Then expand to secondary applications and user groups.
Troubleshoot common upgrade symptoms
Use the symptom to narrow the investigation rather than repeating deployment steps:
| Symptom | Likely investigation areas | First checks |
|---|---|---|
| Tile is missing | Role, catalog, page, target mapping, content transport | Compare the user role and transported content |
| Tile opens an error page | Intent, semantic object, action, application deployment | Inspect the target mapping and application resource |
| Application loads with a blank area | JavaScript exception, missing library, descriptor, cache | Review browser console and network requests |
| Data request fails | OData service, authorization, backend error, destination | Trace the failed request and test the service path |
| Save or submit fails | Business authorization, validation, workflow, backend logic | Reproduce with a representative business role |
| Old UI appears after deployment | Browser or launchpad cache | Test a clean session and execute the approved cache procedure |
| Custom extension breaks | API usage, reused component, control library, theme | Compare the extension dependencies with the target runtime |
For performance symptoms, measure launch time, network requests, backend response time, and rendering behavior separately. The SAP Fiori app performance basics guide provides a focused method for separating frontend, network, and backend contributors.
Close the upgrade with operational evidence
Store the final version matrix, test results, transport list, cache actions, defect decisions, screenshots or logs, and known limitations in the change record. Record the exact user roles and business processes used for acceptance.
Update support documentation with changed application names, new navigation paths, role ownership, browser requirements, and first-response troubleshooting steps. Monitor launchpad errors, failed service calls, authorization failures, and user reports after go-live so that defects are detected before they become widespread.
A completed upgrade has a traceable baseline, tested compatibility, verified authorization, documented deployment evidence, and an owner for every remaining issue.