Vue d’ensemble de la migration de modèle de données standard à améliorée

L'utilitaire de migration cli Microsoft Power Platform déplace la configuration prise en charge d'un site Power Pages existant et les enregistrements associés du modèle de données standard vers le modèle de données amélioré, puis bascule le site pour utiliser la configuration migrée.

Le modèle de données standard stocke la configuration du site Power Pages dans des tables qui utilisent le préfixe adx_. Le modèle de données amélioré stocke la configuration du site dans la table composant de site (powerpagecomponent) et identifie chaque composant par son type de composant. Comprendre le fonctionnement de l’utilitaire de migration, les modèles qu’il prend en charge et les personnalisations qu’il ne met pas à jour automatiquement vous aide à déterminer quand et comment déplacer un site.

L’examen des avantages améliorés du modèle de données explique pourquoi vous pouvez envisager de migrer un site.

Il est important de noter que toutes les tables adx_* ne sont pas déplacées vers powerpagecomponent. Seules les tables de métadonnées adx_* — celles qui décrivent la structure et l’interface de création du site, telles que adx_webpage, adx_webtemplate, adx_contentsnippet, adx_sitesetting, adx_pagetemplate, adx_weblink, adx_entityform et adx_entitylist — sont consolidées dans powerpagecomponent (leurs propriétés de chaque ligne étant déplacées dans la colonne JSON du contenu).

Les tables transactionnelles / d’exécution adx_* — celles qui capturent l’activité des utilisateurs finaux à l’exécution, telles que adx_invitation, adx_inviteredemption, adx_portalcomment, adx_externalidentity, ainsi que les tables de soumission et de journalisation des formulaires d’entité / formulaires avancés — ne sont pas migrées vers powerpagecomponent ; elles restent dans leurs schémas existants et continuent de stocker les données d’exécution comme auparavant. Ce qui change pour ces tables transactionnelles, c’est que leurs références aux enregistrements de métadonnées sont redirigées lors de la migration des références afin qu’elles pointent vers les nouvelles lignes powerpagecomponent au lieu des anciennes lignes de métadonnées adx_*.

Les sites existants créés sur le modèle de données standard continuent à s’exécuter sur des tables adx_*, de sorte que chaque site doit être migré pour bénéficier d’un modèle de données amélioré. La migration déplace les métadonnées de configuration du site dans la structure powerpagecomponent du modèle de données amélioré, redirige les références transactionnelles vers ces nouveaux enregistrements de métadonnées et bascule l’enregistrement du site pour qu’il soit servi à partir du modèle de données amélioré. C’est également là que les personnalisations ( colonnes adx_* personnalisées, Liquid qui lit les attributs adx_*, FetchXML sur adx_* tables, plug-ins et workflows) sont exposées et corrigées, car ces personnalisations ne sont pas remplacées automatiquement et doivent être réécrites ou restructurées pour fonctionner sur un modèle de données amélioré.

Prerequisites

Fonctionnalités de l’utilitaire de migration

L’utilitaire de migration copie la configuration de site prise en charge et les enregistrements associés au modèle de données amélioré. Une fois la migration terminée, le site actif bascule vers le modèle de données amélioré et est validé avant de revenir à l’utilisation normale.

Utilitaire de migration :

  • Génère un rapport de personnalisations susceptibles de nécessiter des modifications manuelles.
  • Migre la configuration de site prise en charge et les enregistrements associés.
  • Vous permet de vérifier l’état de la migration avant de changer le modèle de données actif.
  • Vous permet de rétablir le site au modèle de données standard si la validation identifie un problème critique.

Important

L’utilitaire de migration ne met pas automatiquement à jour toutes les personnalisations qui dépendent directement des tables de modèle de données standard. Passez en revue le rapport de personnalisation, corrigez le code personnalisé affecté et testez le site migré avant l’utilisation de la production.

Modèles pris en charge

Vous pouvez migrer des sites de modèle de données standard existants qui ont été créés à partir des modèles suivants :

  • Disposition de démarrage 1-5
  • Traitement de l’application
  • Page vierge
  • Inscription au programme
  • Planifier et gérer les réunions
  • FAQ
  • Portail communauté (Dynamics 365)
  • Portail libre-service client (Dynamics 365)
  • Portail libre-service des employés (Dynamics 365)
  • Portail partenaires (Dynamics 365)

Note

La création de nouveaux sites avec le modèle de données amélioré et la migration de sites existants sont des fonctionnalités distinctes. Si le modèle d’origine d’un site n’est pas répertorié ici, n’exécutez pas l’utilitaire de migration pour ce site.

Avant de commencer

Considérations supplémentaires relatives à la planification :

  • Le paramètre d’environnement Passer au modèle de données amélioré détermine le modèle de données utilisé pour les nouveaux sites. L’activation du paramètre ne migre pas les sites existants.
  • Exécutez d’abord la migration dans une copie complète de l’environnement de production. Effectuez la correction et la validation de la personnalisation avant la migration.
  • Utilisez le processus de sauvegarde et de restauration standard de votre organisation pour sauvegarder l’environnement de production.
  • Planifiez une fenêtre de maintenance pour le commutateur de production final et la validation.
  • Enregistrez l’ID du site web, l’ID du portail, l’URL de l’environnement, la version cli, les versions de package, l’heure de début de la migration et le formulaire de sortie de commande dans le cadre de l’enregistrement de migration.

Planifiez la séquence des environnements

La migration prend en charge différents environnements, avec un mode différent pour chaque environnement.

Environnement Mode recommandé Ce que vous faites
Développement configurationData Migrez la configuration, passez en revue le rapport de personnalisation, corrigez les personnalisations, validez et capturez la configuration dans une solution.
Test ou UAT configurationDataReferences Importez la solution testée à partir du développement, migrez les enregistrements associés pris en charge, activez le modèle de données amélioré et validez.
Production configurationDataReferences Importez la solution managée validée, migrez les enregistrements associés pris en charge, activez pendant la fenêtre de maintenance et effectuez la validation de production.
Environnement unique ou site simple all Migrez la configuration et les enregistrements associés dans une seule opération uniquement lorsque vous comprenez l’impact de la personnalisation et n’utilisez pas le chemin de la solution multienvironment.

Créer un dossier de travail

Utilisez un dossier de travail vide pour contenir des rapports, une source de site téléchargée et des fichiers de comparaison. Les exemples suivants utilisent \<OUTPUT\> pour cet emplacement.

mkdir C:\PowerPagesMigration\<site-name>
cd C:\PowerPagesMigration\<site-name>

Phases de migration

Le processus de migration se compose de quatre phases :

  1. Vérifications préalables : vérifiez le site, les ID, l’interface CLI, les packages, la solution de modèle et l’état de migration.
  2. Configuration : migrez la configuration dans le développement ou l’importation de la configuration testée dans les environnements en aval.
  3. Migrer et activer : migrer les enregistrements associés, confirmer l’achèvement, changer de modèle et redémarrer.
  4. Valider : testez le comportement, les autorisations, le code personnalisé et les parcours de modèle.

Capture d’écran d’un diagramme de flux montrant le processus de migration du modèle de données standard au modèle de données amélioré.

La phase 1 (découverte de sites et pré-vérifications) et la phase 4 (validation post-migration) s’exécutent de la même façon pour chaque site.

Les Phase 2 et Phase 3 sont subdivisées en pistes : leur forme dépend du mode de migration, qui détermine la piste à partir du type d’environnement.

La piste de création (mode configurationData ou all) est utilisée pour les environnements de développement et les configurations à environnement unique. Les métadonnées proprement dites sont migrées localement et les personnalisations sont analysées et corrigées par rapport à la source de modèle de données standard avant le déplacement des références transactionnelles.

Le Downstream Track (mode configurationDataReferences) est utilisé pour les environnements de test, de préproduction (UAT) et de production, où les métadonnées de configuration sont supposées provenir de l’importation d’une solution ALM depuis Dev. Seules les références transactionnelles migrent dans ce parcours. Les constatations liées à la personnalisation indiquent une lacune ALM en amont plutôt qu’un travail à effectuer localement.

Phase 1 : Vérifications préalables

  1. Vérifiez votre version de l’interface CLI Power Platform avec pac --version. Si votre version est antérieure à la version requise, installez ou mettez à jour l’interface CLI Microsoft Power Platform avant de continuer.

  2. Authentifiez-vous auprès de l’environnement cible.

    1. Exécutez pac auth list.
    2. Exécutez pac auth who.

  3. Vérifiez que le profil d’authentification actif pointe vers l’environnement qui contient le site. Pour sélectionner un autre profil ou créer un profil, utilisez pac auth select ou pac auth create -u "https://contoso.crm.dynamics.com".

  4. Installez des solutions de modèle de données améliorées pour votre modèle à l’aide de l’une des méthodes suivantes :

    1. Créez un site à partir de votre modèle avec l’indicateur de modèle de données amélioré (EDM) activé dans le centre d’administration.
    2. Utiliser l’interface CLI pour l’installer avec la commande pac application install --application-name "PowerPages_PartnerPortal_V2"

  5. Recherchez le site et enregistrez ses identificateurs avec pac pages list -v.

  6. Enregistrez les valeurs indiquées dans le tableau suivant.

    Valeur Utilisé pour
    ID du site Web Toutes les migrate-datamodel commandes.
    ID du portail Basculez vers le modèle de données amélioré et revenez au modèle de données standard.
    Nom convivial et URL Confirmez que vous avez sélectionné le site approprié dans le Centre d’administration.
    Version du modèle de données Doit être Standard. S’il est déjà amélioré, la migration n’est pas nécessaire.

    Important

    L'ID du portail n'est pas l'ID d'application Power Pages. Si l’interface de ligne de commande (CLI) n’affiche pas l’ID du portail, il est disponible dans le Centre d’administration Power Platform sous Ressources>Sites Power Pages>, ou ajoutez /_services/about à l’URL du site lorsque vous êtes connecté avec les autorisations d’accès au site web requises.

  7. Recherchez une migration précédente ou en cours avec la commande suivante :

    pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --checkMigrationStatus
    Status Signification Action
    NotStarted ou aucun suivi Aucune migration n’a démarré. Poursuivez avec les vérifications du package.
    Rétabli Une migration précédente a été annulée. Passez en revue la raison pour laquelle elle a été rétablie, puis continuez lorsque vous êtes prêt.
    Terminé La migration s’est terminée, mais le site n’a peut-être pas été basculé. Confirmez le modèle de données actif. S’il est toujours Standard, poursuivez l’activation.
    Exécution en cours La migration est toujours en cours de traitement. Continuez à vérifier l’état. Ne démarrez pas une autre migration pour le même site.
    Échec La migration a rencontré une erreur. Collectez les détails de la sortie de commande et de l’environnement, corrigez la cause et réessayez uniquement une fois l’échec compris.

    Note

    Si une migration reste plus longue que prévu, vous avez besoin de l’ID du site web, de l’ID d’environnement, de la version CLI, des versions de package, de la sortie de commande et de l’heure de début de la migration avant de contacter Microsoft support. Une migration active ne devrait pas être réinitialisée, sauf si le support ou un runbook approuvé le demande.

  8. Vérifiez les packages propriétaires requis avec pac solution list --includeSystemSolutions.

    1. Vérifiez que CDSBasePortal, PowerPages_Core et les solutions EDM du modèle du site sont installés dans les versions requises.

  9. Si un package est manquant ou obsolète, mettez-le à jour à partir du Centre d’administration Power Platform :

    1. Ouvrez l’environnement cible.
    2. Accédez à Resources>Dynamics 365 applications.
    3. Recherchez le package requis.
    4. Sélectionnez Installer ou mettre à niveau.
    5. Attendez que l’opération se termine, puis réexécutez pac solution list --includeSystemSolutions .

    Note

    Si la solution de modèle EDM n’est pas disponible pour une installation directe, le fait de créer un site temporaire de modèle de données amélioré dans le même environnement à partir du même modèle installe la solution EDM correspondante. Vous pouvez supprimer le site temporaire une fois la solution confirmée.

  10. Générez le rapport de personnalisation avec pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --siteCustomizationReportPath "<OUTPUT>". La génération du rapport ne modifie pas le site.

  11. Ouvrez le fichier CSV généré et passez en revue chaque élément qui référence les tables de modèle de données standard. Attribuez un propriétaire et une étape de validation pour chaque correction requise avant la migration de production.

    Catégorie de personnalisation Plan
    Colonnes personnalisées sur les tables de métadonnées adx_ Déplacez les données personnalisées vers une table personnalisée prise en charge associée à powerpagecomponent.
    Relations avec les tables de métadonnées adx_ Recréez la relation par rapport à la table de modèle de données améliorée prise en charge.
    Références Liquid ou FetchXML aux tables adx_ Mettez à jour le code pour utiliser les objets Liquid, les tables virtuelles ou powerpagecomponent pris en charge.
    Flux de travail et plug-ins sur les tables adx_ Refactorisez et inscrivez la logique sur les tables de modèle de données améliorées prises en charge.

    Note

    Un rapport de personnalisation ne prouve pas que tout le comportement du site fonctionne après la migration ; la validation est toujours requise.

  12. Choisissez le mode de migration pour déterminer ce que l’utilitaire migre dans une seule opération.

    Mode Qu’est-ce qu’il migre ? Quand l’utiliser
    données de configuration Métadonnées de configuration de site prises en charge, telles que les pages, les modèles web, les extraits de code, les paramètres, les formulaires, les listes, les rôles web et les autorisations de table. Développement, dans lequel vous corrigez les problèmes de configuration et la faites passer via des solutions.
    références des données de configuration Enregistrements pris en charge relatifs à la configuration du site migré. Test, UAT et production après l’arrivée de la configuration du site via une importation de solution.
    tout Configuration et enregistrements associés pris en charge. Un seul environnement ou une migration simple qui n’utilise pas la séquence d’environnement basée sur la solution.

Phase 2 : Configuration du site

Suivi de création : développement ou environnement unique

  1. Téléchargez une base de référence SDM en exécutant pac pages download --webSiteId "<WEBSITE_ID>" --modelVersion 1 --path "<OUTPUT>\site-sdm". La commande crée un dossier enfant nommé pour le site. Enregistrez le dossier qui contient directement website.yml.

  2. Migrer la configuration du site en exécutant pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --mode configurationData. Si vous souhaitez utiliser le chemin à opération unique, remplacez configurationData par all.

  3. Vérifiez l’état de la migration en exécutant pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --checkMigrationStatus. Utilisez la boucle PowerShell suivante pour vérifier l’état une fois par minute pendant jusqu’à 30 minutes :

    $webSiteId = "<WEBSITE_ID>"
for ($i = 1; $i -le 30; $i++) {
    $output = pac pages migrate-datamodel `
        --webSiteId $webSiteId `
        --checkMigrationStatus 2>&1 | Out-String
    if ($output -match "Completed|Failed|Reverted") {
        Write-Host $output
        break
    }
    Write-Host "Attempt $i/30 - migration is still running."
    Start-Sleep -Seconds 60
}

    Si la boucle se termine alors que le statut est toujours « En cours », la vérification continue avec --checkMigrationStatus. Une opération de longue durée n’est pas nécessairement une opération ayant échoué.

  4. Corrigez les personnalisations signalées à l’aide du rapport de personnalisation et des conseils de cet article pour mettre à jour fetchXML, Liquid, colonnes personnalisées, relations, flux de travail et plug-ins affectés. Testez à nouveau chaque composant modifié. Si vous mettez à jour la source téléchargée, chargez le dossier de site qui contient website.yml directement en exécutant pac pages upload --path "<OUTPUT>\site-sdm\<site-slug>" --modelVersion 1.

Branche en aval : tests, UAT ou production

  1. Importez la solution qui contient la configuration de site migrée et corrigée. Utilisez le Centre d’administration Power Platform ou votre pipeline de déploiement établi.

    pac solution import --path "<PATH_TO_SOLUTION_ZIP>" --activate-plugins true --publish-changes true

  2. Vérifiez que la configuration du site est présente en ouvrant l’application de gestion Power Pages dans l’environnement cible. L’enregistrement du site et la configuration attendue doivent être présents avant la migration des enregistrements connexes.

  1. Migrez les enregistrements associés pris en charge. Si vous avez déjà utilisé --mode all, ignorez cette étape. Vérifiez l’état jusqu’à ce qu’il signale Terminé.

    pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --mode configurationDataReferences
pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --checkMigrationStatus

  2. Une fois que l’état de la migration indique que celle-ci est terminée avec succès, basculez le site actif vers le modèle de données amélioré. L’enregistrement de site web du modèle de données standard est désactivé et l’enregistrement de site web du modèle de données amélioré correspondant devient actif.

    pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --updateDatamodelVersion --portalId "<PORTAL_ID>"

  3. Redémarrez le site.

    1. Ouvrez le Centre d’administration Power Platform.
    2. Accédez à l’environnement, puis sélectionnez Ressources>Power Pages sites.
    3. Sélectionnez le site.
    4. Sélectionnez Redémarrer. Si le redémarrage n’est pas disponible, désactivez puis activez le site.
    5. Attendez que l’opération se termine avant la validation.

  4. Confirmez le modèle de données actif à l’aide d’une ou plusieurs de ces méthodes :

    1. Dans le Centre d’administration Power Platform, sélectionnez le site et vérifiez que le modèle de données affiche Amélioré.
    2. Ouvrez l'espace de travail d'installation du site dans Power Pages studio de conception et confirmez le modèle de données affiché.
    3. Vérifiez que la configuration avancée s’ouvre dans l’application gestion des Power Pages.
    4. Exécutez pac pages list -v et confirmez la version du modèle de données.

    Tip

    L’URL du site et la conception visuelle ne changent pas simplement parce que le modèle de données actif a changé. Pour vérifier la migration, utilisez ces vérifications, et non l’apparence du site.

Phase 4 : Valider le site migré

Effectuez la validation avant de rouvrir un site de production aux utilisateurs. Utilisez des comptes de test pour chaque type d’utilisateur et rôle web important, puis enregistrez le résultat de chaque test critique.

Domaine Éléments à valider
Pages et contenu Page d’accueil, pages de contenu représentatives, modèles web, extraits de contenu, fichiers web, navigation, redirections et contenu multilingue.
Authentication Connectez-vous, déconnectez-vous, inscrivez, invitations, fournisseurs d’identité externes et accès refusé.
Authorization Les rôles web, les autorisations de table, les autorisations de colonne et les règles d’accès aux pages autorisent et refusent les actions attendues.
Formulaires et listes Formulaires de base, formulaires à plusieurs étapes, listes, métadonnées de formulaire, soumissions, enregistrements connexes et sessions de formulaires web utilisées par le site.
modèles de parcours Dynamics 365 Le client, l’employé, la communauté ou les parcours partenaires principaux utilisés par votre implémentation, y compris les pages spécifiques au modèle et les modèles d’accès.
Code personnalisé Liquid, FetchXML, JavaScript, plug-ins, workflows et intégrations identifiés dans le rapport de personnalisation.
Paramètres et fichiers du site Les paramètres de site, les images, les pièces jointes, les fichiers SVG et d’autres fichiers web se chargent correctement.
Données et références Les nombres d’enregistrements importants et les enregistrements associés pris en charge renvoient aux composants appropriés du site migré.
Administration et ALM Le site s’ouvre dans Power Pages Management et peut être ajouté à, exporté et importé à partir de solutions comme prévu.

Vérifier les diagnostics du navigateur

Ouvrez les outils de développement du navigateur lors du test des pages représentatives. Enquêter :

  • Erreurs de console qui mentionnent adx\_, entités, Liquid ou FetchXML.
  • Réponses HTTP 401 ou 403 provenant de \_api, qui peuvent indiquer un problème d’autorisation ou de rôle web.
  • Les réponses HTTP 500, qui peuvent indiquer une défaillance de Liquid, de FetchXML, d’un plug-in ou d’une intégration.

Critères d’achèvement de la migration

Considérez la migration comme terminée uniquement lorsque le site affiche le modèle de données amélioré, que les parcours métier critiques sont validés, que le comportement de sécurité attendu a été confirmé et que chaque constat relatif à une personnalisation à fort impact a été résolu ou accepté.

Séquence de migration de production

Utilisez la séquence de production suivante pour réduire les risques de migration :

  1. Créez une copie complète de l’environnement de production pour la répétition.
  2. Confirmez les prérequis de l’interface CLI, du package et du modèle de solution dans l’environnement copié.
  3. Générez et passez en revue le rapport de personnalisation.
  4. Migrez la configuration dans l’environnement de développement copié.
  5. Corrigez les personnalisations et capturez la configuration de site validée dans une solution managée.
  6. Importez la solution dans l’environnement de répétition, migrez les enregistrements associés pris en charge, activez le modèle de données amélioré et terminez la liste de contrôle de validation complète.
  7. Répétez la remédiation et les essais jusqu’à ce que tous les tests critiques soient concluants.
  8. Planifiez la fenêtre de maintenance de production, communiquez les points de décision de validation et de restauration, puis sauvegardez la production.
  9. Vérifiez à nouveau les prérequis du package de production et de la solution de modèle.
  10. Importez la solution managée validée en production.
  11. Exécutez, vérifiez l’état de la migration, changez configurationDataReferencesle modèle de données actif et redémarrez le site.
  12. Exécutez la liste de contrôle de validation de production et renvoyez le site à une utilisation normale uniquement après la réussite des tests critiques.

Rétablir un site migré vers le modèle de données standard

Si la validation identifie un problème critique après l’activation, utilisez la commande suivante pour réactiver l’enregistrement du site web du modèle de données standard :

pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --revertToStandardDataModel --portalId "<PORTAL_ID>"

Une fois la commande terminée :

  1. Redémarrez le site à partir du Centre d’administration Power Platform.
  2. Vérifiez que le site affiche Standard comme modèle de données actif.
  3. Réexécutez les tests de validation critiques du site.
  4. Conservez le rapport de migration, les détails des erreurs et les notes de correction avant de tenter une autre migration.

Important

Planifiez la décision de retour arrière avant la migration en production. Passez en revue les modifications apportées après le changement de modèle de données amélioré avant de rétablir, car les enregistrements de site web standard et améliorés sont des enregistrements distincts.

Résolution des problèmes

Message ou symptôme Cause probable Action
pac powerpages migrate-datamodel n’est pas reconnu La commande utilise l’espace de noms incorrect ou une interface CLI obsolète. Mettez à jour l’interface CLI Power Platform et utilisez pac pages migrate-datamodel.
CDSBasePortal ou PowerPages_Core n’est pas répertorié Les solutions système n’ont pas été incluses dans la sortie de commande, ou le package n’est pas installé. Exécutez pac solution list --includeSystemSolutions. Installez ou mettez à niveau le package manquant à partir du Centre d’administration Power Platform.
Site web non pris en charge pour la migration Le modèle d’origine n’est pas pris en charge, les versions de package sont insuffisantes ou la solution de modèle EDM correspondante est manquante. Vérifiez l’éligibilité du modèle, les versions de package et la solution EDM répertoriée dans la référence de la solution de modèle.
Un argument --webSiteId inconnu a été passé pour pac pages upload La commande de chargement n’accepte pas l’argument ID du site web. Omettez l’argument. Le site est identifié à partir de website.yml.
Le chargement cible le mauvais site ou ne parvient pas à trouver le site Le chemin pointe vers le dossier wrapper au lieu du dossier de site. Utilisez le dossier enfant qui contient directement website.yml.
L’ID du portail s’affiche Unknown ou N/A Le site est inactif ou l’interface CLI installée ne retourne pas la valeur. Obtenez l’ID du portail à partir du Centre d’administration Power Platform ou de la page du /_services/about site. N’utilisez pas l’ID d’application.
La migration indique Completed, mais le site affiche toujours Standard Le modèle de données actif n’a pas été basculé ou l’ID de portail incorrect a été utilisé. Exécutez la commande d’activation avec l’ID du site web et l’ID du portail correct, puis redémarrez et vérifiez le site.
L’état demeure Running La migration traite un grand volume de données ou est bloquée. Continuez à vérifier l’état. Collectez l’environnement, le package, l’interface CLI, l’heure de début et les détails de la commande avant de contacter le support technique. Ne démarrez pas une deuxième migration.
L’état est Failed Une erreur de package, de modèle, de personnalisation, de données ou de service a arrêté l’opération. Enregistrez la sortie de la commande complète, corrigez la cause identifiée et réessayez uniquement après avoir examiné l’état de migration ayant échoué.
Le site s’ouvre, mais les utilisateurs ne peuvent pas accéder aux données attendues Les rôles web, les autorisations de table ou les requêtes personnalisées ne se comportent pas comme prévu après la migration. Passez en revue les rôles web, les autorisations de table, les autorisations de colonne, FetchXML, Liquid et les erreurs réseau du navigateur.

Considérations relatives aux personnalisations de site

Le rapport de personnalisation identifie les dépendances directes sur les tables de modèle de données standard. Effectuez la correction requise avant l’utilisation de la production.

Colonnes personnalisées sur des tables de métadonnées

Si une table de modèle de données standard telle que adx_webpage contient une colonne personnalisée, créez une table personnalisée pour stocker les données personnalisées et ajoutez une recherche à powerpagecomponent. Migrez les valeurs personnalisées vers la nouvelle table et mettez à jour le code qui lit ou écrit la colonne.

Relations entre les tables personnalisées et les tables de métadonnées

Recréez les relations personnalisées qui pointent vers les tables adx_ afin qu’elles pointent vers la table appropriée du modèle de données amélioré, généralement powerpagecomponent. Mettez à jour les formulaires dépendants, les vues, les plug-ins, les flux et les intégrations.

Références liquides aux tables de métadonnées

Remplacez l’accès direct entities['adx_*'] par un objet Liquid pris en charge lorsqu’un tel objet existe. Par exemple, utilisez l’objet Liquid weblinks au lieu d’interroger directement adx_weblinkset ou les tables associées. Passez en revue chaque utilisation, car l’objet retourné et les attributs disponibles peuvent différer.

Références FetchXML aux tables de métadonnées

Remplacez les références d’entité directe adx_ par la table virtuelle ou la requête powerpagecomponent correspondante et filtrez par powerpagecomponenttype

Exemple de modèle de données standard :

<fetch>
  <entity name="adx_webpage">
    <attribute name="adx_name" />
    <filter>
      <condition attribute="adx_partialurl" operator="eq" value="home" />
    </filter>
  </entity>
</fetch>

Exemple de modèle de données amélioré :

<fetch>
  <entity name="powerpagecomponent">
    <attribute name="name" />
    <filter type="and">
      <condition attribute="powerpagecomponenttype" operator="eq" value="2" />
      <condition attribute="partialurl" operator="eq" value="home" />
    </filter>
  </entity>
</fetch>

Flux de travail et plug-ins personnalisés

Remanier un workflow personnalisé et une logique de module complémentaire inscrits sur les tables adx_. Inscrivez la logique mise à jour sur la table de modèle de données améliorée appropriée et utilisez le schéma et les attributs améliorés. Testez le comportement de création, de mise à jour, de suppression et de sécurité dans un environnement hors production.

Référence de commande

Purpose Commande
Vérifier la version de l’interface CLI pac --version
Répertorier les profils d’authentification pac auth list
Créer un profil d’authentification pac auth create -u "<ENV_URL>"
Répertorier les sites et les identificateurs pac pages list -v
Répertorier les solutions système pac solution list --includeSystemSolutions
Vérifier l’état de la migration pac pages migrate-datamodel --webSiteId "<ID>" --checkMigrationStatus
Télécharger la source SDM pac pages download --webSiteId "<ID>" --modelVersion 1 --path "<OUT>\site-sdm"
Télécharger la source EDM pac pages download --webSiteId "<ID>" --modelVersion 2 --path "<OUT>\site-edm"
Générer un rapport de personnalisation pac pages migrate-datamodel --webSiteId "<ID>" --siteCustomizationReportPath "<OUT>"
Migrer une configuration pac pages migrate-datamodel --webSiteId "<ID>" --mode configurationData
Migrer des enregistrements associés pac pages migrate-datamodel --webSiteId "<ID>" --mode configurationDataReferences
Migrer les deux catégories pac pages migrate-datamodel --webSiteId "<ID>" --mode all
Charger la source du site pac pages upload --path "<SITE_ROOT>" --modelVersion 1
Activer EDM pac pages migrate-datamodel --webSiteId "<ID>" --updateDatamodelVersion --portalId "<PORTAL_ID>"
Revenir à SDM pac pages migrate-datamodel --webSiteId "<ID>" --revertToStandardDataModel --portalId "<PORTAL_ID>"

Informations de référence sur le type de composant de site

Lorsque vous interrogez powerpagecomponent, utilisez les valeurs suivantes dans le filtre powerpagecomponenttype .

Component Valeur Component Valeur
État de publication 1 Page web 2
Fichier web 3 Ensemble de liens Web 4
Lien Web 5 Modèle de page 6
Extrait de contenu 7 Modèle web 8
Paramètre du site 9 Règle du contrôle d’accès de la page Web 10
Rôle web 11 Accès au site Web 12
Marqueur de site 13 Formulaire de base 15
Métadonnées de formulaire de base 16 Liste 17
Autorisation de table 18 Formulaire avancé 19
Étape de formulaire avancé 20 Métadonnées de formulaire avancé Vingt-et-un
Positionnement de sondage 24 Placement publicitaire 26
Utilisateur de bot 27 Profil d’autorisation de colonne 28
Autorisation de colonne 29 Rediriger 30
Règle de transition de l’état de publication 31 Shortcut 32
Flux de cloud 33 Composant UX 34

Informations de référence sur la solution de modèle EDM

Exécutez pac solution list --includeSystemSolutions pour vérifier que la solution de modèle de données améliorée pour le modèle du site est installée.

Modèle Nom unique de la solution EDM
Disposition de démarrage 1 DefaultPortalTemplate_V2
Disposition de démarrage 2 PowerPages_BlankDesign002_V2
Disposition de démarrage 3 PowerPages_BlankDesign003_V2
Disposition de démarrage 4 PowerPages_BlankDesign004_V2
Disposition de démarrage 5 PowerPages_BlankDesign005_V2
Page vierge PowerPages_BlankTemplate_V2
FAQ PowerPages_FAQ_V2
Traitement de l’application PowerPages_BuildingPermit_V2
Inscription au programme PowerPages_ProgramRegistration_V2
Planifier et gérer les réunions PowerPages_BookMeeting_V2
Portail communauté (Dynamics 365) PowerPages_CommunityPortal_V2
Portail libre-service client (Dynamics 365) PowerPages_CustomerPortal_V2
Portail libre-service des employés (Dynamics 365) PowerPages_ESSPortal_V2
Portail partenaires (Dynamics 365) PowerPages_PartnerPortal_V2

Contenu connexe

  • Last updated on