DEV Community

Beatriz Maciel
Beatriz Maciel

Posted on • Updated on

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

Oldest comments (0)