SAP Build Work Zone

SAP Build Work Zone sépare l'origine du contenu et l'endroit où les utilisateurs le voient :

1. Un administrateur souscrit au service dans un subaccount SAP BTP et attribue la role collection Launchpad_Admin aux administrateurs du site.
2. Dans le Channel Manager, les content providers sont enregistrés. Les applications déployées dans le HTML5 application repository du subaccount arrivent par un provider que l'abonnement crée automatiquement ; les systèmes SAP S/4HANA sont ajoutés comme content providers distants.
3. Dans le Content Manager, les administrateurs combinent applications, catalogues, groupes et rôles, issus des providers ou créés localement.
4. Dans le Site Directory, les administrateurs créent les sites et leur attribuent des rôles.
5. Chaque rôle devient une role collection dans SAP BTP, affectée à des utilisateurs ou à des groupes du fournisseur d'identité.

À l'exécution, l'utilisateur ouvre le site, voit les tiles autorisées par ses role collections, et chaque application s'exécute sur son propre back-end. SAP Build Work Zone est une couche d'accès et de composition : il décide de ce que voient les utilisateurs, tandis que les applications continuent de s'exécuter là où elles sont déployées.

Les deux éditions sont consommées sous forme d'abonnements sur SAP BTP, et toutes deux peuvent afficher du contenu SAP S/4HANA fédéré. Les UI integration cards sont prises en charge dans les deux éditions : les cards déclaratives entièrement, tandis que certaines fonctionnalités des component cards ne fonctionnent que dans l'édition advanced et échouent à l'exécution dans l'édition standard. La licence dépend de l'édition et du contrat ; la description de service SAP en vigueur en précise la métrique. Pour un simple launchpad central, l'édition standard de SAP Build Work Zone couvre le besoin ; l'édition advanced relève d'une décision de workplace plutôt que de launchpad.

Le contenu SAP S/4HANA n'est pas reconstruit dans SAP Build Work Zone. Il est fédéré :

1. Exposer dans le back-end. En on-premise et en Private Edition, un administrateur sélectionne les rôles à exposer dans la transaction /UI2/CDM3_EXP_SCOPE (Manage Content for Launchpads on SAP BTP). Les releases récentes prennent aussi en charge les rôles dérivés et composites. En Public Edition, l'exposition passe par un communication arrangement pour le communication scenario SAP_COM_0647.
2. Connecter sur SAP BTP. Des destinations pointent vers le système SAP S/4HANA, et un content provider est créé dans le Channel Manager.
3. Consommer. Les rôles exposés, avec leurs catalogues, tiles et target mappings, apparaissent dans le Content Manager et sont attribués à un site.

Lorsque le contenu back-end change, le provider doit être mis à jour avant que les utilisateurs voient la modification, soit manuellement dans le Channel Manager, soit au moyen de mises à jour automatiques que les administrateurs peuvent configurer pour les providers basés sur ABAP. La fédération de contenu laisse SAP S/4HANA propriétaire de son contenu launchpad, tandis que SAP Build Work Zone le présente de manière centralisée.

• Un point d'entrée pour plusieurs back-ends : un même site peut combiner du contenu provenant de plusieurs systèmes SAP S/4HANA, d'applications SAP BTP et d'applications tierces.
• Réutiliser plutôt que reconstruire : les rôles fédérés apportent les catalogues, tiles et target mappings existants, si bien que la conception du launchpad SAP S/4HANA n'est pas dupliquée.
• Service géré : SAP exploite le runtime du site, de sorte que le point d'entrée central ne dépend pas d'une release de front-end server gérée par le client.
• Thèmes et image de marque : la licence inclut l'UI theme designer, ce qui permet aux sites de suivre la charte graphique de l'entreprise sans code spécifique.
• De la place au-delà des tiles : les cards et, dans l'édition advanced, les workspaces permettent aux équipes de construire des pages d'accueil par rôle autour de leurs applications.

Pour les organisations disposant de plus d'un back-end, SAP Build Work Zone est la manière native SAP d'offrir aux utilisateurs une porte d'entrée unique.

• Il présente les applications ; il ne les exécute pas. Chaque application s'exécute toujours sur son propre back-end, avec les performances, les erreurs et le cycle de releases de ce système.
• Deux niveaux d'autorisation. Un utilisateur a besoin de la role collection sur SAP BTP pour voir une tile et de l'autorisation back-end, gérée par exemple dans PFCG, pour utiliser l'application. SAP Build Work Zone ne remplace pas ce second niveau.
• La fédération est une copie avec un cycle de rafraîchissement. Le site affiche l'état du contenu à la dernière mise à jour du provider : les modifications back-end ne sont donc pas toujours visibles immédiatement.
• Les identités doivent correspondre. L'authentification unique (single sign-on) vers le back-end dépend d'une identité utilisateur cohérente entre SAP BTP et SAP S/4HANA.
• Aucune logique de processus. Un site peut exposer des tâches et des cards, mais l'enchaînement des étapes entre applications et systèmes est défini ailleurs.

Ces limites sont voulues : SAP Build Work Zone optimise l'accès aux applications, pas les processus qui s'exécutent derrière elles.

Vérifiez la chaîne de l'utilisateur jusqu'au back-end dans cet ordre :

1. La role collection est-elle affectée à l'utilisateur, directement ou via un groupe du fournisseur d'identité ?
2. Le rôle est-il attribué au site dans le Site Directory ?
3. Le content provider a-t-il été mis à jour après la dernière modification dans SAP S/4HANA ?
4. Le rôle fait-il partie de l'exposition back-end ?
5. La destination vers le back-end fonctionne-t-elle pour cet utilisateur ?
6. L'utilisateur dispose-t-il de l'autorisation back-end pour l'application ?

Si la tile est visible mais que la navigation échoue, exécutez /UI2/FLIA dans le back-end pour le même utilisateur afin d'analyser l'intent. La plupart des problèmes de visibilité dans SAP Build Work Zone sont des problèmes d'affectation de rôles ou d'exposition, pas des applications défaillantes.