Navigation basée sur les intents

Dans le SAP Fiori Launchpad, la partie de l'URL située après # est un intent, pas l'adresse d'une application. Un intent typique ressemble à #PurchaseOrder-display?PurchaseOrder=4500000123.

1. L'utilisateur clique sur une tile ou un lien, ou une application déclenche la navigation dans le code. Chacun ne nomme que le semantic object, l'action et d'éventuels paramètres.
2. Le launchpad vérifie quels intents l'utilisateur peut utiliser. Sur le launchpad ABAP, ils proviennent des catalogues des rôles PFCG de l'utilisateur.
3. La résolution de cible du launchpad compare l'intent aux target mappings disponibles, y compris les règles de type de terminal et de paramètres.
4. Le target mapping retenu fournit l'application : un composant SAPUI5, une transaction SAP GUI for HTML, une application Web Dynpro ABAP ou une URL, ainsi que le système sur lequel elle s'exécute.
5. Le launchpad lance la cible et transmet les paramètres.

L'appelant ne sait jamais quelle application a répondu. La navigation basée sur les intents est un contrat à liaison tardive entre ce que l'utilisateur veut faire et l'application qui le fait.

Cette indirection résout de vrais problèmes de cycle de vie :

• Cibles propres à chaque rôle. Le même intent peut ouvrir une vue manager pour un rôle et une vue gestionnaire pour un autre, uniquement par configuration.
• Cibles propres à chaque terminal. Un utilisateur sur poste de travail et un utilisateur sur téléphone peuvent atteindre des applications différentes par le même lien.
• Applications remplaçables. Un intent peut pointer aujourd'hui vers une application Web Dynpro ABAP et plus tard vers une nouvelle application SAPUI5, sans modifier les applications qui y renvoient.
• Déploiement indépendant. Les applications ont des cycles de vie différents ; une application source ne peut pas supposer qu'une application cible est installée. Les intents laissent le launchpad décider de ce qui existe pour cet utilisateur, dans ce système.
• Extension sans modification. Les clients peuvent rediriger un intent standard vers une application spécifique sans toucher au code SAP.

Ce sont ces propriétés qui expliquent pourquoi les applications SAP Fiori se relient entre elles par des intents plutôt que par des adresses codées en dur. La navigation basée sur les intents échange un léger effort de configuration contre des applications qui peuvent évoluer indépendamment.

• SAP Fiori elements : les champs annotés avec un semantic object deviennent des smart links, et la navigation sortante est déclarée via des annotations et l'app descriptor. Le framework appelle le launchpad pour le compte du développeur.
• App descriptor : sap.app → crossNavigation déclare les inbounds (les intents qu'une application accepte, avec des règles de paramètres, par exemple le traitement des paramètres supplémentaires : autorisés, ignorés ou non autorisés) et les outbounds (les intents qu'une application peut déclencher).
• SAPUI5 freestyle : le service shell sap.ushell.services.Navigation propose des méthodes asynchrones pour naviguer, construire un lien, vérifier si un intent est pris en charge pour l'utilisateur et lister les liens d'un semantic object. L'ancien service CrossApplicationNavigation est obsolète depuis SAPUI5 1.120.

Les développeurs doivent vérifier qu'un intent est pris en charge avant d'afficher un lien, car la prise en charge varie selon l'utilisateur. Dans le code, la navigation basée sur les intents est une requête adressée au launchpad, jamais un appel direct à une autre application.

• Elle exige un runtime de launchpad ou de site. Les intents sont résolus par le shell. SAP indique que le service Navigation fonctionne dans le périmètre du launchpad courant ; une application ouverte seule, hors du launchpad ou d'un site SAP Build Work Zone, ne dispose donc d'aucun service pour les résoudre.
• Les erreurs apparaissent à l'exécution. Un target mapping manquant ou un mauvais rôle se manifeste lorsqu'un utilisateur clique, pas lors du transport du contenu ; les tests par rôle sont donc importants.
• Les paramètres transitent dans l'URL. Les sélections volumineuses nécessitent un app state plutôt que des paramètres d'URL, et les valeurs sensibles ne doivent pas figurer dans un intent.
• Les cibles inter-systèmes dépendent de la configuration. Une cible dans un autre système repose sur un alias système ou une destination corrects.
• La navigation n'est pas un état de processus. Un intent ouvre une application avec un contexte ; il n'enregistre pas ce que l'utilisateur fait ensuite, si une tâche est terminée ni ce qui vient après.

Ces limites découlent de la conception : la navigation basée sur les intents détermine où aller, et laisse à l'application cible ce qui s'y passe.

Sur le launchpad ABAP, suivez les éléments factuels plutôt que de commencer par modifier le contenu :

1. Relevez l'intent dans la barre d'adresse du navigateur ou dans le message de la console.
2. Si la console affiche un ID de journal d'application, ouvrez le journal d'application UI2 dans SLG1 ; depuis le message, vous pouvez accéder à l'analyse des intents.
3. Exécutez /UI2/FLIA avec l'intent, le type de terminal et l'utilisateur concerné. La transaction indique quels rôles et catalogues portent l'intent et quel target mapping lui correspond.
4. Si le target mapping est correct mais que l'application se charge dans le mauvais système, vérifiez les alias système avec /UI2/FSAC.
5. Si un composant SAPUI5 ne peut pas être chargé, vérifiez le journal de l'index des applications SAPUI5 avec /UI5/APP_INDEX_CALCULATE.

Sur SAP BTP, comparez l'intent de la tile avec les inbounds de l'app descriptor déployé. Un intent en échec relève généralement d'un problème de contenu ou de rôle, et les outils de la navigation basée sur les intents indiquent lequel avant toute modification.

La syntaxe et le principe sont les mêmes ; seule la source des target mappings change. Les applications déployées sur SAP BTP déclarent leurs inbounds dans l'app descriptor, et SAP Build Work Zone traite ces inbounds comme les cibles du site. Les applications de SAP S/4HANA atteignent un site Work Zone via la Federation of Remote Content Providers, qui expose le contenu du launchpad back-end au site. Quelle que soit l'option de déploiement, la navigation basée sur les intents conserve le même contrat : un intent entre, et le contenu de l'utilisateur décide quelle application en sort.