SAPUI5 Launchpad Integration: Tiles and Target Mappings

From Standalone App to Launchpad Tile

An SAPUI5 app running on its own URL is only half the story in an S/4HANA or BTP landscape. Users expect it on the Fiori Launchpad: a tile in a group, single sign-on, and navigation that survives bookmarks. That integration rests on two pieces — the tile and the target mapping.

The good news: your app barely changes. The launchpad does the heavy lifting through configuration, not code.

---

Target Mappings: The Navigation Contract

A target mapping connects an intent — a semantic object plus action, like SalesOrder-manage — to your app's URL. When a tile or a cross-app link fires that intent, the launchpad resolves it to your app and passes parameters along.

The intent is the public address of your app. Tiles, bookmarks, and other apps all navigate to the intent, never to the raw URL.

In the launchpad designer (or the Fiori Launchpad content manager in newer releases), you create the target mapping with three essentials:

• Semantic Object / Action: e.g. SalesOrder + manage. Keep the naming consistent with your domain.
• Application URL: the deployed path of your app on the ABAP repository or HTML5 repo.
• Application ID / component name: used to resolve the app and its dependencies.

---

Tiles: Static and Dynamic

Static tiles show a fixed title, icon, and subtitle. They take minutes to configure and suit apps where the tile itself carries no live data.

Dynamic tiles call your OData service to display a number — open orders, pending approvals — refreshed on an interval you set. They need a service URL and a refresh interval in the tile configuration, plus the OData annotations or a simple value binding the launchpad understands.

// dynamic tile config essentials
{
  "serviceUrl": "/sap/opu/odata/sap/ZORDER_SRV/",
  "serviceRefreshInterval": 300,
  "numberValue": "{OpenOrders}"
}

Say you have an approval app: a dynamic tile showing the pending count turns the launchpad into a to-do list. That's often the difference between an app that gets used and one that gets forgotten.

---

What Your App Must Do

Very little, but these matter:

• Read startup parameters: the launchpad passes intent parameters into your app. Grab them in Component.js via this.getComponentData().startupParameters.
• Handle the back button: inside the launchpad, browser-back should return to the launchpad, not exit the browser. Use sap.m.routing history handling or the CrossApplicationNavigation service.
• Declare dependencies: your manifest's sap.ui5/dependencies must list the libraries the launchpad needs to load.

// Component.js - reading startup params
init: function () {
  UIComponent.prototype.init.apply(this, arguments);
  var oParams = this.getComponentData().startupParameters;
  var sOrderId = oParams && oParams.orderId && oParams.orderId[0];
  this.getRouter().initialize(sOrderId);
}

Test your app inside the launchpad sandbox early. Apps that work standalone but ignore startup parameters or back-button behavior feel broken in the launchpad.

---

Final Take

Launchpad integration is configuration with a small code surface: a target mapping for the intent, a tile for the entry point, and startup-parameter handling in your component. Get those three right and your app feels native to the Fiori world.

Static or dynamic tiles — which do your users actually click? Drop your experience in the comments.