Trois conseils pour ajouter un site sans tête dans XM Cloud / Blogs / Perficient

Introduction 📖

Dans cet article, j’aborderai trois conseils que les développeurs devraient prendre en compte lors du déploiement d’un nouveau site sans tête sur XM Cloud. Ayant récemment ajouté un nouveau site sans tête à une solution existante, j’ai rencontré quelques problèmes. J’espère sauver d’autres personnes de maux de tête similaires à l’avenir (principalement moi-même 😉). Si vous avez récemment ajouté un nouveau site sans tête à votre solution XM Cloud et que vous rencontrez des difficultés pour que le site apparaisse et fonctionne correctement, veuillez continuer à lire 👇.

1. Vérifiez l’élément de démarrage du nouveau site 🚩

Après avoir déployé votre nouveau site, si vous remarquez que le site n’apparaît pas sur le Sites page de destination dans XM Cloud (https://xmapps.sitecorecloud.io/?tab=tools&tenantName=&organization=), vérifiez que le site Élément de départ le champ est défini. Ce champ se trouve sur le site Regroupement de sites élément dont le chemin est (généralement) le suivant :

/sitecore/content/<site_collection>/<site>/Settings/Site Grouping/<site>

De plus, assurez-vous que l’élément référencé est physiquement présent dans l’arborescence du contenu. Si le Élément de départ n’est pas présent, le site n’apparaîtra pas dans XM Cloud.

Dans mon cas particulier, j’avais initialement mal configuré la sérialisation pour le nouveau site et exclu par inadvertance le nom du nouveau site. Maison article. Le Élément de départ Le champ était défini, mais il ne pointait vers rien dans l’environnement cible, donc mon nouveau site n’apparaissait pas dans XM Cloud 🤦‍♂️.

2. Vérifiez les éléments de l’hôte de rendu 🤖

Si votre nouveau site apparaît dans XM Cloud mais que vous ne pouvez ouvrir aucune page dans Experience Editor ou Preview, il se peut que quelque chose ne fonctionne pas avec les éléments de l’hôte de rendu.

Chaque solution XM Cloud comprend un xmcloud.build.json fichier dans le répertoire racine. Il s’agit du fichier de configuration de build XM Cloud ; il contrôle la manière dont XM Cloud crée et déploie la solution. Ce fichier contient une liste des hôtes de rendu que XM Cloud doit provisionner et démarrer dans le cadre d’un déploiement. Les hôtes de rendu (également parfois appelés « hôtes d’édition » dans le contexte d’un CM) sont nécessaires pour piloter les fonctionnalités d’éditeur d’expérience et d’aperçu de Sitecore. Le xmcloud.build.json le fichier est assez important et utile ; pour plus d’informations sur ce fichier et ce qu’il peut faire, veuillez vous référer à la documentation officielle ici : https://doc.sitecore.com/xmc/en/developers/xm-cloud/the-xm-cloud-build-configuration.html.

Il devrait y avoir une entrée dans le renderingHosts propriété du xmcloud.build.json fichier pour chaque application sans tête distincte de votre solution. Notez cependant qu’il est possible d’exécuter multiple sites sans tête avec une seule application principale utilisant le module complémentaire multisite JSS. Pour plus d’informations sur les avantages et les inconvénients de l’une ou l’autre approche, consultez cet article du développeur Sitecore : https://developers.sitecore.com/learn/accelerate/xm-cloud/pre-development/project-architecture/multisite#web-application.

Pour les besoins de cette astuce, supposons qu’il existe deux sites sans tête, chacun avec sa propre application Next.js sans tête exécutant différentes versions de Node (ce qui implique également la nécessité de deux hôtes de rendu distincts : un hôte de rendu ne peut pas exécuter plusieurs versions. de Node/Next.js). Disons que xmcloud.build.json le fichier ressemble à ceci :

{
    "renderingHosts": {
        "mysite1": {
            "path": "./src/rendering-mysite1",
            "nodeVersion": "16.15.1",
            "jssDeploymentSecret":"<redacted>",
            "enabled": true,
            "type": "sxa",
            "lintCommand": "lint",
            "startCommand": "start:production"
        },
        "mysite2": {
          "path": "./src/rendering-mysite2",
          "nodeVersion": "20.14.0",
          "jssDeploymentSecret":"<redacted>",
          "enabled": true,
          "type": "sxa",
          "lintCommand": "lint",
          "startCommand": "start:production"
      }
    },
    ...

Lorsque XM Cloud exécute un déploiement, il lit le xmcloud.build.json fichier, parcourt le renderingHosts propriété et approvisionne les conteneurs concernés en coulisses. Une fois le déploiement terminé, les éléments de l’hôte de rendu dans l’arborescence de contenu sont créés et/ou mis à jour sous ce dossier :

/sitecore/system/Settings/Services/Rendering Hosts

Les éléments de l’hôte de rendu dans ce dossier sont mappés aux hôtes de rendu énumérés dans le xmcloud.build.json déposer.

Une chose intéressante à noter est que, quel que soit le nom du premier hôte de rendu, le xmcloud.build.json fichier (par exemple, monsite1 dans l’exemple ci-dessus), le d’abord hôte de rendu dans le xmcloud.build.json Le fichier sera toujours créé dans l’arborescence de contenu de Sitecore avec un nom de Défaut. Les hôtes de rendu N+1 auront les noms répertoriés dans le xmcloud.build.json déposer. Par exemple (encore une fois, en supposant que xmcloud.build.json ci-dessus 👆), les hôtes de rendu post-déploiement dans l’environnement XM Cloud cible ressembleraient à ceci :

Une fois que XM Cloud crée ces éléments, il les définit comme protégés dans l’arborescence de contenu : ces éléments ne devrait pas être modifié en dehors du processus de déploiement de XM Cloud.

Si, pour une raison quelconque, vous avez sérialisé ces éléments et les avez remplacés manuellement (soit en apportant des modifications manuelles, soit en installant un package de contenu), vous pouvez vous retrouver dans une situation où les modifications et mises à jour lors des déploiements XM Cloud sur ces éléments sont ignorés car Sitecore examine les éléments remplacés. Cela restera un problème jusqu’à ce que les éléments sérialisés remplacés soient nettoyés à l’aide de la CLI Sitecore. itemres cleanup commande (référence : https://doc.sitecore.com/xmc/en/developers/xm-cloud/the-cli-itemres-command.html#the-cleanup-subcommand) ou les éléments remplacés sont simplement supprimés (pour être restaurés lors du prochain déploiement).

Le TL;DR pour cette astuce: ne sérialisez pas les éléments de l’hôte de rendu correspondant aux entrées dans le renderingHosts propriété dans le xmcloud.build.json file–XM cloud gère ces éléments, vous n’avez donc pas à le faire.

3. Définissez le nom et la description de la collection de sites 📛

La page de destination des sites XM Cloud a été mise à jour récemment mais, dans le passé, le nom de la collection de sites à laquelle appartenait un site était parfois présenté comme « N/A » :

Il s’avère qu’il existe une section de champ sur les éléments de la collection de sites qui permet aux développeurs de définir le Nom et Description pour la collection du site. Certes, au départ, j’étais simplement ennuyé par le « N/A » et je voulais un moyen de définir le nom de la collection de sites. Cependant, c’est généralement une bonne idée de nommer et de décrire vos collections de sites, surtout s’il y en a (ou s’il y en aura) beaucoup. Pour définir le Nom et Description champs d’un élément de collection de sites, accédez à l’élément de collection de sites dans l’arborescence de contenu et accédez au Métadonnées section field pour fournir des valeurs pour ces champs :

🥣 Assurez-vous de sérialiser toutes les mises à jour de ces éléments à l’aide de la CLI Sitecore ser pull commande (référence : https://doc.sitecore.com/xmc/en/developers/xm-cloud/the-cli-serialization-command.html#the-pull-subcommand). Les éléments de la collection de sites sont contrôlés par les développeurs et doivent être cohérents entre les environnements.

Désormais, dans l’interface XM Cloud Sites (et peut-être ailleurs dans le futur), il sera plus facile de différencier les collections de sites et de déterminer l’objectif d’une collection de sites donnée. ✅

Merci pour la lecture! 🙏