Visão geral do provedor de recursos de armazenamento storage-resource-provider-overview

Introdução introduction

A partir do AEM Communities 6.1, o conteúdo da comunidade, comumente chamado de conteúdo gerado pelo usuário (UGC), é armazenado em uma única loja comum fornecida por um provedor de recursos de armazenamento (SRP).

Há várias opções de SRP, todas acessando o UGC por meio de uma nova interface do AEM Communities, a API do SocialResourceProvider (API SRP), que inclui todas as operações de criação, leitura, atualização e exclusão (CRUD).

Todos os componentes do SCF são implementados usando a API do SRP, permitindo que o código seja desenvolvido sem o conhecimento de topologia subjacente ou local do UGC.

A API SocialResourceProvider está disponível somente para clientes licenciados do AEM Communities.

Consulte também:

Sobre o Repositório about-the-repository

Para entender o SRP, é útil entender a função do repositório de AEM (OAK) em um site da comunidade AEM.

Java Content Repository (JCR)
Esse padrão define um modelo de dados e uma interface de programação de aplicativos (API JCR) para repositórios de conteúdo. Ele combina características de sistemas de arquivos convencionais com as de bancos de dados relacionais e adiciona vários recursos adicionais que os aplicativos de conteúdo geralmente precisam.

Uma implementação do JCR é o repositório AEM, OAK.

Apache Jackrabbit Oak (OAK)
OAK O é uma implementação do JCR 2.0 que é um sistema de armazenamento de dados criado especificamente para aplicativos centrados em conteúdo. É um tipo de banco de dados hierárquico projetado para dados não estruturados e semiestruturados. O repositório armazena não apenas o conteúdo voltado para o usuário, mas também todos os códigos, modelos e dados internos usados pelo aplicativo. A interface do usuário para acessar conteúdo é CRXDE Lite.

JCR e OAK normalmente são usados para se referir ao repositório AEM.

Depois de desenvolver o conteúdo do site no ambiente de autor privado, ele deve ser copiado para o ambiente de publicação público. Isso geralmente é feito por meio de uma operação chamada replicação. Isso acontece sob controle do autor/desenvolvedor/administrador.

Para o UGC, o conteúdo é inserido por visitantes do site registrados (membros da comunidade) no ambiente de publicação público. Isso acontece aleatoriamente.

Para fins de gerenciamento e relatórios, é útil ter acesso ao UGC a partir do ambiente de criação privado. Com o SRP, o acesso ao UGC do autor é mais consistente e eficaz, pois a replicação reversa da publicação para o autor não é necessária.

Sobre SRP about-srp

Quando o UGC é salvo no armazenamento compartilhado, há uma única instância do conteúdo do membro que pode, na maioria das implantações, ser acessada dos ambientes do autor e de publicação. Independentemente da escolha de SRP (MSRP, ASRP, JSRP), todas devem ser acessadas programaticamente com a API do SRP.

ASRP asrp

No caso de ASRP, o UGC não é armazenado no JCR, ele é armazenado em um serviço de nuvem hospedado e gerenciado pelo Adobe. O UGC armazenado no ASRP não pode ser visualizado com o CRXDE Lite nem acessado usando a API do JCR.

Consulte ASRP - Provedor de Recursos de Armazenamento Adobe.

Não é possível para os desenvolvedores acessar o UGC diretamente.

O ASRP usa a nuvem Adobe para consultas.

MSRP msrp

No caso de MSRP, o UGC não é armazenado no JCR, ele é armazenado no MongoDB. O UGC armazenado no MSRP não pode ser visualizado com o CRXDE Lite nem acessado usando a API do JCR.

Consulte MSRP - Provedor de recursos de armazenamento MongoDB.

Embora o MSRP seja comparável ao ASRP, como todas as instâncias de servidor AEM estão acessando o mesmo UGC, é possível usar ferramentas comuns para acessar diretamente o UGC armazenado no MongoDB.

O MSRP usa o Solr para consultas.

JSRP jsrp

O JSRP é o provedor padrão para acessar todos os UGC em uma única instância de AEM. Ele fornece a capacidade de experimentar rapidamente o AEM Communities 6.1 sem a necessidade de configurar o MSRP ou o ASRP.

Consulte JSRP - Provedor de recursos de armazenamento JCR.

No caso do JSRP, embora o UGC seja armazenado no JCR e acessível por meio da API do CRXDE Lite e do JCR, é altamente recomendável que a API do JCR nunca seja usada para fazer isso, caso contrário, alterações futuras podem afetar o código personalizado.

Além disso, o repositório dos ambientes de criação e publicação não é compartilhado. Embora um cluster de instâncias de publicação resulte em um repositório de publicação compartilhado, o UGC inserido na publicação não estará visível no autor, portanto, não há capacidade de gerenciar o UGC do autor. O UGC só é persistente no repositório AEM (JCR) da instância em que foi inserido.

O JSRP usa os índices Oak para consultas.

Sobre nós de sombra no JCR about-shadow-nodes-in-jcr

Os nós de sombra, que imitam o caminho para o UGC, existem no repositório local para servir dois propósitos:

Independentemente da implementação do SRP, o UGC real *não será *visível no mesmo local que o nó de sombra.

Para Controle de Acesso (ACLs) for-access-control-acls

Algumas implementações de SRP, como ASRP e MSRP, armazenam o conteúdo da comunidade em bancos de dados que não fornecem verificação de ACL. Os nós de sombra fornecem um local no repositório local ao qual as ACLs podem ser aplicadas.

Usando a API SRP, todas as opções de SRP executam a mesma verificação do local de sombra antes de todas as operações de CRUD.

A verificação da ACL usa um método de utilitário que retorna um caminho adequado para verificar as permissões aplicadas ao UGC do recurso.

Consulte Princípios básicos de SRP e UGC para código de amostra.

Para recursos não existentes (NERs) for-non-existing-resources-ners

Alguns componentes das Comunidades podem ser incluídos em um script e, portanto, exigem um nó endereçável do Sling para suportar recursos das Comunidades. Componentes incluídos são designados por recursos não existentes (NERs).

Os nós de sombra fornecem um local endereçável do Sling no repositório.

Local de armazenamento storage-location

A seguir, um exemplo de um nó de sombra, usando o Componente Comentários no Guia de componentes da comunidade:

Nenhum UGC será encontrado sob o nó de sombra.

O comportamento padrão é configurar nós de sombra em uma instância de publicação sempre que a subárvore relevante for referenciada para leitura ou gravação.

Por exemplo, suponha que a implantação seja MSRP com um farm de publicação TarMK.

Quando uma membro posta UGC no pub1 (armazenado no MongoDB), os nós de sombra são criados no JCR no pub1.

Na primeira vez que o UGC é lido no pub2, se nada for configurado, o comportamento padrão é criar os nós de sombra.

Se desejar outro comportamento diferente do padrão, ele deve ser configurado na instância de autor e encaminhado para todas as instâncias de publicação, que normalmente é um processo manual.