Usar a habilidade de migração em nuvem do AEM using-cloud-migration-skill

Essa referência aborda cada padrão de migração compatível, como fornecer descobertas de BPA e como gerenciar sessões em um grande projeto. Para obter uma introdução e instruções de configuração, consulte a visão geral.

Gerar uma Runbook de migração migration-runbook

Para uma avaliação de todo o projeto, comece com um runbook em vez de nomear um único padrão. Solicitar ao agente:

Review my code for AEMaaCS migration

A habilidade gera um somente leituramigration-runbook.md na raiz do projeto sem alterar nenhum código. O runbook abrange o padrão a cada que a habilidade de migração pode endereçar e, para cada um, registra:

Como o runbook também grava um cache de resultados ao lado do Markdown, uma sessão de padrão posterior reutiliza os resultados já descobertos — o agente não faz uma nova verificação. Use o runbook para priorizar quais padrões serão tratados primeiro e, em seguida, inicie as sessões de padrão conforme descrito abaixo.

Como uma sessão funciona workflow-overview

Cada sessão de migração segue esta sequência:

O agente processa um padrão e um lote por vez. Ele não continua automaticamente; cada lote requer sua confirmação.

Padrões de migração patterns

Scheduler scheduler

Segmenta classes Java usando injeção de sling.commons.scheduler ou Scheduler que são incompatíveis com o tempo de execução contêiner e sem estado do AEMaaCS.

ID do padrão BPA: scheduler

O agente converte trabalhos inseridos Scheduler em @Component implementações de Runnable usando @Designate, substituindo o registro do agendador baseado em construtor por métodos de ciclo de vida @Activate / @Deactivate.

ResourceChangeListener resource-change-listener

Direciona ResourceChangeListener ou ResourceChange implementações de ouvinte que exigem atualizações para o AEMaaCS.

ID do padrão BPA: resourceChangeListener

Replicação replication

Classes de destino que importam com.day.cq.replication.Replicator ou APIs de replicação relacionadas, que não têm suporte no AEMaaCS. O agente os substitui por equivalentes baseados em ContentDistribution e atualiza as referências de serviço OSGi correspondentes.

ID do padrão BPA: replication

Ouvinte de eventos event-listener

Direciona implementações OSGi EventListener ou EventHandler que devem ser atualizadas para a semântica de processamento de eventos do AEMaaCS.

ID do padrão BPA: eventListener

Manipulador de eventos event-handler

Segmenta serviços OSGi EventHandler síncronos que precisam ser adaptados para AEMaaCS.

ID do padrão BPA: eventHandler

API de ativos asset-api

Classes de destino que usam APIs do DAM obsoletas AssetManager, DAMEvent ou sem suporte. O agente os substitui pelos equivalentes de API compatíveis do AEM Assets.

ID do padrão BPA: assetApi

Cache de goiaba para cafeína guava-cache

Pacotes de destino que usam o cache do Guava (com.google.common.cache.*, como Cache, CacheBuilder e LoadingCache). No AEM as a Cloud Service, a biblioteca de cache em andamento com suporte é a Cafeína. Portanto, o agente troca a dependência do Maven, atualiza importações e ajusta os sites de chamada afetados. Como a cafeína foi escrita pelo mesmo autor e sua API é intencionalmente quase idêntica, a alteração é principalmente mecânica.

ID do padrão BPA: guavaCache

O BPA relata esse padrão na granularidade bundle (subtipo custom.guava.cache), portanto, o agente resolve o pacote para os arquivos Java que realmente importam o cache Guava e os edita. Esse padrão é fornecido apenas pela habilidade de migração, não code-assessment, porque o uso do cache Guava ocorre somente no código herdado do AEM, nunca no código nativo do Cloud Service.

Lint HTL (data-sly-test) htl-lint

Segmenta modelos HTL em ui.apps que produzem data-sly-test: redundant constant value comparison avisos de linha. O agente descobre os modelos afetados examinando o pacote de conteúdo diretamente; esse padrão não requer uma conexão BPA CSV ou CAM.

ID do padrão BPA: htlLint

Configurações OSGi para o Cloud Manager osgi-cloud-manager

Converte configurações OSGi em ui.config para o formato .cfg.json compatível com Cloud Manager com manipulação específica de ambiente completo. Abrange várias tarefas relacionadas:

Conversão de formato de configuração

O AEMaaCS exige que as configurações OSGi sejam armazenadas como .cfg.json arquivos, com configurações específicas do ambiente em pastas de escopo de modo de execução (config.author/, config.publish/, config.dev/ e assim por diante). O agente:

Segredos e variáveis de ambiente

Move segredos de texto simples e valores específicos do ambiente para fora dos arquivos de configuração confirmados e os substitui por espaços reservados do Cloud Manager:

As variáveis e segredos correspondentes são aplicados no Cloud Manager e inseridos no tempo de execução; nenhum valor é armazenado no controle do código-fonte.

Não há suporte para modos de execução (URC)

O AEM as a Cloud Service oferece suporte a um conjunto fixo de identificadores de modo de execução. As pastas de configuração que usam um modo de execução não compatível não terão efeito depois de implantadas. O agente sinaliza essas Configurações de modo de Execução Não Suportadas (URC), incluindo:

As descobertas de URC vêm primeiro do Analisador de Práticas Recomendadas (subtipo unsupported.runmode, severidade CRITICAL); quando nenhuma origem de BPA as relata, o agente verifica as pastas config.* e install.* localmente como uma rede de segurança. Para cada descoberta, ele relata o caminho da pasta, o modo de execução incorreto e a correção: avalie se a configuração ainda é necessária, renomeie-a para um modo de execução compatível ou remova-a se estiver obsoleta. Para violações somente de ordenação, onde cada token é válido, mas está fora de ordem, o agente pode aplicar uma reordenação segura automaticamente (por exemplo, renomear config.dev.author para config.author.dev); tokens desconhecidos e outros casos ambíguos são sinalizados para você resolver.

A conversão de formato de configuração e a externalização secreta não exigem um CSV ou CAM do BPA, e a detecção de URC usa descobertas de BPA quando disponíveis. Iniciar uma sessão com:

Scan my config files and create Cloud Manager environment secrets or variables.

Migração de caixa de diálogo (interface herdada) dialog-migration

Converte as caixas de diálogo da interface clássica em interface de toque. O agente lida com dois subtipos de diálogo: as definições ExtJS / Interface clássica cq:Dialog são recriadas como estruturas Coral 3 _cq_dialog, e as caixas de diálogo Coral 2 existentes são atualizadas no local para Coral 3. Também transporta ouvintes, optionsProvider, namePrefix e atualizações filter.xml.

ID do padrão BPA: lui (somente subtipos da caixa de diálogo)

Quando existirem descobertas de diálogo e widget personalizado para os mesmos componentes, execute a migração de widget personalizado primeiro, para que todas as referências de xtype sejam resolvidas antes que as caixas de diálogo sejam convertidas.

Convert my Classic UI dialogs to Touch UI Coral 3.

Widgets de design personalizados (interface herdada) custom-design-widgets

Migra widgets ExtJS personalizados (cq:Widget definições com xtype valores personalizados). O agente faz o inventário dos widgets e mapeia cada xtype para um equivalente Coral 3 conhecido, ou então cria andaimes para um componente de formulário da interface do Granite quando não existe mapeamento direto.

ID do padrão BPA: cdw

Migrate my custom ExtJS widgets (CDW findings) from CAM.

Modernização de modelo template-modernization

Converte modelos estáticos em modelos editáveis e gera as regras de regravação das Ferramentas de modernização do AEM correspondentes (regras de estrutura, componente e política). O agente é executado em três fases: descobre os modelos e produz um plano por modelo, executa o modelo de plano por modelo e valida as estruturas /conf geradas.

Durante a descoberta, o agente percorre os modelos em apps/<appId>/templates/ a qualquer profundidade, incluindo pastas de modelo aninhadas ou agrupadas, e classifica cada modelo estático como herdado ou personalizado com base no tipo de recurso do componente página. Essa classificação é válida mesmo sem um relatório do BPA, de modo que os modelos personalizados são tratados de forma distinta dos herdados.

Este padrão não usa uma ID de padrão BPA. Iniciar uma sessão com:

Migrate my static templates to editable templates and generate the Modernize Tools rewrite rules.

Conversão do Dispatcher dispatcher-conversion

Converte uma configuração AMS ou Apache HTTPD e Dispatcher local na estrutura do AEM as a Cloud Service. Este recurso envolve a ferramenta Dispatcher Converter mantida pela Adobe, adicionando detecção, geração de configuração, verificação de saída e validação ao redor dela.

O agente funciona por meio de um fluxo em fases:

ID do padrão do Runbook: dispatcherConversion (detectado heuristicamente no layout de configuração). Esse padrão não usa BPA nem CAM. Iniciar uma sessão com:

Convert my AMS / on-prem Dispatcher config to AEM as a Cloud Service.

Opções de Source do BPA bpa-source

Tratamento de erros de MCP mcp-errors

Se a conexão MCP retornar um erro (incluindo falhas de projeto não encontrado ou de autenticação), o agente será interrompido e mostrará o erro. Ele não muda automaticamente para outra origem. No estado interrompido, é possível:

Gerenciamento de sessões em relatórios grandes large-reports

Para relatórios do BPA com muitas descobertas, a abordagem lote a lote permite validar de forma incremental:

Um padrão por confirmação mantém o histórico do Git legível e facilita a reversão de transformações padrão individuais, se necessário.

Escopo do Workspace workspace-scope

O agente procura e edita arquivos somente nas pastas abertas da área de trabalho do IDE. Ele não examina diretórios pai, pastas irmãs ou outros locais no disco.

Se uma descoberta de BPA fizer referência a um caminho de arquivo que não existe no espaço de trabalho, o agente será interrompido e informará quais caminhos estão ausentes. Abra a pasta do projeto correta ou forneça os caminhos explicitamente para continuar.