Diretrizes de desenvolvimento do AEM as a Cloud Service

O código sendo executado em AEM como um Cloud Service deve estar ciente do fato de que ele está sempre em execução em um cluster. Isso significa que sempre há mais de uma instância em execução. O código deve ser resiliente, especialmente porque uma instância pode ser interrompida em qualquer momento.

Durante a atualização do AEM como um Cloud Service, haverá instâncias com o código novo e antigo sendo executado em paralelo. Portanto, o código antigo não deve quebrar com o conteúdo criado pelo novo código e o novo código deve ser capaz de lidar com o conteúdo antigo.

Se houver a necessidade de identificar o principal no cluster, a API de descoberta Apache Sling pode ser usada para detectá-lo.

Estado na memória

O estado não deve ser mantido na memória, mas persistido no repositório. Caso contrário, esse estado pode ser perdido se uma instância for interrompida.

Estado no sistema de arquivos

O sistema de arquivos da instância não deve ser usado em AEM como Cloud Service. O disco é efêmero e será descartado quando as instâncias forem recicladas. A utilização limitada do sistema de arquivos para armazenamentos temporários relacionados com o processamento de pedidos únicos é possível, mas não deve ser abusada para arquivos enormes. Isso ocorre porque pode ter um impacto negativo na cota de uso de recursos e ser executado em limitações de disco.

Como exemplo, onde o uso do sistema de arquivos não é suportado, a camada de publicação deve garantir que todos os dados que precisam ser persistentes sejam enviados para um serviço externo para armazenamento de longo prazo.

Observação

Da mesma forma, com tudo o que está a acontecer de forma assíncrona, como atuar sobre eventos de observação, não se pode garantir que seja executado localmente, pelo que tem de ser utilizado com cuidado. Isso é verdadeiro para eventos JCR e eventos de recursos Sling. No momento em que uma alteração ocorre, a instância pode ser retirada e substituída por uma instância diferente. Outras instâncias na topologia que estão ativas no momento poderão reagir a esse evento. No entanto, neste caso, este não será um evento local e pode até não haver um líder ativo no caso de uma eleição de líder em curso quando o evento for emitido.

Tarefas em segundo plano e trabalhos de longa execução

O código executado como tarefas em segundo plano deve supor que a instância em que está sendo executado pode ser desativada a qualquer momento. Portanto, o código deve ser resiliente e a maior parte das importações retomável. Isso significa que, se o código for executado novamente, ele não deve ser start do início novamente, mas sim do ponto em que parou. Embora este não seja um requisito novo para esse tipo de código, em AEM como Cloud Service é mais provável que ocorra uma derrubada de instância.

Para minimizar os problemas, devem ser evitados trabalhos de longa duração, se possível, e eles devem ser retomados no mínimo. Para executar esses trabalhos, use os Trabalhos Sling, que têm uma garantia pelo menos uma vez e, portanto, se forem interrompidos, serão executados novamente o mais rápido possível. Mas eles provavelmente não deveriam start desde o início novamente. Para agendar esses trabalhos, é melhor usar o scheduler Sling Jobs como novamente a execução pelo menos uma vez.

O Scheduler Sling Commons não deve ser usado para agendamento, pois a execução não pode ser garantida. É mais provável que seja agendada.

Da mesma forma, com tudo o que está a acontecer de forma assíncrona, como atuar sobre eventos de observação (quer seja, eventos de JCR ou eventos de recursos de Sling), não se pode garantir que seja executado e, portanto, deve ser usado com cuidado. Isso já é válido para implantações AEM no presente.

Conexões HTTP de Saída

É altamente recomendável que todas as conexões HTTP de saída definam tempos limite de conexão e leitura razoáveis. Para códigos que não aplicam esses tempos limite, instâncias AEM executadas em AEM como Cloud Service, imporão um tempo limite global. Esses valores de tempo limite são de 10 segundos para chamadas de conexão e 60 segundos para chamadas de leitura para conexões usadas pelas seguintes bibliotecas Java populares:

O Adobe recomenda o uso da biblioteca do Apache HttpComponents Client 4.x fornecida para fazer conexões HTTP.

As alternativas que são conhecidas por funcionarem, mas que podem exigir que a dependência seja fornecida por você mesmo, são:

Nenhuma personalização de interface clássica

AEM como Cloud Service só suporta a interface de usuário de toque para código de cliente de terceiros. A interface clássica não está disponível para personalização.

Evitar Binários Nativos

O código não poderá baixar binários em tempo de execução nem modificá-los. Por exemplo, ele não poderá desempacotar arquivos jar ou tar.

Nenhum vínculo de transmissão por AEM como Cloud Service

Os binários devem ser acessados por meio do CDN, que disponibilizará binários fora dos principais serviços de AEM.

Por exemplo, não use asset.getOriginal().getStream(), o que aciona o download de um binário no disco efêmero do serviço AEM.

Nenhum agente de replicação reverso

A replicação reversa de Publicar para Autor não é suportada em AEM como Cloud Service. Se tal estratégia for necessária, você poderá usar um armazenamento de persistência externo que seja compartilhado entre o farm de instâncias de Publicação e, potencialmente, o cluster Autor.

Os agentes de replicação encaminhados podem precisar ser portados

O conteúdo é replicado de Autor para Publicar por meio de um mecanismo de sub-publicação. Não há suporte para agentes de replicação personalizados.

Monitoramento e depuração

Logs

Para desenvolvimento local, as entradas de registros são gravadas em arquivos locais na pasta /crx-quickstart/logs.

Nos ambientes da Cloud, os desenvolvedores podem baixar os logs por meio do Cloud Manager ou usar uma ferramenta de linha de comando para rastrear os logs.

Configuração do nível de log

Para alterar os níveis de log dos ambientes do Cloud, a configuração de Sling Logging OSGI deve ser modificada, seguida de uma reimplantação completa. Como isso não é instantâneo, tenha cuidado ao ativar registros detalhados em ambientes de produção que recebem muito tráfego. No futuro, é possível que haja mecanismos para mudar mais rapidamente o nível de log.

Observação

Para executar as alterações de configuração listadas abaixo, é necessário criá-las em um ambiente de desenvolvimento local e depois enviá-las para um AEM como uma instância Cloud Service. Para obter mais informações sobre como fazer isso, consulte Implantação para AEM como Cloud Service.

Ativando o nível de log DEBUG

O nível de log padrão é INFO, ou seja, as mensagens DEBUG não são registradas.
Para ativar o nível de log DEBUG, defina a variável

/libs/sling/config/org.apache.sling.commons.log.LogManager/org.apache.sling.commons.log.level

propriedade para depurar. Não deixe o log no nível de log DEBUG mais tempo do que o necessário, pois ele gera muitos logs.
Uma linha no arquivo de depuração geralmente é start com DEBUG e, em seguida, fornece o nível de log, a ação do instalador e a mensagem de log. Por exemplo:

DEBUG 3 WebApp Panel: WebApp successfully deployed

Os níveis de log são os seguintes:

0 Erro fatal A ação falhou e o instalador não pode continuar.
1 Erro A ação falhou. A instalação continua, mas uma parte do CRX não foi instalada corretamente e não funcionará.
2 Aviso A ação foi bem-sucedida, mas encontrou problemas. O CRX pode ou não funcionar corretamente.
3 Info A ação foi bem sucedida.

Thread Dumps

Os despejos de processos em ambientes da Cloud são coletados de forma contínua, mas não podem ser baixados de maneira automática no momento. Enquanto isso, entre em contato com AEM suporte se os despejos por thread forem necessários para depurar um problema, especificando a janela de hora exata.

CRX/DE Lite e console do sistema

Desenvolvimento local

Para o desenvolvimento local, os desenvolvedores têm acesso total ao CRXDE Lite (/crx/de) e ao Console da Web AEM (/system/console).

Observe que no desenvolvimento local (usando o recurso de início rápido pronto para nuvem), /apps e /libs podem ser gravados diretamente, o que é diferente dos ambientes da nuvem nos quais as pastas de nível superior são imutáveis.

AEM como ferramentas de desenvolvimento de Cloud Service

Os clientes podem acessar a lista CRXDE no ambiente de desenvolvimento, mas não no estágio ou na produção. O repositório imutável (/libs, /apps) não pode ser gravado no tempo de execução, portanto, tentar fazer isso resultará em erros.

Um conjunto de ferramentas para depurar AEM como ambientes de desenvolvedor de Cloud Service no Developer Console para ambientes dev, stage e production. O url pode ser determinado ajustando-se as urls do serviço Autor ou Publicação da seguinte maneira:

https://dev-console/-<namespace>.<cluster>.dev.adobeaemcloud.com

Como atalho, o seguinte comando da CLI do Gerenciador de nuvem pode ser usado para iniciar o console do desenvolvedor com base em um parâmetro de ambiente descrito abaixo:

aio cloudmanager:open-developer-console <ENVIRONMENTID> --programId <PROGRAMID>

Consulte esta página para obter mais informações.

Os desenvolvedores podem gerar informações de status e resolver vários recursos.

Como ilustrado abaixo, as informações de status disponíveis incluem o estado de pacotes, componentes, configurações OSGI, índices de carvalho, serviços OSGI e trabalhos Sling.

Console de desenvolvedor 1

Como ilustrado abaixo, os desenvolvedores podem resolver dependências de pacote e servlets:

Console de desenvolvedor 2

Console de desenvolvedor 3

Também útil para depuração, o console Desenvolvedor tem um link para a ferramenta Explorar Query:

Console de desenvolvedor 4

Para programas regulares, o acesso ao Console do desenvolvedor é definido pelo "Gerenciador de nuvem - Função do desenvolvedor" no Admin Console, enquanto para programas de caixa de proteção, o Console do desenvolvedor está disponível para qualquer usuário com um perfil de produto que fornece acesso ao AEM como um Cloud Service. Para todos os programas, "Gerenciador de nuvem - Função do desenvolvedor" é necessário para os despejos de status e os usuários também devem ser definidos no Perfil Usuários AEM ou Administradores AEM nos serviços de autor e publicação para que os dados de despejo de status sejam visualizações de ambos os serviços. Para obter mais informações sobre como configurar permissões de usuário, consulte Documentação do Cloud Manager.

AEM Serviço de armazenamento temporário e produção

Os clientes não terão acesso à ferramenta para desenvolvedores para ambientes de preparo e produção.

Monitoramento de desempenho

O Adobe monitora o desempenho do aplicativo e toma medidas para resolver se a deterioração é observada. No momento, as métricas do aplicativo não podem ser observadas.

Endereço IP de saída dedicado

Mediante solicitação, o AEM como Cloud Service fornecerá um endereço IP estático e dedicado para HTTP (porta 80) e HTTPS (porta 443) de saída programado no código Java.

Benefícios

Esse endereço IP dedicado pode melhorar a segurança ao integrar-se com fornecedores SaaS (como um fornecedor de CRM) ou outras integrações fora do AEM como uma Cloud Service que oferta uma lista de permissões de endereços IP. Ao adicionar o endereço IP dedicado à lista de permissões, ele garante que somente o tráfego do Cloud Service do cliente AEM possa fluir para o serviço externo. Além do tráfego de outros IPs permitidos.

Sem o recurso de endereço IP dedicado ativado, o tráfego que sai do AEM como um Cloud Service continua por meio de um conjunto de IPs compartilhados com outros clientes.

Configuração

Para ativar um endereço IP dedicado, envie uma solicitação ao Suporte ao cliente, que fornecerá as informações do endereço IP. A solicitação deve especificar cada ambiente e solicitações adicionais devem ser feitas se novos ambientes precisarem do recurso após a solicitação inicial. Ambientes de programa Sandbox não são suportados.

Uso de recursos

O recurso é compatível com código Java ou bibliotecas que resultam em tráfego externo, desde que usem propriedades padrão do sistema Java para configurações de proxy. Na prática, isso deveria incluir a maioria das bibliotecas comuns.

Abaixo está uma amostra de código:

public JSONObject getJsonObject(String relativePath, String queryString) throws IOException, JSONException {
  String relativeUri = queryString.isEmpty() ? relativePath : (relativePath + '?' + queryString);
  URL finalUrl = endpointUri.resolve(relativeUri).toURL();
  URLConnection connection = finalUrl.openConnection();
  connection.addRequestProperty("Accept", "application/json");
  connection.addRequestProperty("X-API-KEY", apiKey);

  try (InputStream responseStream = connection.getInputStream(); Reader responseReader = new BufferedReader(new InputStreamReader(responseStream, Charsets.UTF_8))) {
    return new JSONObject(new JSONTokener(responseReader));
  }
}

O mesmo IP dedicado é aplicado a todos os programas de um cliente em sua Organização de Adobe e a todos os ambientes em cada um dos programas. Isso se aplica tanto aos serviços de autor quanto aos serviços de publicação.

Somente as portas HTTP e HTTPS são suportadas. Isso inclui HTTP/1.1, bem como HTTP/2 quando criptografado.

Considerações sobre depuração

Para validar se o tráfego está de fato saindo no endereço IP dedicado esperado, verifique os logs no serviço de destino, se disponível. Caso contrário, pode ser útil chamar um serviço de depuração como https://ifconfig.me/ip, que retornará o endereço IP de chamada.

Enviando email

AEM como Cloud Service requer que o correio externo seja criptografado. As seções abaixo descrevem como solicitar, configurar e enviar emails.

Solicitando acesso

Por padrão, o email de saída está desativado. Para ativá-lo, envie um ticket de suporte com:

  1. O nome de domínio totalmente qualificado para o servidor de email (por exemplo smtp.sendgrid.net)
  2. A porta a ser usada. Deve ser a porta 465 se for suportada pelo servidor de correio; caso contrário, a porta 587 Observe que a porta 587 só pode ser usada se o servidor de correio exigir e impor o TLS nessa porta
  3. A ID do programa e a ID do ambiente dos ambientes dos quais eles gostariam de enviar emails
  4. Se o acesso SMTP é necessário para o autor, publicação ou ambos.

Enviando emails

O serviço OSGI Day CQ Mail Service deve ser usado e os emails devem ser enviados para o servidor de correio indicado na solicitação de suporte, em vez de diretamente para os recipient.

AEM CS requer que o correio seja enviado pela porta 465. Se um servidor de correio não suportar a porta 465, a porta 587 poderá ser usada, desde que a opção TLS esteja ativada.

Observação

Observe que o Adobe não oferece suporte para o agrupamento SMTP em um endereço IP exclusivo.

Configuração

Os emails no AEM devem ser enviados usando o serviço OSGi do Day CQ Mail Service.

Consulte AEM documentação 6.5 para obter detalhes sobre como configurar as configurações de email. Para AEM CS, os seguintes ajustes devem ser feitos no serviço com.day.cq.mailer.DefaultMailService OSGI:

Se a porta 465 tiver sido solicitada:

  • definir smtp.port como 465
  • definir smtp.ssl como true
  • definir smtp.starttls como false

Se a porta 587 tiver sido solicitada (somente permitida se o servidor de email não suportar a porta 465):

  • definir smtp.port como 587
  • definir smtp.ssl como false
  • definir smtp.starttls como true

Nesta página