DEV Community

Beatriz Maciel
Beatriz Maciel

Posted on • Edited on

10

Série: AEM para iniciantes | 🇧🇷

Esta é uma série de publicações em Português/BR para auxiliar as vídeo aulas e os conceitos apresentados no site da Adobe.com sobre AEM (Adobe Experience Manager). Este material não é da Adobe e sim uma tradução livre dos conceitos apresentados no treinamento deles e tem como intuito ajudar a guiar os primeiros passos do(a) programador(a) que precisa de um guia em português.
Fiz esse conteúdo em parceria com a Lorena Gomes, desenvolvedora AEM/Java e minha colega.

O que é o Adobe Experience Manager (AEM)?

O Adobe Experience Manager (AEM) é uma solução abrangente de gerenciamento de conteúdo para criar sites, aplicativos móveis e formulários. O AEM facilita o gerenciamento de conteúdo e ativos de marketing. (Fonte: Adobe)
Ele é popularmente conhecido como um CMS (Content Management Systems) e pretende integrar diversas funcionalidades para facilitar e automatizar a publicação de sites e aplicativos.

Quais são os ambientes do AEM?

Author e Publish Tier. Geralmente usamos o ambiente Author no dia a dia.

Camada de "Author": é usado para criação, envio e edição de conteúdo e para administrar o site.

Camada de "Publish": é utilizado para disponibilizar o conteúdo.

Java Content Repository (JCR)

O JCR é um gerenciador do Sistema de arquivos do AEM. Gerencia cada nodo que tem suas propriedades, extensões/tipos e usuários.
O JCR também mascara a informação para proteger e disponibilizar na sua própria plataforma.

É formado por:

  • Tree structure (estrutura em árvore)

-- Os nodos proporcionam estrutura;
-- Propriedades guardam os dados;

  • Organized in paths (organizado em "caminhos");

Estrutura JCR
Nodos e Propriedades

O que é o Apache Sling?

Sobre o Sling
É uma aplicação web baseada em princípios REST¹ que disponibilizam fácil desenvolvimento de aplicações de conteúdo orientado. O Sling usa um repositório JCR, como o Apache Jackrabbit, ou, no caso do AEM, o CRX Content Repository como banco de dados.
Ao utilizarmos o Sling, preterimos o tipo do conteúdo em detrimento da resolução da URL através de um script the renderiza esse mesmo conteúdo. Em outras palavras: o tipo do conteúdo é menos importante quando temos um script que o "traduz" através de performance de renderização.
Isso traz flexibilidade e agilidade e nós podemos tratar de diferentes tipos de conteúdos, facilitando a customização das páginas.

Em síntese, o Sling:

  • Converte e renderiza as informações
  • Pega recursos e converte em HTML e JSON

Apache Sling Script Resolution

A imagem acima descreve a resolução do script Sling e mostra como ele captura uma requisição HTTP de um nodo de conteúdo (content node) transformando-a em resource type (tipo de recurso, em tradução literal) e, posteriormente, em script.

A imagem a seguir descreve os parâmetros de requisição "escondidos" que podemos usar no SlingPostServlet. O SlingPostServelet é o artifício utilizado de forma padrão para todas as requisições POST e dá infinitas opções de criação, modificação e mobilidade de nodos no repositório.

Using SlingPostServlet

Exemplo de decomposição da URL e significados:

URL decomposition Sling

procotol HTTP

host Nome do website

content path O "caminho" específico do conteúdo a ser renderizado. É usado em combinação com a extensão; neste exemplos temos o tools/spy.html

selector(s) Usado para métodos alternativos de renderização de conteúdo; neste exemplo um formato de impressão A4

extension Formato do conteúdo; também especifica o script a ser usado para renderização

suffix Pode ser usado para informação adicional

param(s) Qualquer parâmetro necessário para conteúdo dinâmico

A figura abaixo mostra o mecanismo usado:

Sling Mechanism

Com o Sling, podemos especificar qual script renderiza uma entidade determinada (através da propriedade sling:resourceType no nodo JCR). Esse mecanismo oferece mais liberdade para qualquer um que acesse o script nas entidades de dados (como a demonstração SQL em um script PHP faria) como um recurso que pode ter diversas interpretações ou formas de utilização.

Localizando o Script

Quando o recurso apropriado (o conteúdo do nodo) é localizado, o sling resource type é extraído. É aí que temos o path (caminho) que localiza o script que será utilizado para renderizar o conteúdo.

O path é especificado pelo sling:resourceType e pode ser tanto 1. absoluto ou 2. relativo a um parâmetro de configuração.

Observação: Os paths relativos são recomendados pela Adobe pela sua portabilidade aumentada.

Além do sling:resourceType, há também o `sling:resourceSuperType. O Super Type geralmente indica uma propriedade e é utilizado para "procurar" um script através da hierarquia dos recursos, podendo reutilizar propriedades (de um nodo ou não, também podem ser propriedades herdadas diretamente da root - chamamos de default a root, também).

Exemplo:

String:resourceSuperType

Todos os scripts do Sling ficam guardados em subpastas em /apps ou em /libs.

Alguns outros pontos relevantes:

  • Quando um Método (GET, POST) é necessário ele será especificado em letras maiúsculas de acordo com os parâmetros HTTP. Ex: jobs.POST.esp
  • Várias engenharias de scripts são suportadas:
    -- HTL (É a preferida e recomendada pelo AEM para o server-side template system HTML) .html

    -- ECMAScript (JavaScript) Pages .esp, .ecma

    -- Java Server Pages .jsp

    -- Java Servlet Compiler .java

    -- JavaScript templates .jst

Entretanto, o Apache Sling também suporta a integração com outros scripts, tais como o Groovy, JRuby e o Freemaker.

O que é OSGi?

O Open Services Gateway initiative (OSGi):

É uma arquitetura modular dinâmica que facilita a implementação e desenvolvimento, cria sistemas a partir de módulos internos e externos, com componentes pré definidos, reduzindo a complexidade do desenvolvimento.
O container OSGi permite que quebremos nossa aplicação em módulos individuais (em arquivos jar com meta informação adicional, chamados de bundles) e administremos as dependências cruzadas entre elas com:

  • Serviços implementados dentro do container OSGi
  • Um contrato entre o container e a sua aplicação

Esses serviços e contratos permitem que os elementos individuais descubram dinamicamente um ao outro para colaborarem entre si.

OSGI

  • Controla os composite bundles (pacotes);
  • Componentes pequenos, reutilizáveis e colaborativos;
  • Cada componente OSGi é contido em um bundle;

O Sling usa a implementação do framework Apache Felix para o OSGi.

Bundles

  • É um arquivo JAR com metadata adicional
  • Disponibiliza (promove) componentes (podem ter um ou mais componentes)

Bundles

Estrutura de um Repositório

  • /apps
    Relacionado à aplicação. Inclui definições de componentes específicas para o seu website. Os componentes que você desenvolve podem ser baseados nos componentes disponíveis em /libs/foundation/components

  • /content
    Conteúdo criado para o seu website.

  • /etc

  • /home
    Informação de Grupo e de Usuário

  • /libs
    Bibliotecas e definições que pertencem ao core do AEM. As subpastas em /libs representam as features que podem ser utilizadas prontamente do AEM, como busca ou replicação. O conteúdo em /libs não deve ser modificado, uma vez que isso pode afetar a forma como AEM trabalha. Features feitas especificamente para o seu website devem ser desenvolvidas no /apps.

  • /tmp
    Área de trabalho temporária

  • /var
    Arquivos que mudam e são atualizados pelo sistema, como os audit logs, estatísticas e os event-handling.

O que o Dispatcher?

O Dispatcher é uma ferramenta de armazenamento em cache e/ou balanceamento de carga do Adobe Experience Manager, que pode ser usado em conjunto com um servidor Web de classe empresarial, ajudando a melhorar o desempenho de resposta do site (saiba mais aqui).

Catching and load-balancing tool

  • Converte o conteúdo em HTML estático
  • Caches static assets (armazena assets estáticos)
  • Conteúdo pode ser despejado por um agente de replicação AEM
  • Ambiente rápido e dinâmico
  • É um plug-in de web server disponibilizado para o Apache e para Internet Information Server (IIS)

Dispatcher

  • Pode ter vários autores, que controlam a área de autores (em preto)
  • Depois tem a fase de Publish e, por fim, vai para o web server

Dispatcher II

O visitante acessa o site e faz um document request. Essa requisição vai para o web server e se há disponibilidade de módulo, é aceita.

Passo 1: a requisição é cacheable?
Se não, vai para o publish e renderiza o documento. Se sim, passa pela segunda perfunta.
Passo 2: a requisição já está armazenada (cached)?
Passo 3: a requisição está cached e está atualizada? Se sim, leva o documento para o dispatcher novamente.

========

Questões finais:

Qual ambiente é usado para administrar o workflow?
Author

Qual é o benefício de usar o JCR?
Guarda conteúdo em estruturas hierárquicas

Qual é o framework web no AEM Stack?
Apache Sling

Quem disponibiliza o container Java no AEM Stack?
OSGi

Quais são as funcionalidades do Dispatcher?
Load balancing, Security e Caching,

Load balancing --> distribuir carga

========

¹ Uma API REST é um conjunto de restrições de arquitetura. Significa "Transferência de Estado Representacional" (Representational State Transfer).

========

Conteúdo e referências:

Solution Partners - AEM training : Adobe
Adobe 6.5 : Adobe
Experience Cloud : Adobe
Core Concepts : Adobe
Discover Sling in 5 minutes : Apache
API REST : BeCode

Top comments (0)

Great read:

Is it Time to go Back to the Monolith?

History repeats itself. Everything old is new again and I’ve been around long enough to see ideas discarded, rediscovered and return triumphantly to overtake the fad. In recent years SQL has made a tremendous comeback from the dead. We love relational databases all over again. I think the Monolith will have its space odyssey moment again. Microservices and serverless are trends pushed by the cloud vendors, designed to sell us more cloud computing resources.

Microservices make very little sense financially for most use cases. Yes, they can ramp down. But when they scale up, they pay the costs in dividends. The increased observability costs alone line the pockets of the “big cloud” vendors.