O AEM como um SDK 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 Quickstart e você suspeitar que isso seja devido a interfaces que foram removidas de AEM implantadas como Cloud Service, entre em contato com o Suporte ao cliente para determinar se você precisa de acesso. Isso exigirá alterações no backend.
O AEM como um SDK Cloud Service é usado para criar e implantar código personalizado. Para obter mais detalhes, consulte a AEM documentação do Project Archetype. Em um nível alto, as seguintes etapas são executadas:
As mesmas etapas são executadas pelo Gerenciador de nuvem ao implantar Ambientes da Cloud. A execução de builds localmente permite o desenvolvimento e o teste locais para que os desenvolvedores possam descobrir problemas estruturais ou de código 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 um Cloud Service. Você pode ver qual versão está usando fazendo logon no AEM, indo para o ponto de interrogação no canto superior direito da tela e selecionando Sobre o Adobe Experience Manager
Quando é recomendado atualizar o projeto local com um novo SDK?
É recomendado atualizá-lo pelo menos após uma versão de manutenção mensal.
É opcional atualizá-lo após qualquer versão de manutenção diária. Os clientes serão informados quando sua instância de produção for atualizada com êxito para uma nova versão AEM. Para as versões de manutenção diárias, não é de se esperar que o novo SDK tenha mudado significativamente, se é que isso aconteceu. Ainda assim, é recomendável atualizar ocasionalmente o ambiente local AEM desenvolvedor 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 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 frequentemente (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 gerada automaticamente no primeiro start de um ambiente AEM. Enquanto a configuração de nuvem cuida 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ê gostaria que fossem reutilizados/crx/de
para adicioná-lo ao pacote que será reutilizado em instalações