Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Power Pages prend en charge l’intégration du code d’application monopage (SPA) créé avec des outils d’intelligence artificielle (IA) de nouvelle génération, comme GitHub Copilot. Cette fonctionnalité permet aux développeurs d’apporter des expériences front-end modernes basées sur des composants dans Power Pages à l’aide du langage naturel comme interface de codage.
En guidant, testant et affinant le code généré par l’IA, les créateurs peuvent changer leur focus des tâches d’implémentation répétitives à l’orchestration de niveau supérieur. Cette approche permet un développement plus intuitif et créatif tout en conservant la qualité et les normes de qualité de l’entreprise.
Cet article vous montre comment :
- Créez et configurez un projet SPA pour Power Pages à l’aide de l’interface CLI Power Platform CLI (PAC CLI).
- Chargez et téléchargez des ressources de code vers et depuis votre site Power Pages.
- Mettez en place une structure de projet sécurisée et facile à maintenir.
- Découvrez les principales différences entre les implémentations Power Pages basées sur SPA et celles traditionnelles.
Note
- Un site SPA est un site Power Pages qui s'exécute entièrement dans le navigateur de l'utilisateur (rendu côté client). Contrairement aux sites de Power Pages traditionnels, vous gérez uniquement les sites SPA via le code source et les outils d’interface de ligne de commande (CLI).
- L’intégration Git de Power Platform n’est pas prise en charge pour les sites web Single-Page Application (SPA) dans Power Pages.
Prerequisites
Avant de commencer, assurez-vous d’avoir :
- Environnement Power Pages avec des privilèges admin.
- Power Platform CLI (PAC CLI) version 1.44.x ou ultérieure installée et authentifiée.
- Un site Power Pages version 9.7.4.x ou ultérieure.
- Autoriser les chargements de fichiers JavaScript dans les environnements Dataverse.
- Dépôt Git local avec votre projet frontal personnalisé, tel que React, Angular ou Vue.
Autoriser les chargements de fichiers JavaScript
Par défaut, certains environnements Dataverse bloquent le chargement de fichiers JavaScript (.js). Si vous rencontrez l’erreur « Échec de l’importation : la pièce jointe n’est pas un type valide ou est trop volumineuse. Il ne peut pas être chargé ou téléchargé. » mettez à jour vos paramètres d’environnement pour autoriser ce type de fichier.
Pour ajuster les paramètres dans le centre d’administration Power Platform pour un environnement, procédez comme suit :
- Connectez-vous au Centre d’administration Power Platform.
- Dans le volet de navigation, sélectionnez Gérer.
- Dans le volet Gérer, sélectionnez Environnements.
- Sélectionnez un environnement.
- Dans la barre de commandes, sélectionnez Paramètres.
- Développez Produit, puis sélectionnez Confidentialité + Sécurité.
- Dans la section Pièces jointes bloquées , supprimez
jsde la liste des extensions de fichier. - Cliquez sur Enregistrer.
Créer et déployer un site SPA
Les sites SPA Power Pages sont gérés à l’aide des commandes PAC CLI upload-code-site et download-code-site. Après avoir chargé un site, il apparaît dans Power Pages dans la liste Inactive sites. Activez le site pour le mettre à la disposition des utilisateurs.
Charger un site SPA
Utilisez la commande pac pages upload-code-site pour charger votre source locale et vos ressources compilées dans votre environnement de Power Pages.
Syntax
pac pages upload-code-site `
--rootPath <local-source-folder> `
[--compiledPath <build-output-folder>] `
[--siteName <site-display-name>]
Parameters
| Paramètre | Alias | Obligatoire | Description |
|---|---|---|---|
--rootPath |
-rp |
Oui | Dossier local contenant les fichiers sources de votre site |
--compiledPath |
-cp |
Non | Chemin d’accès aux actifs compilés, comme React build |
--siteName |
-sn |
Non | Nom d'affichage de votre site Power Pages |
Exemple
pac pages upload-code-site `
--rootPath "../your-project" `
--compiledPath "./build" `
--siteName "Contoso Code Site"
Si vous n’avez pas de projet existant, essayez les exemples d’implémentations de sites SPA à l’aide de React, Angular et Vue.
Définition des paramètres de chargement avec powerpages.config.json
Personnalisez le comportement de la upload-code-site commande en incluant un powerpages.config.json fichier dans le dossier racine de votre site. Lorsque ce fichier est présent, exécutez upload-code-site avec uniquement le paramètre --rootPath. La commande lit les valeurs restantes du fichier de configuration. Si vous fournissez des arguments de ligne de commande et des valeurs de configuration, les arguments de ligne de commande sont prioritaires.
Champs de configuration
| Champ | Type | Obligatoire | Description |
|---|---|---|---|
siteName |
string | Oui | Nom d’affichage du site Power Pages. |
compiledPath |
string | Oui | Chemin d’accès au répertoire de sortie compilé (par exemple, le dossier Vite dist ou React build ), par rapport à powerpages.config.json. |
defaultLandingPage |
string | Oui | Page HTML servie lorsque la racine du site est ouverte, par rapport à compiledPath (généralement index.html). |
bundleFilePatterns |
chaîne de caractères[] | Non | Liste de modèles de caractères génériques identifiant les fichiers du dossier web-files du site que l’interface CLI supprime avant de charger la nouvelle build. Utilisez ce champ pour supprimer les bundles obsolètes dont le nom inclut un hachage de contenu, afin d’éviter l’accumulation d’anciennes ressources sur le site. Consultez le fractionnement du code et le nettoyage de bundle. |
includeSource |
booléen | Non | Quand true, la commande charge votre code source en plus des ressources compilées. La valeur par défaut est false. |
sourceExcludePatterns |
chaîne de caractères[] | Non | Modèles génériques pour les fichiers sources à exclure du chargement. S’applique uniquement lorsque includeSource est true (par exemple, pour ignorer node_modules ou les fichiers d’environnement locaux). |
Pour obtenir la référence des champs la plus précise et la plus à jour, consultez le powerpages.config.json schéma. Ajoutez la propriété correspondante $schema à votre fichier de configuration pour activer la validation et la saisie semi-automatique dans les éditeurs qui prennent en charge le schéma JSON.
Exemple de powerpages.config.json
{
"$schema": "https://www.schemastore.org/powerpages.config.json",
"siteName": "Contoso Bank",
"compiledPath": "dist",
"defaultLandingPage": "index.html",
"bundleFilePatterns": [
"index-*.js",
"index-*.css"
]
}
Télécharger un site SPA
Utilisez la commande pac pages download-code-site pour télécharger le code d’un site existant dans un répertoire local à des fins de modification ou de sauvegarde.
Syntax
pac pages download-code-site `
[--environment <env-url-or-guid>] `
--path <local-target-folder> `
--webSiteId <site-guid> `
[--overwrite]
Parameters
| Paramètre | Alias | Obligatoire | Description |
|---|---|---|---|
--environment |
-env |
Non | Environnement Dataverse (GUID ou URL complète). Par défaut, il s’agit de votre profil d’authentification actif |
--path |
-p |
Oui | Répertoire local pour télécharger le code du site |
--webSiteId |
-id |
Oui | Enregistrement GUID du site web SPA Power Pages |
--overwrite |
-o |
Non | Remplacer les fichiers existants dans le répertoire cible s’ils existent |
Exemple
pac pages download-code-site `
--environment "https://contoso.crm.dynamics.com" `
--path "./downloaded-site" `
--webSiteId "11112222-bbbb-3333-cccc-4444dddd5555" `
--overwrite
Activer et tester votre site
- Accédez à Power Pages.
- Sélectionnez Sites inactifs, recherchez votre site et sélectionnez Réactiver.
- Lorsque le site est actif, accédez à l’URL de votre site pour vérifier le déploiement.
Conseil / Astuce
Toute commande upload-code-site ultérieure met automatiquement à jour le site actif.
Structure et configuration du projet
Une disposition de projet cohérente aide à garantir un comportement de chargement correct.
/your-project
│
├─ src/ ← Your source code, like React components
├─ build/ ← Compiled assets, output of the `npm run build` command
├─ powerpages.config.json ← Optional CLI configuration file
└─ README.md
Utilisez le fichier powerpages.config.json facultatif pour personnaliser le fonctionnement de la commande upload-code-site.
Fractionnement du code et nettoyage de bundle
À mesure qu’une application à page unique se développe, un bundle JavaScript unique devient volumineux et lent à charger. Les outils de génération modernes résolvent ce problème avec le fractionnement du code. Cette technique décompose l’application en blocs plus petits que le navigateur télécharge à la demande (par exemple, uniquement lorsque l’utilisateur accède à un itinéraire spécifique). Chaque bloc est émis avec un hachage de contenu dans son nom de fichier, par exemple, afin que Dashboard-BSbmIXoe.jsles navigateurs puissent le mettre en cache pendant de longues périodes et le télécharger à nouveau uniquement lorsque son contenu change.
Le fractionnement du code introduit une considération de déploiement unique pour Power Pages sites SPA : étant donné que chaque build produit de nouveaux noms de fichiers hachés, des exécutions répétées upload-code-site laisseraient les anciens fichiers hachés derrière eux sur le site. Au fil des déploiements, ces fragments orphelins s’accumulent dans le web-files du site. Le bundleFilePatterns champ dans powerpages.config.json existe pour les nettoyer.
Activer le fractionnement de code
Le fractionnement du code est géré par votre outil de génération front-end, et non par Power Pages, de sorte que l’approche dépend de l’infrastructure et du bundler que vous utilisez. La technique la plus courante consiste à charger des parties de l’application avec des importations dynamiques, souvent appliquées au niveau de l’itinéraire ou de la vue afin que chaque section télécharge uniquement lorsqu’un utilisateur y accède (chargement différé).
Les bundlers tels que Vite, webpack et esbuild peuvent également regrouper des modules en segments nommés explicitement. Pour obtenir la configuration exacte, consultez la documentation de votre framework et de votre bundler.
dist/assets/
├─ index-BJltBIP-.js ← app entry
├─ index-DMwMk7hv.css ← styles
├─ Dashboard-BSbmIXoe.js ← lazy route chunk
├─ InvoiceList-DwjrGrAI.js ← lazy route chunk
└─ InvoiceDetail-D3DVGkeM.js← lazy route chunk
Quelle que soit l’approche choisie, le résultat est le même, et c’est la partie qui importe pour le déploiement : la build émet plusieurs fichiers de sortie, chacun avec un hachage de contenu dans son nom. Étant donné que ces hachages changent chaque fois que le contenu d’un fichier change, chaque build produit un ensemble différent de noms de fichiers. Les sections suivantes expliquent comment nettoyer vos environnements Dataverse à mesure que ces noms changent.
Comment upload-code-site nettoie les packages obsolètes
Avant de téléverser vos ressources compilées, upload-code-site supprime chaque fichier dans le web-files du site qui correspond à un motif générique dans bundleFilePatterns, puis téléverse la version compilée actuelle. Ce comportement de suppression puis de chargement conserve le jeu de fichiers déployé identique à votre dernière sortie compilée au lieu de calquer chaque build au-dessus de la précédente.
Pour que le nettoyage fonctionne, les modèles génériques dans bundleFilePatterns devront correspondre aux noms de fichiers émis par votre build. Il existe deux façons de les conserver exactement, en fonction de la façon dont votre outil de génération nomme les fichiers.
Option 1 : Lister directement les motifs génériques
De nombreux outils de build conservent un préfixe de nom stable et modifient uniquement le hachage du contenu, comme index-[hash].js. Lorsque vos noms de fichiers de sortie suivent un schéma prévisible comme celui-ci, indiquez dans bundleFilePatterns un motif générique pour chacun d’eux. Aucun outil supplémentaire n’est nécessaire :
{
"$schema": "https://www.schemastore.org/powerpages.config.json",
"siteName": "Contoso Bank",
"compiledPath": "dist",
"defaultLandingPage": "index.html",
"bundleFilePatterns": [
"index-*.js",
"index-*.css"
]
}
Un modèle générique tel que index-*.js correspond à ce fichier sur chaque build, quel que soit le hachage. Ajoutez une entrée par fichier de sortie et ajoutez un nouveau modèle chaque fois que votre build commence à produire un nouveau fichier de sortie.
Option 2 : Générer des modèles génériques avec un script post-build
Utilisez cette approche lorsque vos noms de fichiers de sortie ne suivent pas de modèle prévisible, ou lorsque votre application produit de nombreux fichiers dont les noms changent lorsque vous ajoutez et supprimez des itinéraires, ce qui rend une liste gérée manuellement sujette aux erreurs. Un petit script qui s’exécute après la compilation parcourt le résultat compilé et remplace bundleFilePatterns par un motif générique pour chaque fichier généré. Par exemple, lorsqu’un outil de génération nomme les fichiers selon le format [name]-[hash].[ext], le script réduit Dashboard-BSbmIXoe.js au motif Dashboard-*.js.
scripts/postbuild.js :
#!/usr/bin/env node
/**
* Post-build script: scans dist/assets/ and updates powerpages.config.json
* with bundleFilePatterns that match all Vite-generated chunks.
*
* This ensures `pac pages upload-code-site` cleans up old hashed bundles
* on each deploy instead of accumulating stale files.
*
* Usage: node scripts/postbuild.js
* Or via npm: "postbuild": "node scripts/postbuild.js" in package.json
*/
import { readdirSync, readFileSync, writeFileSync } from 'fs'
import { join } from 'path'
const ROOT = join(import.meta.dirname, '..')
const DIST_ASSETS = join(ROOT, 'dist', 'assets')
const CONFIG_PATH = join(ROOT, 'powerpages.config.json')
// Vite output format: [name]-[hash].[ext]
// We want to extract "name" and "ext" to produce "name-*.ext" patterns
const HASH_PATTERN = /^(.+)-[A-Za-z0-9_-]{6,12}\.(js|css)$/
try {
const files = readdirSync(DIST_ASSETS)
const patternSet = new Set()
for (const file of files) {
const match = file.match(HASH_PATTERN)
if (match) {
const [, baseName, ext] = match
patternSet.add(`${baseName}-*.${ext}`)
}
}
const patterns = [...patternSet].sort()
if (patterns.length === 0) {
console.log('No hashed bundles found in dist/assets/ — skipping config update.')
process.exit(0)
}
// Read current config
const config = JSON.parse(readFileSync(CONFIG_PATH, 'utf-8'))
const oldPatterns = config.bundleFilePatterns || []
// Check if update is needed
const oldSet = new Set(oldPatterns)
const newSet = new Set(patterns)
const changed = oldSet.size !== newSet.size || [...newSet].some(p => !oldSet.has(p))
if (!changed) {
console.log(`bundleFilePatterns already up-to-date (${patterns.length} patterns).`)
process.exit(0)
}
// Update config
config.bundleFilePatterns = patterns
writeFileSync(CONFIG_PATH, JSON.stringify(config, null, 2) + '\n', 'utf-8')
console.log(`Updated powerpages.config.json with ${patterns.length} bundle patterns:`)
for (const p of patterns) {
console.log(` ${p}`)
}
} catch (err) {
console.error('postbuild error:', err.message)
process.exit(1)
}
Connectez le script à votre build pour qu’il s’exécute toujours après le bundler :
{
"scripts": {
"build": "tsc -b && vite build && node scripts/postbuild.js"
}
}
Désormais, un déploiement se fait en deux commandes, et le site n’accumule jamais de chunks orphelins :
npm run build
pac pages upload-code-site --rootPath .
Après la génération, powerpages.config.json reflète les bundles actuels exacts, par exemple :
{
"$schema": "https://www.schemastore.org/powerpages.config.json",
"siteName": "Contoso Bank",
"compiledPath": "dist",
"defaultLandingPage": "index.html",
"bundleFilePatterns": [
"Dashboard-*.js",
"InvoiceDetail-*.js",
"InvoiceList-*.js",
"index-*.css",
"index-*.js"
]
}
Authentification et autorisation
Les sites Power Pages SPA utilisent le même modèle de sécurité que les sites Power Pages traditionnels.
Configurer les fournisseurs d’identité
- Accédez à Power Pages.
- Recherchez votre site et sélectionnez Modifier.
- SélectionnezSécurité>Fournisseurs d'identité.
- Ajoutez ou configurez des fournisseurs identity, comme Microsoft Entra ID.
- Chaque nouveau site a automatiquement un fournisseur de Microsoft Entra ID par défaut.
Accéder au contexte utilisateur dans le code
Obtenir les métadonnées d’authentification sur le client :
URL d’autorité :
L’URL de connexion ou d’autorité pour Microsoft Entra ID est la suivante :
https://login.windows.net/<tenantId>Recherchez l'URL d'autorité Authority pour d'autres fournisseurs d'identité configurés en allant dans Power Pages>
<your site>>Security>paramètres de configuration des fournisseurs d'identité>.Détails sur l’utilisateur :
window["Microsoft"].Dynamic365.Portal.User
Exemple de flux React
import { IconButton, Tooltip } from '@mui/material';
import {
Login,
Logout
} from '@mui/icons-material';
import React from 'react';
export const AuthButton = () => {
const username = (window as any)["Microsoft"]?.Dynamic365?.Portal?.User?.userName ?? "";
const firstName = (window as any)["Microsoft"]?.Dynamic365?.Portal?.User?.firstName ?? "";
const lastName = (window as any)["Microsoft"]?.Dynamic365?.Portal?.User?.lastName ?? "";
const tenantId = (window as any)["Microsoft"]?.Dynamic365?.Portal?.tenant ?? "";
const isAuthenticated = username !== "";
const [token, setToken] = React.useState<string>("");
React.useEffect(() => {
const fetchAntiForgeryToken = async (): Promise<string> => {
try {
const tokenEndpoint = "/_layout/tokenhtml";
const response = await fetch(tokenEndpoint, {});
if (response.status !== 200) {
throw new Error(`Failed to fetch token: ${response.status}`);
}
const tokenResponse = await response.text();
const valueString = 'value="';
const terminalString = '" />';
const valueIndex = tokenResponse.indexOf(valueString);
if (valueIndex === -1) {
throw new Error('Token not found in response');
}
const requestVerificationToken = tokenResponse.substring(
valueIndex + valueString.length,
tokenResponse.indexOf(terminalString, valueIndex)
);
return requestVerificationToken || '';
} catch (error) {
console.warn('[Impersonation] Failed to fetch anti-forgery token:', error);
return '';
}
};
const getToken = async () => {
try {
const token = await fetchAntiForgeryToken();
setToken(token);
} catch (error) {
console.error('Error fetching token:', error);
}
};
getToken();
}, []);
return (
<div className="flex items-center gap-4">
{isAuthenticated ? (
<>
<span className="text-sm">Welcome {firstName + " " + lastName}</span>
<Tooltip title="Logout">
<IconButton color="primary" onClick={() => window.location.href = "/Account/Login/LogOff?returnUrl=%2F"}>
<Logout />
</IconButton>
</Tooltip>
</>
) : (
<form action="/Account/Login/ExternalLogin" method="post">
<input name="__RequestVerificationToken" type="hidden" value={token} />
<Tooltip title="Login">
<IconButton name="provider" type="submit" color="primary" value={`https://login.windows.net/${tenantId}/`}>
<Login />
</IconButton>
</Tooltip>
</form>
)}
</div>
);
};
Utiliser les API web Power Pages
Les développeurs peuvent utiliser Power Pages API web pour charger du contenu dans l’interface utilisateur ou pour créer, mettre à jour et supprimer des enregistrements. Avant d’utiliser ces API, vérifiez que les API web requises sont activées et que les autorisations de table appropriées et les rôles web sont correctement configurés.
// Create query to get all cards from Dataverse
const fetchCards = async () => {
const response = await fetch("/_api/cr7ae_creditcardses");
const data = await response.json();
const cards = data.value;
const returnData = [];
// Loop through the cards and get the name and id of each card
for (let i = 0; i < cards.length; i++) {
const card = cards[i];
const cardName = card.cr7ae_name;
const cardId = card.cr7ae_creditcardsid;
const features = card.cr7ae_features
?.split(',')
.map((feature: string) => feature.trim());
const type = card.cr7ae_type;
const image = card.cr7ae_image;
const category = card.cr7ae_category
?.split(',')
.map((cat: string) => cat.trim());
// ...additional processing/pushing to returnData...
}
return returnData;
};
Configurer le développement local en activant les appels d’API web à partir de localhost à l’aide de l’authentification Microsoft Entra ID
Les développeurs ont besoin de cycles d’itération plus rapides, de débogage local et de fonctionnalités de rechargement à chaud lors de la création d’applications. SPA prend en charge ces flux de travail en activant des appels d’API web sécurisés à partir de localhost à l’aide de l’authentification Microsoft Entra ID (Azure AD) v1.
Cette configuration vous permet de :
- Exécutez votre application localement avec prise en charge complète de l’authentification.
- Utilisez des outils de développement modernes comme Vite pour un rechargement chaud et des commentaires rapides.
- Évitez les problèmes CORS lors de l’appel des API web Power Pages.
- Accélérez le développement sans déployer de modifications sur le portail.
Cette configuration permet une expérience de développement local productive pour SPA, afin que les développeurs puissent créer, tester et itérer rapidement avec l’accès complet aux API et la prise en charge de l’authentification.
Important
- Utilisez uniquement les points de terminaison Microsoft Entra v1 pour l’authentification.
- L’authentification du porteur est prise en charge uniquement dans les versions du portail 9.7.6.6 ou ultérieures.
- Appliquez ces paramètres uniquement dans les environnements de développement.
Étapes de configuration
Activer l’authentification SPA
- Dans Azure portail, ouvrez l’application Microsoft Entra inscrite pour votre portail.
- Activer l’authentification Application à page unique (SPA).
- Ajoutez
localhostcomme URI de redirection en utilisant la configuration de plateforme Application monopage. Pour plus d’informations, consultez Comment ajouter un URI de redirection dans votre application.-
URI de redirection :
http://localhost:<port>/.
-
URI de redirection :
Ajouter des paramètres de site
- Ajoutez ces paramètres de site dans Power Pages :
Authentication/BearerAuthentication/Enabled = true Authentication/BearerAuthentication/Protocol = OpenIdConnect Authentication/BearerAuthentication/Provider = AzureADUtiliser ADAL.js pour l’authentification
- Implémentez l’authentification côté client à l’aide deADAL.js.
Note
MSAL.js n’est pas compatible, car Power Pages utilise des points de terminaison Microsoft Entra v1, tandis que MSAL utilise v2. Le format de l’émetteur diffère entre les versions.
Ajouter un en-tête d’autorisation
- Incluez cet en-tête dans toutes les demandes d’API web :
Authorization: Bearer <id_token>Définir la visibilité du site sur Public
- Ce paramètre permet
localhostd’accéder au site à des fins de développement et de test.
- Ce paramètre permet
Configurer le proxy de développement
- Si vous utilisez Vite, ajoutez ce code dans
vite.config.jspour éviter les problèmes de CORS :
export default defineConfig({ plugins: [react()], server: { proxy: { '/_api': { target: 'https://site-foo.powerappsportals.com', changeOrigin: true, secure: true } } } });- Si vous utilisez Vite, ajoutez ce code dans
Différences entre les sites Power Pages existants
Le tableau suivant résume les principales différences entre les sites SPA créés avec cette fonctionnalité et les sites de Power Pages traditionnels :
| Fonctionnalité | Comportement du site SPA |
|---|---|
| Actualisation côté serveur | Retourne toujours la page racine du site et le routeur côté client affiche les sous-itinéraires. |
| Conflits de routage | Les routes côté client sont prioritaires et une actualisation matérielle revient à la racine. |
| Espace de travail Page | L’espace de travail Pages n’est pas pris en charge. Utiliser le routage client et les pages de site client. Pour la sécurité au niveau de la page, vérifiez les rôles Web attribués avec l’objet utilisateur global et effectuez un rendu conditionnel de l’interface utilisateur. |
| Espace de travail Style | L’utilisation de style avec l’espace de travail Style n’est pas prise en charge. Utilisez le style de votre framework, tel que CSS, CSS-in-JSou les classes utilitaires. |
| Localisation | Prise en charge d’une seule langue. Implémentez le chargement des ressources côté client. |
| Modèles Liquid | Le code Liquid et les modèles Liquid ne sont pas pris en charge. Accédez aux données à l’aide du moteur de modèle et des API web de votre framework. |
FAQ
Quel support est disponible pour les tests unitaires et d’intégration ?
Actuellement, il n’y a pas de prise en charge intégrée pour les tests unitaires et d’intégration. Les créateurs doivent écrire et exécuter ces tests localement ou au sein de leurs pipelines CI/CD.
L’intégration de Power Fx à l’aide de WebAssembly est-elle prise en charge ?
Cette fonctionnalité n’est pas actuellement prise en charge.
Le code source est-il disponible dans Power Pages ?
Actuellement, les créateurs peuvent créer des sites web à l’aide de TypeScript ou GitHub Copilot Agent. Les fichiers JavaScript et CSS compilés sont accessibles et peuvent être modifiés dans Visual Studio Code. Cependant, l’édition directe et étendue des fichiers HTML n’est actuellement pas prise en charge.
Puis-je créer un composant en externe à l’aide de cette fonctionnalité et l’apporter à un site Power Pages ?
Non, vous ne pouvez pas apporter un composant généré en externe à un site Power Pages existant à l'aide de cette fonctionnalité.
Puis-je ajouter des composants prêts à l’emploi, comme des listes et des formulaires ?
L’ajout de composants prêts à l’emploi, tels que des listes et des formulaires, n’est actuellement pas pris en charge. Toutefois, vous pouvez créer des formulaires et des listes personnalisés à l’aide de l’infrastructure React et des API web.
Puis-je configurer un site SPA comme PWA à partir de l’espace de travail Configuration ?
Non. Les sites SPA ne prennent pas en charge le paramètre d’application web progressive (PWA) dans la configuration de l’espace de travail. Cette limitation signifie que vous ne pouvez pas utiliser la section Mobile pour activer un site en tant que PWA. Pour ajouter des fonctionnalités PWA, telles que des expériences d’application installables et des pages hors connexion, implémentez-les dans votre code d’infrastructure. Par exemple, ajoutez un manifeste d’application Web et un service worker.
Comment fonctionne le contrôle de code source ?
Les développeurs peuvent utiliser l’intégration Git de Power Platform pour le contrôle de code source. Cependant, seuls les fichiers web compilés sont ajoutés au référentiel, pas le code source complet.
Ces sites prennent-ils en charge le référencement ?
Étant donné que les sites SPA sont construits avec le framework React et utilisent le rendu côté client, la prise en charge du référencement est limitée.
Quel support en matière de sécurité et de gouvernance les Power Pages offrent-ils aux sites SPA ?
Power Pages applique les autorisations de table et les rôles web de sécurité sur les appels d’API web, ce qui garantit que l’accès aux données s’aligne sur les rôles d’utilisateur. Utilisez l’objet window["Microsoft"].Dynamic365.Portal.User pour récupérer les propriétés de base de l’utilisateur et personnaliser les expériences en fonction des rôles des utilisateurs.
De plus, les sites SPA prennent en charge :
- Configurations de site public et privé
- Paramètres de gouvernance, y compris le contrôle de l’accès anonyme aux données
- Configurations de fournisseur d’authentification
Ces fonctionnalités permettent de garantir l’intégration sécurisée et conforme des composants personnalisés dans Power Pages.