RAP / CDS / ODataintermediate

SAPUI5 and Fiori Tools Part 7: Deployment to BTP and ABAP

Key takeaway

Deploy a SAPUI5/Fiori app to production: build it, deploy to the ABAP repository or to SAP BTP, register it in the Fiori launchpad with tiles and roles, and manage transports and versions.

Explanation

📌 KEY POINTS
✅ Two main targets: ABAP repository (BSP application, transported like ABAP) or SAP BTP (HTML5 app repository).
✅ Fiori tools create the deploy configuration; "npm run deploy" builds and deploys.
✅ Users need a launchpad tile/target mapping and a role — deployment alone is not enough.
⚠️ Deploy to DEV only; move to QAS/PRD via transports (ABAP) or pipelines (BTP).

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–6 built and tested the app. This final part brings it to users.

━━━━━━━━━━━━━━━━━━━━
▶ 1. BUILD
"ui5 build" (or the build step of npm scripts generated by Fiori tools) creates a dist folder: minified files, Component-preload.js, i18n bundles. Always deploy the build result, not the source folder.

━━━━━━━━━━━━━━━━━━━━
▶ 2. DEPLOY TO THE ABAP REPOSITORY (ON-PREMISE / PRIVATE CLOUD)

Fiori tools: "npx fiori add deploy-config" → target ABAP; creates ui5-deploy.yaml with system URL, BSP application name (e.g. ZPURCHREQ), package and transport request.
"npm run deploy" uploads the build as a BSP application (the backend program /UI5/UI5_REPOSITORY_LOAD offers an alternative upload).
The app is in a package and transport — move it to QAS/PRD with the transport, like ABAP objects.
Also transport: the OData service/binding, roles, launchpad content.

━━━━━━━━━━━━━━━━━━━━
▶ 3. DEPLOY TO SAP BTP (CLOUD FOUNDRY)

Fiori tools: deploy config for Cloud Foundry creates an MTA (mta.yaml) with the HTML5 app, the HTML5 app repository and (managed) approuter configuration.
Build the MTA (mbt build) and deploy (cf deploy) — or "npm run deploy".
Backend access through BTP destinations (to S/4HANA via Cloud Connector for on-premise).
Content appears in SAP Build Work Zone / launchpad service.

━━━━━━━━━━━━━━━━━━━━
▶ 4. LAUNCHPAD INTEGRATION

Semantic object + action (e.g. PurchaseRequest-manage) in the app's manifest "crossNavigation" inbound.
On ABAP: a tile and target mapping in a catalog; the catalog in a business role; spaces and pages for layout. In S/4HANA Cloud / BTP: business catalogs/roles and Work Zone content.
Users see the tile only if they have the role — and they also need the OData service authorization.

━━━━━━━━━━━━━━━━━━━━
▶ 5. VERSIONS AND LIFECYCLE

Increase the app version in manifest.json ("sap.app" → "applicationVersion") with each release.
Clear caches after deployment where needed (e.g. /UI5/APP_INDEX_CALCULATE on ABAP for app index, browser cache busting via versioned resources).
Keep deploy configurations in the repository; use CI/CD pipelines for BTP and consistent transport handling for ABAP.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Run "npx fiori add deploy-config" and choose ABAP.
Enter system, BSP name ZPURCHREQ, package and transport.
"npm run deploy"; check the BSP application in the backend.
Create tile/target mapping and add it to a role; test with a test user.

✅ CHECKPOINT: your app is deployed and reachable from the launchpad. SAPUI5 series complete.

Code example

ABAP Code

# ===== ABAP deployment: ui5-deploy.yaml (generated by Fiori tools, simplified) =====specVersion: "3.0"metadata:  name: zpurchreqtype: applicationbuilder:  customTasks:    - name: deploy-to-abap      afterTask: generateCachebusterInfo      configuration:        target:          url: https://s4dev.example.com:44300          client: "100"        app:          name: ZPURCHREQ              # BSP application name          description: Purchase Requests          package: ZPR_UI          transport: S4DK900123         # transport request for QAS/PRD        exclude:          - /test/ # ===== Commands =====# npx fiori add deploy-config          -> choose ABAP or Cloud Foundry# npm run build                          -> dist/ (minified, preload)# npm run deploy                         -> upload to ABAP repository / BTP # ===== BTP (Cloud Foundry) =====# mta.yaml: html5 app module + html5 repo host + (managed) approuter# mbt build   -> mta_archives/zpurchreq_1.0.0.mtar# cf deploy mta_archives/zpurchreq_1.0.0.mtar # ===== manifest.json: launchpad inbound =====# "sap.app": {#   "applicationVersion": { "version": "1.2.0" },#   "crossNavigation": {#     "inbounds": {#       "manage": { "semanticObject": "PurchaseRequest", "action": "manage",#                   "title": "Manage Purchase Requests", "signature": { "parameters": {} } }#     }#   }# } # ===== Go-live checklist =====# [ ] app deployed & transported      [ ] OData service published in QAS/PRD# [ ] tile + target mapping + catalog [ ] business role assigned# [ ] service authorization           [ ] caches / app index refreshed

Real project scenario

A team deployed their app to QAS by re-running "npm run deploy" against the QAS system from a developer laptop. A week later, PRD contained a different app version than QAS, and nobody could say which code was live.
They switched to the standard process: deploy only to DEV with a transport request, move the BSP application with the OData service, roles and launchpad content in the same transport route, and bump applicationVersion for every release. Releases became traceable, and the "wrong version in PRD" incidents stopped.

Common mistakes

Deploying the source folder instead of the build result.
Deploying directly to QAS/PRD from a laptop.
Forgetting tiles, target mappings, catalogs and roles.
Forgetting service authorization for users.
Not increasing the app version.
Missing cache/app-index refresh after deployment.

Best practices

Keep deploy configuration in the repository.
Deploy to DEV only; transport (ABAP) or pipeline (BTP) further.
Transport app, service, roles and launchpad content together.
Version every release in manifest.json.
Use a go-live checklist and test with a real business role.

Interview angle

Questions: "How do you deploy a Fiori app to an ABAP system?", "What is needed for users to see the app?", "How does BTP deployment differ?"
Strong answer: build with ui5 build, deploy via Fiori tools deploy config (ui5-deploy.yaml: system, BSP name, package, transport) to the ABAP repository, then transport; on BTP build an MTA with HTML5 app repository and approuter and deploy with cf deploy; launchpad needs an inbound (semantic object/action), tile and target mapping in a catalog within a role, plus service authorization; version apps and refresh caches.

Practice this lesson

Quick check

1. How should an app reach QAS and PRD in an ABAP landscape?

2. Which deployment practice causes version confusion between systems?

3. What must exist for users to start a deployed app from the Fiori launchpad?

Interview questions

1. How do you deploy a Fiori app to production, and what must be in place for users to see it?

Answer it in your own words first, then compare.

2. QAS and PRD run different versions of the same Fiori app. How did this happen and how do you prevent it?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.