Semantic Object

Un semantic object est le substantif de la navigation SAP Fiori ; l'action en est le verbe. Ensemble, ils forment un intent, écrit dans l'URL du launchpad sous la forme #SemanticObject-action, éventuellement suivi de paramètres.

1. Une tile, un lien ou une application demande un intent, par exemple #PurchaseOrder-display?PurchaseOrder=4500000123.
2. Le launchpad recherche des target mappings ayant le même semantic object et la même action parmi les catalogues des rôles de l'utilisateur.
3. Le target mapping correspondant détermine quelle application s'ouvre.

Un semantic object porte généralement de nombreuses actions. Dans la SAP Fiori Apps Reference Library, PurchaseOrder-display est résolu vers la transaction classique ME23N via SAP GUI for HTML, PurchaseOrder-manage vers l'application Manage Purchase Orders et PurchaseOrder-displayFactSheet vers une fact sheet de commande d'achat. L'application appelante ne nomme que le business object et l'opération voulue. Un semantic object est donc un nom stable pour une entité métier, indépendant de la technologie d'interface qui la prendra finalement en charge.

• Launchpad basé sur ABAP (on-premise, Private Edition) : SAP livre les semantic objects avec les composants d'interface ; la transaction /UI2/SEMOBJ_SAP les affiche. Les semantic objects spécifiques sont créés avec /UI2/SEMOBJ ou avec l'activité de Customizing dédiée aux semantic objects spécifiques dans SPRO (UI Technologies, SAP Fiori, contenu du launchpad). Une entrée spécifique ayant la même clé qu'une entrée livrée par SAP en remplace les attributs.
• SAP BTP et SAP Build Work Zone : chaque application déclare les semantic objects et les actions qu'elle accepte comme inbounds dans son app descriptor (sap.app → crossNavigation → inbounds), où le semantic object et l'action sont obligatoires. Les semantic objects proviennent de ces descripteurs plutôt que d'une transaction de maintenance ABAP.
• SAP S/4HANA Cloud Public Edition : les semantic objects livrés par SAP sont utilisés tels quels. Pour une application spécifique, le développeur définit la tile, y compris son intent, dans le cadre de l'application avant de la déployer.

Le semantic object est défini une fois par paysage système, puis référencé partout où la navigation en a besoin.

Les semantic objects ne servent pas qu'aux tiles. Dans SAP Fiori elements, un champ annoté avec un semantic object (Common.SemanticObject en OData ou CAP, @Consumption.semanticObject en ABAP CDS) est rendu sous forme de lien lorsque le semantic object est valide dans le launchpad. Un clic sur ce lien liste toutes les actions que l'utilisateur peut atteindre pour cet objet ; lorsqu'une seule cible existe, l'application navigue directement.

Les applications SAPUI5 freestyle utilisent le service de navigation du shell (sap.ushell.services.Navigation) pour savoir quels liens existent pour un semantic object et pour naviguer. Dans les deux cas, la liste des liens est calculée par utilisateur à partir des target mappings de ses rôles : deux utilisateurs qui cliquent sur le même champ fournisseur peuvent donc voir des options différentes.

Un semantic object sur un champ est une demande d'options de navigation, et les rôles de l'utilisateur décident des options qui apparaissent.

Appliquez ce critère de décision : l'entité existe-t-elle déjà en tant que business object SAP ?

• Réutilisez le semantic object SAP lorsqu'une application spécifique travaille sur la même entité, par exemple une application spécifique de validation des commandes d'achat chez Alder Manufacturing. Réutiliser PurchaseOrder permet à l'application spécifique d'apparaître dans les mêmes listes de liens que les applications standard et de recevoir la navigation depuis celles-ci. Ajoutez une action distincte plutôt qu'un nouveau semantic object.
• Créez un semantic object spécifique lorsque l'entité n'a pas d'équivalent SAP, comme une demande d'outillage spécifique qui n'existe que dans l'extension d'Alder Manufacturing. Respectez les conventions de nommage convenues pour le paysage système.
• N'en créez pas un par application. Un semantic object nommé d'après une application plutôt que d'après une entité fragmente la navigation et masque l'application spécifique des liens standard.

Un semantic object spécifique se justifie par une nouvelle entité métier, pas par une nouvelle application.

1. Écarts d'orthographe et de casse. SAP décrit les target mappings comme sensibles à la casse : une tile qui envoie PurchaseOrder peut donc ne pas être résolue face à un target mapping défini pour Purchaseorder. Copiez les semantic objects depuis leur définition au lieu de les saisir.
2. Attendre d'un semantic object qu'il accorde un accès. Un semantic object ne porte aucune autorisation. L'accès provient des catalogues des rôles de l'utilisateur, qui contiennent les target mappings de ce semantic object.
3. Supposer qu'un lien signifie une application. Les smart links n'apparaissent que pour les cibles que l'utilisateur peut atteindre. Un lien visible pour un key user peut ne pas apparaître pour un employé administratif, et c'est voulu.
4. Remplacer à la légère des semantic objects livrés par SAP. Une entrée spécifique ayant la même clé modifie les attributs pour toutes les applications qui utilisent l'objet.

Lorsque la navigation d'un semantic object se comporte de façon inattendue, exécutez /UI2/FLIA pour l'utilisateur et l'intent concernés avant de modifier une définition. La plupart des problèmes de semantic objects sont des problèmes de nommage ou de rôles plutôt que de définition.