O AEM como SDK do Cloud Service é composto pelos seguintes artefatos:
Além disso, alguns clientes que foram implantados anteriormente com AEM 6.5 ou versões anteriores usarão os artefatos abaixo. Se a compilação local não estiver funcionando com o jar do Quickstart e você suspeitar que isso se deve a interfaces que foram removidas AEM implantadas como um Cloud Service, entre em contato com o Suporte ao cliente para determinar se você precisa de acesso. Isso exigirá alterações no back-end.
O AEM como SDK do Cloud Service é usado para criar e implantar código personalizado. Para obter mais detalhes, consulte a AEM documentação do Arquétipo de projeto. Em um alto nível, as seguintes etapas são executadas:
As mesmas etapas são executadas pelo Cloud Manager ao implantar em ambientes do Cloud. A execução de builds localmente permite o desenvolvimento e o teste locais, de modo que os desenvolvedores possam descobrir problemas de código ou estruturais com eficiência, bem antes de se comprometer com o controle de origem e acionar as implantações do Cloud Manager, o que pode demorar mais.
<dependency>
<groupId>com.adobe.aem</groupId>
<artifactId>aem-sdk-api</artifactId>
<version>2019.11.3006.20191108T223635Z-191201</version>
<scope>provided</scope>
</dependency>
A entrada da versão do SDK deve corresponder à versão do AEM como Cloud Service. Você pode ver qual versão está usando fazendo logon no AEM, depois indo para o ponto de interrogação no canto superior direito da tela e selecionando Sobre o Adobe Experience Manager
Quando é recomendável atualizar o projeto local com um novo SDK?
É recomendado atualizá-lo pelo menos após uma versão de manutenção mensal.
É opcional para atualizá-lo após qualquer versão de manutenção diária. Os clientes serão informados quando a instância de produção for atualizada com êxito para uma nova versão de AEM. Para as versões de manutenção diárias, não se espera que o novo SDK tenha mudado significativamente, se é que mudará. Ainda assim, é recomendável atualizar ocasionalmente o ambiente de desenvolvedor do AEM local com o SDK mais recente, em seguida recriar e testar o aplicativo personalizado. A versão de manutenção mensal normalmente inclui alterações mais impactantes e, portanto, os desenvolvedores devem atualizar, reconstruir e testar imediatamente.
Abaixo está o procedimento recomendado para atualizar um ambiente local:
crx-quickstart
para uma pasta diferente para manter a segurança-r
).
Se houver conteúdo que deve ser instalado com cada nova versão de início rápido de AEM, inclua-o em um pacote de conteúdo e no controle de origem do projeto. Em seguida, instale-o sempre.
A recomendação é atualizar o SDK com frequência (por exemplo, bisemanalmente) e descartar o estado local completo diariamente para não depender acidentalmente dos dados de estado no aplicativo.
Caso você dependa do CryptoSupport (configurando as credenciais do Cloudservices ou do serviço SMTP Mail no AEM ou usando a API CryptoSupport no aplicativo), as propriedades criptografadas serão criptografadas por uma chave que é gerada automaticamente no primeiro início de um ambiente AEM. Embora a configuração de nuvem trate da reutilização automática da CryptoKey específica do ambiente, é necessário injetar a chave de criptografia no ambiente de desenvolvimento local.
Por padrão, o AEM é configurado para armazenar os dados principais dentro da pasta de dados de uma pasta, mas para facilitar a reutilização no desenvolvimento, o processo de AEM pode ser inicializado na primeira inicialização com "-Dcom.adobe.granite.crypto.file.disable=true
". Isso gerará os dados de criptografia em "/etc/key
".
Para poder reutilizar pacotes de conteúdo contendo os valores criptografados, siga estas etapas:
-Dcom.adobe.granite.crypto.file.disable=true
". É recomendável, mas opcional, sempre adicioná-lo./etc/key
". Isso manterá o segredo a ser reutilizado em todos os ambientes para os quais você deseja que eles sejam reutilizados/crx/de
para adicioná-lo ao pacote que será reutilizado em instalações