Utilisation des compétences de migration vers le cloud AEM using-cloud-migration-skill
Cette référence couvre chaque modèle de migration pris en charge, la manière de fournir des résultats BPA et de gérer les sessions dans un projet volumineux. Pour obtenir une introduction et des instructions de configuration, consultez la présentation.
Générer un Runbook de migration migration-runbook
Pour une évaluation de projet complet, commencez avec un runbook au lieu de nommer un seul modèle. Demandez à l’agent avec :
Review my code for AEMaaCS migration
La compétence génère un migration-runbook.md lecture seule à la racine de votre projet sans modifier de code. Le runbook couvre chaque modèle que les compétences de migration peuvent traiter et, pour chacun d’eux, enregistre :
- Stratégie de détection utilisée (résultats BPA/CAM, analyseur ou analyse heuristique de contenu)
- Les fichiers affectés et un nombre de résultats par motif
- Une invite de copier-coller pour démarrer la session de migration de ce modèle
Comme le runbook écrit également un cache de résultats avec le markdown, une session ultérieure de répétition réutilise les résultats déjà découverts — l’agent ne réanalyse pas. Utilisez le runbook pour classer par priorité les modèles à traiter en premier, puis démarrez les sessions de modèles comme décrit ci-dessous.
Fonctionnement d’une session workflow-overview
Chaque session de migration suit cette séquence :
- Nommez le modèle : spécifiez un modèle (par exemple,
scheduler) - Fournir des résultats : à partir d’un fichier CSV BPA, CAM via MCP ou de chemins d’accès à des fichiers spécifiques
- L’agent lit les règles de transformation : la compétence lit les règles de transformation appropriées de la compétence
code-assessmentcompagnon avant d’apporter des modifications au code - Premier lot de cinq : l’agent transforme jusqu’à cinq résultats et signale ce qu’il a modifié
- Vous vérifiez et continuez : après avoir vérifié chaque lot, répondez
continuepour passer au suivant
L’agent traite un modèle et un lot à la fois. Il ne se poursuit pas automatiquement ; chaque lot nécessite votre confirmation.
Modèles de migration patterns
Planificateur scheduler
Cible les classes Java à l’aide de l’injection sling.commons.scheduler ou Scheduler qui sont incompatibles avec l’exécution en conteneur sans état d’AEMaaCS.
Identifiant de modèle BPA : scheduler
L’agent convertit les tâches injectées par Scheduler en implémentations @Component de Runnable à l’aide de @Designate, en remplaçant l’enregistrement du planificateur basé sur le constructeur par des méthodes de cycle de vie @Activate/@Deactivate.
ResourceChangeListener resource-change-listener
Cible les implémentations de listener ResourceChangeListener ou ResourceChange qui nécessitent des mises à jour pour AEMaaCS.
Identifiant de modèle BPA : resourceChangeListener
Réplication replication
Classes cibles important des API de réplication com.day.cq.replication.Replicator ou associées, qui ne sont pas prises en charge dans AEMaaCS. L’agent les remplace par des équivalents basés sur ContentDistribution et met à jour les références de service OSGi correspondantes.
Identifiant de modèle BPA : replication
Écouteur d’événement event-listener
Cible les implémentations OSGi EventListener ou EventHandler qui doivent être mises à jour pour la sémantique de traitement des événements AEMaaCS.
Identifiant de modèle BPA : eventListener
Gestionnaire d’événements event-handler
Cible les services EventHandler OSGi synchrones qui doivent être adaptés à AEMaaCS.
Identifiant de modèle BPA : eventHandler
API de ressources asset-api
Cible les classes à l’aide d’API AssetManager, DAMEvent ou DAM non prises en charge obsolètes. L’agent les remplace par les équivalents API AEM Assets pris en charge.
Identifiant de modèle BPA : assetApi
Cache de goyave à la caféine guava-cache
Cible les lots qui utilisent le cache de Guava (com.google.common.cache.*, tels que Cache, CacheBuilder et LoadingCache). Sur AEM as a Cloud Service, la bibliothèque de cache en cours de traitement prise en charge est la caféine, de sorte que l’agent permute la dépendance Maven, met à jour les importations et ajuste les sites d’appel affectés. Comme la caféine a été écrite par le même auteur et que son API est intentionnellement presque identique, le changement est principalement mécanique.
Identifiant de modèle BPA : guavaCache
BPA signale ce modèle avec une granularité bundle (sous-type custom.guava.cache), de sorte que l’agent résout le bundle sur les fichiers Java qui importent réellement le cache Guava et les modifie. Ce modèle est fourni uniquement par la compétence de migration (et non code-assessment), car l’utilisation du cache Guava se produit uniquement dans le code transféré à partir de l’AEM hérité, jamais dans le code Cloud Service natif.
guavaCache s’appuie sur le BPA comme source de vérité. Lorsqu’aucune source BPA ou CAM n’est disponible, l’agent analyse vos fichiers Java à la recherche d’importations import com.google.common.cache en tant que candidats non confirmés.HTL Lint (data-sly-test) htl-lint
Cible les modèles HTL sous ui.apps qui génèrent des avertissements data-sly-test: redundant constant value comparison. L’agent détecte les modèles affectés en analysant directement le package de contenu ; ce modèle ne nécessite pas de connexion CSV ou CAM BPA.
Identifiant de modèle BPA : htlLint
htlLint résultats n’apparaissent pas dans les exportations CSV BPA. L’agent les découvre par analyse directe des fichiers lorsque vous démarrez une session pour ce modèle.Configurations OSGi pour Cloud Manager osgi-cloud-manager
Convertit les configurations OSGi en ui.config au format .cfg.json compatible avec Cloud Manager avec une gestion complète spécifique à l’environnement. Cela couvre plusieurs tâches connexes :
Conversion du format de configuration
AEMaaCS nécessite que les configurations OSGi soient stockées sous la forme de fichiers .cfg.json, avec des configurations spécifiques à l’environnement dans les dossiers dont le mode d’exécution a la portée (config.author/, config.publish/, config.dev/, etc.). L’agent :
- Convertit les configurations OSGi
.config,.cfget au format XML existantes en.cfg.json - Divise les configurations contenant à la fois des valeurs spécifiques à l’auteur et à la publication en fichiers distincts de l’étendue du mode d’exécution
- Valide les types de propriété par rapport à la spécification du métatype OSGi (chaînes, entiers, booléens, tableaux).
- Indique les PID appartenant à Adobe pour une révision manuelle plutôt que pour une conversion automatique
Secrets et variables d’environnement
Déplace les secrets en texte brut et les valeurs spécifiques à l’environnement des fichiers de configuration validés et les remplace par des espaces réservés Cloud Manager :
$[secret:NAME]: pour les mots de passe, jetons et autres valeurs sensibles$[env:NAME]: pour les valeurs non sensibles qui diffèrent par environnement (par exemple, les URL de service)
Les variables et secrets correspondants sont appliqués dans Cloud Manager et injectés au moment de l’exécution ; aucune valeur n’est stockée dans le contrôle de code source.
Modes d’exécution non pris en charge (URC)
AEM as a Cloud Service prend en charge un ensemble fixe d’identifiants de mode d’exécution. Les dossiers de configuration qui utilisent un mode d’exécution non pris en charge n’ont aucun effet une fois déployés. L’agent signale ces configurations de mode d’exécution (URC) non prises en charge, notamment :
- Jetons de mode d’exécution inconnus, par exemple
config.qaouinstall.local - Un jeton de niveau qui suit au lieu de précède le jeton d’environnement,
config.dev.authorau lieu duconfig.author.devvalide. - Jetons non en minuscules, tels que
config.Author.dev, et leconfig.previewréservé (l’aperçu hérite de la publication)
Les résultats URC proviennent d’abord de l’analyseur de bonnes pratiques (sous-type unsupported.runmode, CRITICAL de gravité). Lorsqu’aucune source BPA ne les signale, l’agent analyse les dossiers config.* et install.* localement comme un filet de sécurité. Pour chaque recherche, il indique le chemin d’accès au dossier, le mode d’exécution fautif et la correction. Évaluez si la configuration est toujours nécessaire, renommez-la en mode d’exécution pris en charge ou supprimez-la si elle est obsolète. Pour les violations de commande uniquement, où chaque jeton est valide mais dans le désordre, l’agent peut appliquer automatiquement une réorganisation sécurisée (par exemple, renommer config.dev.author en config.author.dev) ; les jetons inconnus et autres cas ambigus sont signalés pour que vous puissiez les résoudre.
La conversion du format de configuration et l’externalisation secrète ne nécessitent pas de CSV ou de CAM BPA, et la détection URC utilise les résultats BPA lorsqu’ils sont disponibles. Démarrer une session avec :
Scan my config files and create Cloud Manager environment secrets or variables.
Migration de boîtes de dialogue (interface utilisateur héritée) dialog-migration
Convertit les boîtes de dialogue classiques de l’interface utilisateur en interface utilisateur tactile. L’agent gère deux sous-types de boîte de dialogue : ExtJS/IU classique cq:Dialog les définitions sont reconstruites en tant que structures de _cq_dialog Coral 3, et les boîtes de dialogue Coral 2 existantes sont mises à niveau sur place vers Coral 3. Il transfère également les écouteurs, les optionsProvider, les namePrefix et les mises à jour filter.xml.
ID de modèle BPA : lui (sous-types de boîte de dialogue uniquement)
Lorsqu’il existe une boîte de dialogue et des résultats de widget personnalisés pour les mêmes composants, exécutez d’abord la migration du widget personnalisé afin que toutes les références xtype soient résolues avant que les boîtes de dialogue ne soient converties.
Convert my Classic UI dialogs to Touch UI Coral 3.
Widgets de conception personnalisés (interface utilisateur héritée) custom-design-widgets
Migre des widgets ExtJS personnalisés (définitions cq:Widget avec des valeurs de xtype personnalisées). L’agent répertorie les widgets, puis mappe chaque xtype à un équivalent Coral 3 connu ou crée un modèle automatique d’un composant de formulaire de l’IU Granite lorsqu’il n’existe aucun mappage direct.
Identifiant de modèle BPA : cdw
Migrate my custom ExtJS widgets (CDW findings) from CAM.
Modernisation des modèles template-modernization
Convertit les modèles statiques en modèles modifiables et génère les règles de réécriture des outils de modernisation d’AEM correspondantes (structure, composant et règles de politique). L’agent s’exécute en trois phases : il détecte les modèles et produit un plan par modèle, exécute le modèle de plan par modèle et valide les structures de /conf générées.
Lors de la découverte, l’agent parcourt les modèles sous apps/<appId>/templates/ à n’importe quelle profondeur, y compris les dossiers de modèles imbriqués ou groupés, et classe chaque modèle statique comme hérité ou personnalisé en fonction de son type de ressource de composant de page. Cette classification est conservée même sans rapport BPA, de sorte que les modèles personnalisés sont gérés différemment des modèles hérités.
Ce modèle n’utilise pas d’ID de modèle BPA. Démarrer une session avec :
Migrate my static templates to editable templates and generate the Modernize Tools rewrite rules.
Conversion Dispatcher dispatcher-conversion
Convertit une configuration AMS ou Apache HTTPD et Dispatcher On-Premise à la structure AEM as a Cloud Service. Cette fonctionnalité intègre l’outil Dispatcher Converter entretenu par Adobe, ajoutant la détection, la génération de configurations, la vérification de sortie et la validation.
L’agent fonctionne par étapes :
- Détecter et inventorier - Détermine la configuration mode et enregistre un nombre de lignes de base de règles de filtrage, de réécriture et de mise en cache. Les modes reconnus sont
standard(AMS),flexible(On-Premise monolithique),v1(dispositions plus anciennes),already-cloud,not-dispatcheretunknown. Paralready-cloud,not-dispatcherouunknown, l’agent s’arrête et vous demande de confirmer avant de continuer. - Planifier et générer la configuration - Construit la configuration du convertisseur et confirme le plan avec vous.
- Convert - Exécute le convertisseur Adobe Dispatcher (installé automatiquement lors de la première utilisation).
- Vérifier - Vérifie la sortie par rapport à la ligne de base. Un jeu de filtres vidé (
filter-acl-loss) est un arrêt brutal qui doit être résolu avant de continuer. - Transfert transfrontalier : achemine les variables d’environnement Cloud Manager vers le flux des configurations OSGi et signale les candidats au réseau CDN ou à l’en-tête de sécurité.
- Valider - Exécute le programme de validation de Cloud Service Dispatcher et génère un rapport de conversion consolidé.
id de modèle Runbook : dispatcherConversion (détecté de manière heuristique à partir de la disposition de configuration). Ce modèle n’utilise ni BPA ni CAM. Démarrer une session avec :
Convert my AMS / on-prem Dispatcher config to AEM as a Cloud Service.
standard configurations AMS sont quasi automatisées, tandis que les mises en page flexible et v1 doivent être examinées plus en détail.Options Source BPA bpa-source
Gestion des erreurs MCP mcp-errors
Si la connexion MCP renvoie une erreur (notamment un projet introuvable ou des échecs d’authentification), l’agent s’arrête et vous indique l’erreur. Il ne bascule pas automatiquement vers une autre source. À partir de l’état arrêté , vous pouvez :
- Confirmez le projet correct à partir de la liste de l’agent affichée
- Fournir un chemin d’accès CSV BPA en alternative
- Fournir des chemins d’accès aux fichiers Java spécifiques pour une migration manuelle
Gestion des sessions dans les rapports volumineux large-reports
Pour les rapports BPA comportant de nombreux résultats, l’approche lot par lot vous permet de valider de manière incrémentielle :
- Vérifier la différence pour chaque lot
- Validez le lot avec un message de validation dont la portée est définie sur un modèle
- Répondre
continuepour démarrer le lot suivant - Répétez l’opération jusqu’à ce que l’agent signale que tous les résultats du modèle ont été obtenus
Un modèle par validation rend votre historique Git lisible et permet d’annuler facilement les transformations individuelles des modèles, si nécessaire.
Workspace Scope workspace-scope
L’agent recherche et modifie uniquement les fichiers dans les dossiers de l’espace de travail IDE ouverts. Il n’analyse pas les répertoires parents, les dossiers frères ni d’autres emplacements sur le disque.
Si un résultat de recherche BPA fait référence à un chemin d’accès au fichier qui n’existe pas dans l’espace de travail, l’agent s’arrête et vous indique quels chemins d’accès sont manquants. Ouvrez le dossier de projet approprié ou indiquez explicitement les chemins d’accès pour continuer.