Les rendus .NET Core pour XM Cloud reçoivent enfin un peu d’amour / Blogs / Perficient

Ce n’est pas un secret – Sitecore a toujours donné la priorité au framework Next.Js en tant que citoyen de premier ordre pour XM Cloud. Toutes les fonctionnalités les meilleures et les plus raffinées ont tendance à se retrouver en premier lieu dans un cadre donné. Cependant, récemment, il y a eu beaucoup d’activité autour du .Cadre de rendu NET Core ce qui est tout à fait logique étant donné que la plupart d’entre nous, professionnels de la technologie Sitecore, sommes issus de Microsoft et de .NET. Encore plus d’excitation – cela se fait sur .NET 8, qui est le dernier runtime LST !

Kit de démarrage

Le framework ASP.NET Core était avec nous depuis un certain temps, recevant périodiquement des mises à jour et des correctifs mineurs. Mais soyons honnêtes : avoir un SDK en soi, c’est une chose, mais recevoir un kit de démarrage décent en plus de ce cadre est ce qui nous permet, en tant que développeurs, de créer à grande échelle. Et ce moment vient de se produire – sans aucune fanfare, Kit de démarrage XMC ASP.NET Core est devenu public. Bien qu’il s’agisse d’une version très précoce et qu’elle présente ses propres lacunes temporelles, je l’ai essayée et je souhaite partager mes découvertes avec vous.

Quelles sont ces lacunes ? Juste quelques-uns :

• Les composants FEaaS et BYOC ne sont pas encore pris en charge, vous ne pouvez donc pas non plus utiliser Form car il exploite ceux-ci.
• System.Text.Json le sérialiseur est plus strict que Newtonsoft qui a été supprimé au profit d’une solution intégrée, donc certains composants peut échouer
• SITECORE_EDGE_CONTEXT_ID la variable n’est pas prise en charge

Tout le reste semble fonctionner de la même manière. Il existe également certaines attentes quant à la prise en charge par XM Coud du rendu .NET sur un hôte d’édition intégré ultérieurement, de la même manière qui fonctionne aujourd’hui avec les applications JSS, mais je ne travaille pas pour Sitecore et je ne peux que faire des hypothèses et des suppositions sans aucune certitude à ce sujet.

Première impression

J’ai forké le dépôt et cloné le code forké dans mon ordinateur. Jetons un coup d’œil à ce que nous avons là-bas.

• le code varie de ce que nous avions l’habitude de voir dans le kit de démarrage XM Cloud Foundation Head, et c’est compris
• dans le dossier racine, nous avons encore xmcloud.build.json, sitecore.json et dossiers – .config et .sitecore
• xmcloud.build.json est requis pour le déploiement dans le cloud, mais n’a pas renderingHosts section racine requise pour l’édition des hôtes, comme je l’ai expliqué ci-dessus
• il y a headapps dossier pour conserver le fichier de solution avec le(s) sous-dossier(s) des projets .NET, actuellement un seul – aspnet-core-starter
• il y a aussi local-containers dossier contenant les fichiers docker-compose, .envfichiers Docker, scripts, Traefik et le reste des actifs de conteneurs auxquels nous nous sommes habitués
• une autre différence – authoring le dossier contient les paramètres et les éléments de sérialisation ainsi qu’un projet de framework .net pour les personnalisations CM
• cependant il n’y a pas init.ps1 et up.ps1 fichiers, mais c’est facile à créer vous-même en volant et en modifiant ceux de XM Cloud Foundation Head

Dans cet esprit, nous pouvons commencer à enquêter. Il existe un document Lisez-moi expliquant comment déployer cette base de code, mais avant de continuer, j’ai bien sûr décidé de :

Exécuter des conteneurs locaux

Il n’y a pas d’instructions sur la configuration des conteneurs, uniquement pour le déploiement dans le cloud, mais après avoir passé quelques années avec Foundation Head, la toute première chose qui me vient naturellement à l’esprit est d’exécuter ce kit de démarrage dans des conteneurs Docker locaux. Pourquoi pas?

Il y a quelques choses que je devrais faire avant de faire tourner des conteneurs.

1. Modifier les paramètres dans .ENV fichier – au moins ces deux :

# Enter the value for SQL Server admin password:
SQL_SA_PASSWORD=SA_PASSWORD

# Provide a folder storing a Sitecore license file:
HOST_LICENSE_FOLDER=C:\Projects

1. Nous devons générer des certificats SSL Traefik. Pour ce faire, créons .\local-containers\init.ps1 script avec le contenu ci-dessous :

[CmdletBinding(DefaultParameterSetName = "no-arguments")]
Param ()
$ErrorActionPreference = "Stop";

# duplicates in Up.ps1 scrips
$envContent = Get-Content .env -Encoding UTF8
$xmCloudHost = $envContent | Where-Object { $_ -imatch "^CM_HOST=.+" }
$renderingHost = $envContent | Where-Object { $_ -imatch "^RENDERING_HOST=.+" }
$xmCloudHost = $xmCloudHost.Split("=")[1]
$renderingHost = $renderingHost.Split("=")[1]

Push-Location docker\traefik\certs
try {
    $mkcert = ".\mkcert.exe"
    if ($null -ne (Get-Command mkcert.exe -ErrorAction SilentlyContinue)) {
        # mkcert installed in PATH
        $mkcert = "mkcert"
    } elseif (-not (Test-Path $mkcert)) {
        Write-Host "Downloading and installing mkcert certificate tool..." -ForegroundColor Green
        Invoke-WebRequest "https://github.com/FiloSottile/mkcert/releases/download/v1.4.1/mkcert-v1.4.1-windows-amd64.exe" -UseBasicParsing -OutFile mkcert.exe
        if ((Get-FileHash mkcert.exe).Hash -ne "1BE92F598145F61CA67DD9F5C687DFEC17953548D013715FF54067B34D7C3246") {
            Remove-Item mkcert.exe -Force
            throw "Invalid mkcert.exe file"
        }
    }
    Write-Host "Generating Traefik TLS certificate..." -ForegroundColor Green
    & $mkcert -install
    & $mkcert "$xmCloudHost"
    & $mkcert "$renderingHost"
}
catch {
    Write-Error "An error occurred while attempting to generate TLS certificate: $_"
}
finally {
    Pop-Location
}

Write-Host "Adding Windows host"
Add-HostsEntry "$renderingHost"
Add-HostsEntry "$xmCloudHost"

Write-Host "Done!" -ForegroundColor Green

Et puis exécutez ce script :

Il n’y a pas up.ps1 script, alors exécutons directement docker-compose : docker compose up -d

Vous remarquerez peut-être que de nouvelles images apparaissent et vous voyez également un nouveau conteneur : aspnet-core-starter

Si tout est configuré correctement, le script s’exécutera avec succès. Exécutez Sitecore à partir de son nom d’hôte par défaut, tel que configuré dans .env déposer: https://xmcloudcm.localhost/sitecore

À partir de là, vous ne verrez aucun changement significatif. Les conteneurs fonctionnent bien. Sitecore n’a aucun contenu pour interagir avec l’application principale. J’ajouterai le contenu du modèle, mais commençons par le déploiement du potentiel.

Déployer sur le cloud

Lisez-moi Le document suggère une manière peu pratique de déployer le cloud :

1. Créez un référentiel à partir de ce modèle. 2. Connectez-vous à Portail de déploiement Sitecore. 3. Créez un nouveau projet en utilisant l’option « apportez votre code » et sélectionnez le référentiel que vous avez créé à l’étape 1.

Pour la majorité d’entre nous, qui sommes du côté des Sitecore Partner, il n’y a que six environnements disponibles regroupés en deux projets. Ces allocations sont inestimables et sont soigneusement partagées entre tous les passionnés de XM Cloud et les aspirants qui apprennent une nouvelle plateforme. Nous ne pouvons pas simplement « créer un nouveau projet » parce que nous n’avons pas de projet de rechange, donc pour en créer un, nous devons supprimer celui existant. Supprimer un projet nécessite en premier lieu de supprimer tous (trois) ses environnements, ce qui représente la moitié de notre capacité, ce qui représente un travail en cours précieux pour de nombreuses personnes.

C’est pourquoi j’ai décidé d’utiliser CLI à la place. Cela fonctionne exactement de la même manière qu’avec les kits de démarrage Next.Js, et depuis .\.config\dotnet-tools.json vous verrez peut-être qu’il utilise cette même version. Vous déployez le dossier racine contenant xmcloud.build.json fichier en tant que répertoire de travail, il n’y a donc aucun changement dans l’exécution.

Finalement, une fois déployé, nous naviguons vers le cloud XM. J’ai décidé de suivre le fichier ReadMe et de créer un site basique à partir du modèle Skate Park. Fondamentalement, je suis les étapes 4 à 18 du Lisez-moi déposer.

En guise d’exercice parallèle, vous devrez supprimer un composant de navigation d’un élément partiel d’en-tête, situé dans /sitecore/content/Basic/Basic/Presentation/Partial Designs/Header. Le site de base sera interrompu dans le débogueur si vous ne supprimez pas le rendu actuellement incompatible qui présente un problème de sérialisation.

Création d’un tunnel de développement dans Visual Studio

Ensuite, ouvrons et créons la solution dans l’IDE Visual Studio, qui fait référence à .\headapps\aspnet-core-starter.sln déposer. Vous pouvez le voir lié à trois dépendances Sitecore de Sitecore.AspNetCore.SDK.LayoutService.Client:

• Transitoire: Sitecore.AspNetCore.SDK.LayoutService.Client.Interfaces.ISitecoreLayoutClient
• Singleton: Sitecore.AspNetCore.SDK.LayoutService.Client.Serialization.ISitecoreLayoutSerialize
• Singleton: Sitecore.AspNetCore.SDK.LayoutService.Client.Serialization.Converter.IFieldParser

Modifier .\headapps\aspnet-core-starter\appsettings.json avec les valeurs de réglage collectées lors des étapes précédentes. Vous obtiendrez quelque chose ressemblant à :

Créons maintenant un tunnel de développement dans VisualStudio :

Il y aura au moins deux invites de sécurité :

Si tout se passe bien, un message de confirmation apparaît :

Vous pourrez désormais exécuter et déboguer votre code dans Visual Studio :

Notez l’URL du tunnel de développement afin que nous puissions l’utiliser pour configurer l’hôte de rendu, comme décrit à l’étape 27 du fichier Lisez-moi. Vous obtiendrez quelque chose comme ci-dessous :

Jusqu’ici, tout va bien. Vous pouvez désormais exécuter le site Web par URL et dans Experience Editor. L’exécution dans Page ne fonctionnera cependant pas encore en raison de l’erreur ci-dessous :

Pour expliquer cela, Experience Editor s’exécute dans le cadre de CM et extrait le contenu d’un point de terminaison GraphQL sur ce même CM. Pages est à la place une application distincte et autonome, elle n’a donc accès ni au point de terminaison ni à l’élément de paramètres Hôtes de rendu. Il n’a accès qu’à Experience Edge, nous devons donc d’abord publier. Assurez-vous de publier l’intégralité de la collection de sites. Une fois terminé, Page fonctionne parfaitement et affiche le site :

Pour expliquer ce qui se passe ci-dessus: Application Pages (qui est un éditeur SaaS) extrait Experience Edge pour les paramètres du rendu hôte d’édition (qui s’exécute dans un tunnel de développement déboguable à partir de Visual Studio) et restitue le HTML directement avec les données de mise en page et le contenu extraits d’Experience Edge.

Déployer un hôte de rendu sur le cloud

Sans trop réfléchir, j’ai décidé de déployer l’hôte de rendu en tant qu’Azure Web App, en partant du principe que l’application .NET 8 serait mieux prise en charge dans son cloud natif.

Une fois l’application Web créée, ajoutez les variables d’environnement requises. Le moderne et brillant SITECORE_EDGE_CONTEXT_ID La variable n’est pas encore prise en charge avec le SDK .NET Core, nous devrions donc utiliser l’ancienne méthode :

Un avantage agréable de l’intégration de GitHub est qu’Azure crée un flux de travail GitHub Actions avec la construction et le déploiement fonctionnels par défaut. Il n’y a presque rien à changer, je n’ai fait qu’un seul correctif en remplaçant run : dotnet submit -c Release -o ${{env.DOTNET_ROOT}}/myapp avec un chemin codé en dur puisque cette variable contient de l’espace de la partie « Program Files » et est incorrectement tokenisé, interrompant la construction. Après ce correctif, les actions GitHub ont été créées correctement et j’ai commencé à recevoir le statut vert :

… et le site publié apparaît à partir de l’hôte de rendu alimenté par Azure Web App :

Enfin, nous pouvons nous débarrasser de Dev Tunnel, en le remplaçant par les véritables noms d’hôtes des « sites publiés » :

Après avoir republié l’élément Rendering Host sur Edge, nous pouvons arrêter le débogueur et fermer Visual Studio. L’application Experience Editor et Pages fonctionnent désormais avec un hôte d’édition servi par Azure Web App.

Verdict

Bien sûr, il serait très attendu que XM Cloud dispose de capacités d’hôte d’édition .NET intégrées de la même manière que JSS. Mais même sans cela, j’applaudis l’équipe de développement de Sitecore pour avoir créé et continué à travailler sur ce kit de démarrage, car c’est une étape importante pour nous tous au sein de la communauté .NET !

Avec ce kit, nous pouvons désormais commencer à créer une application .NET alimentée par XM Cloud à un rythme plus rapide. Je pense que toutes les fonctionnalités manquantes trouveront leur chemin vers le produit, et peut-être que plus tard il y aura un support (semi)officiel SSG pour .NET, quelque chose comme Statique. Cela permettra des déploiements sur un ensemble plus large d’hébergements, tels que Azure Static Web Apps, Netlify et même Vercel qui ne prend pas en charge .NET pour le moment.