Target Mapping

Chaque navigation dans le SAP Fiori Launchpad est une demande d'intent, pas d'une application précise. La résolution se déroule en cinq étapes :

1. Une tile, un lien ou une autre application déclenche un intent : un semantic object plus une action, avec éventuellement des paramètres comme un numéro de document.
2. Le launchpad collecte tous les target mappings mis à la disposition de l'utilisateur par les catalogues de ses rôles.
3. Le launchpad filtre ces target mappings par semantic object, action, type de terminal et règles de paramètres.
4. Le target mapping correspondant fournit la cible : le type d'application, le composant applicatif ou la transaction, et l'alias système.
5. Le launchpad démarre cette cible et lui transmet les paramètres.

Si aucun target mapping ne subsiste à l'étape 3, l'utilisateur obtient une erreur de navigation au lieu d'une application. Un target mapping est donc une règle de routage évaluée à l'exécution, et non un élément d'interface.

Le même intent peut porter des cibles différentes selon les types de terminaux ou les rôles : c'est ainsi qu'une tile peut ouvrir une application complète sur desktop et une application simplifiée sur téléphone. Chaque champ d'un target mapping restreint ou réoriente l'endroit où aboutit un intent.

Une tile est le point d'entrée visuel qui stocke un intent ; un target mapping est la règle qui résout cet intent. Ce sont deux objets distincts, souvent définis ensemble mais parfois dans des technical catalogs différents. Pour qu'un clic ouvre une application, l'utilisateur doit avoir accès aux deux — à la tile via les catalogues qui la placent, et au target mapping via des catalogues de ses rôles. Un target mapping peut servir de nombreuses tiles et de nombreux liens dans les applications, et une tile peut être résolue différemment selon le terminal. Les tiles décident de ce que voient les utilisateurs ; les target mappings décident de ce qui s'ouvre réellement.

Créez ou modifiez un target mapping lorsque :

• une application SAPUI5 spécifique doit pouvoir être lancée depuis le SAP Fiori Launchpad ;
• une transaction SAP GUI ou une application Web Dynpro ABAP sans application SAP Fiori native a besoin d'une tile ;
• un rôle doit ouvrir une autre application pour le même intent, par exemple une application spécifique au lieu de l'application standard ; évitez alors de laisser plusieurs target mappings correspondants dans les rôles d'un même utilisateur, et testez avec /UI2/FLIA.

Évitez deux raccourcis courants :

• copier des target mappings livrés par SAP dans des catalogues spécifiques alors que les référencer maintiendrait le flux des mises à jour SAP, puisque les modifications de l'original sont propagées à ses références ;
• utiliser des actions génériques (wildcards) ou des règles de paramètres ouvertes qui rendent la résolution imprévisible.

Une modification de target mapping est une décision de conception de la navigation et mérite la même revue qu'une modification de rôle.

Une tile visible prouve que l'utilisateur peut voir la tile, pas que l'intent est résolu. Les causes habituelles, par ordre de fréquence selon les praticiens :

1. Le catalogue de la tile est affecté, mais le catalogue du target mapping manque dans les rôles de l'utilisateur.
2. Le target mapping n'est pas activé pour le type de terminal de l'utilisateur : l'application fonctionne sur desktop et échoue sur téléphone.
3. Les règles de paramètres rejettent les paramètres envoyés par la tile ou le lien.
4. L'alias système pointe vers le mauvais back-end.
5. Les caches du launchpad contiennent encore l'ancien contenu après une modification. Sur le serveur front-end ABAP, exécutez le report /UI2/INVALIDATE_GLOBAL_CACHES dans SE38 ou la transaction /UI2/INVAL_CACHES ; SAP réserve /UI2/INVALIDATE_CLIENT_CACHES aux cas exceptionnels.

Exécutez /UI2/FLIA pour l'utilisateur concerné avant de modifier un contenu, car l'analyse des intents montre quels target mappings le launchpad a réellement pris en compte. Les échecs de navigation sont presque toujours des problèmes d'affectation de rôles ou de concordance de règles, pas des applications défectueuses.

• Applications sur SAP BTP : une application déclare ses cibles de navigation comme inbounds dans son app descriptor (manifest.json, sous sap.app → crossNavigation → inbounds). SAP Build Work Zone utilise ces inbounds comme target mappings du site.
• Contenu issu de SAP S/4HANA : le back-end expose des rôles sélectionnés via l'exposition de contenu (content exposure), et SAP Build Work Zone les consomme, le système SAP S/4HANA étant configuré comme fournisseur de contenu.

Le concept est identique quelle que soit l'option de déploiement — un intent en entrée, une application en sortie. Seul l'endroit où la règle est gérée change.