SAP Deployment
Deploying Fiori apps makes them available to users on the launchpad, whether standard apps you activate or custom apps you build and transport. Deployment differs for embedded versus hub and for on-premise versus cloud.
Deploying a custom Fiori app means building it in Business Application Studio, deploying to the ABAP repository or to BTP for side-by-side apps, creating the tile and target mapping in a catalog, assigning catalog and group to roles with the backend authorisations, then transporting through DEV, QAS and PRD and verifying tile, app and OData service at each stage.
- Watch out: Deploying but not registering the tile/catalog.
Deploying custom apps
A custom UI5 app is built and then deployed to the front-end server (as a BSP application in on-premise, via ABAP repository and transport) or to BTP for side-by-side apps. It is then registered in the launchpad (catalog/tile) and assigned to roles so users can reach it.
Embedded vs hub deployment
In embedded deployments the app and launchpad live on the S/4HANA system; in hub deployments they live on a separate front-end server. This affects where you deploy, how you transport, and how frontend/backend roles are split.
The steps
- Build the app (BAS) and deploy to the target (ABAP repo / BTP).
- Create the Fiori app configuration (tile, target mapping) in a catalog.
- Assign catalog/group to roles; grant backend authorizations.
- Transport through DEV → QAS → PRD and verify at each stage.
Verify
Confirm the tile appears for the right role, the app opens, and its OData service works, in each system as the transport progresses. Deployment issues usually surface as missing tiles or inactive services in the target.
Common pitfalls
- Deploying but not registering the tile/catalog.
- Frontend deployed, backend service not activated in the target.
- Skipping verification per landscape stage.