Panoramica del provider di risorse di storage storage-resource-provider-overview

Introduzione introduction

A partire da AEM Communities 6.1, il contenuto della community, comunemente denominato contenuto generato dall’utente (UGC), viene memorizzato in un singolo archivio comune fornito da un provider di risorse di archiviazione (SRP).

Sono disponibili diverse opzioni SRP, tutte con accesso a UGC tramite una nuova interfaccia AEM Communities, la API SocialResourceProvider (API SRP), che include tutte le operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD).

Tutti i componenti SCF sono implementati utilizzando l’API SRP, consentendo lo sviluppo del codice senza conoscere né l’API topologia sottostante o la posizione dell'UGC.

L'API SocialResourceProvider è disponibile solo per i clienti con licenza di AEM Communities.

Consulta anche:

Informazioni sull’archivio about-the-repository

Per comprendere l’SRP, è utile comprendere il ruolo dell’archivio AEM (OAK) in un sito della community AEM.

Java Content Repository (JCR)
Questo standard definisce un modello dati e un'interfaccia di programmazione dell'applicazione (API JCR) per gli archivi di contenuti. Combina le caratteristiche dei file system convenzionali con quelle dei database relazionali e aggiunge una serie di funzioni aggiuntive di cui spesso le applicazioni di contenuti hanno bisogno.

Un’implementazione di JCR è l’archivio AEM, OAK.

Apache Jackrabbit Oak (OAK)
OAK è un’implementazione di JCR 2.0 che è un sistema di storage dei dati appositamente progettato per applicazioni incentrate sui contenuti. È un tipo di database gerarchico progettato per dati non strutturati e semi-strutturati. Il repository memorizza non solo il contenuto rivolto all'utente, ma anche tutto il codice, i modelli e i dati interni utilizzati dall'applicazione. L’interfaccia utente per accedere ai contenuti è CRXDE Lite.

Sia JCR che OAK sono generalmente utilizzati per fare riferimento all’archivio AEM.

Dopo aver sviluppato il contenuto del sito nell’ambiente di authoring privato, deve essere copiato nell’ambiente di pubblicazione pubblico. Questa operazione viene spesso eseguita tramite un’operazione denominata replica. Questo accade sotto il controllo dell'autore/sviluppatore/amministratore.

Per UGC, il contenuto è inserito dai visitatori registrati del sito (membri della community) nell’ambiente di pubblicazione pubblico. Questo succede in modo casuale.

Ai fini della gestione e del reporting, è utile avere accesso a UGC dall’ambiente di authoring privato. Con l’SRP, l’accesso a UGC dall’autore è più coerente e performante, in quanto la replica inversa da pubblicazione all’autore non è necessaria.

Informazioni sull’SRP about-srp

Quando UGC viene salvato nello storage condiviso, esiste una singola istanza di contenuto membro a cui è possibile accedere, nella maggior parte delle distribuzioni, sia dagli ambienti di authoring che di pubblicazione. Indipendentemente dalla scelta dell’SRP (MSRP, ASRP, JSRP), è necessario accedere a tutti a livello di programmazione con l’API SRP.

ASRP asrp

Nel caso di ASRP, UGC non è memorizzato in JCR, viene memorizzato in un servizio cloud ospitato e gestito da Adobe. Gli UGC memorizzati in ASRP non possono essere visualizzati con CRXDE Lite né utilizzati con l’API JCR.

Vedi ASRP - Provider risorsa di archiviazione Adobe.

Non è possibile per gli sviluppatori accedere direttamente all’UGC.

ASRP utilizza Adobe cloud per le query.

MSRP msrp

Nel caso di MSRP, UGC non è memorizzato in JCR, è memorizzato in MongoDB. Gli UGC memorizzati in MSRP non possono essere visualizzati con CRXDE Lite né utilizzati con l’API JCR.

Vedi MSRP - Provider risorsa di archiviazione MongoDB.

Mentre MSRP è paragonabile ad ASRP, poiché tutte le istanze AEM server stanno accedendo allo stesso UGC, è possibile utilizzare strumenti comuni per accedere direttamente all'UGC memorizzato in MongoDB.

MSRP utilizza Solr per le query.

JSRP jsrp

JSRP è il provider predefinito per accedere a tutti gli UGC su una singola istanza AEM. Fornisce la possibilità di sperimentare rapidamente AEM Communities 6.1 senza la necessità di configurare MSRP o ASRP.

Vedi JSRP - Provider risorsa di archiviazione JCR.

Nel caso di JSRP, mentre UGC è memorizzato in JCR e accessibile tramite sia CRXDE Lite che JCR API, si consiglia vivamente di non utilizzare mai l’API JCR per farlo, altrimenti le modifiche future potrebbero influenzare il codice personalizzato.

Inoltre, l’archivio per gli ambienti di authoring e pubblicazione non è condiviso. Mentre un cluster di istanze di pubblicazione genera un archivio di pubblicazione condiviso, l'UGC immesso al momento della pubblicazione non sarà visibile sull'autore, quindi non è possibile gestire l'UGC dall'autore. UGC viene mantenuto solo nell’archivio AEM (JCR) dell’istanza in cui è stato inserito.

JSRP utilizza gli indici Oak per le query.

Informazioni sui nodi ombra in JCR about-shadow-nodes-in-jcr

I nodi shadow, che imitano il percorso dell'UGC, esistono nell'archivio locale per due scopi:

Indipendentemente dall'implementazione SRP, l'UGC effettivo *non *sarà visibile nella stessa posizione del nodo ombra.

Per controllo accessi (ACL) for-access-control-acls

Alcune implementazioni SRP, come ASRP e MSRP, memorizzano il contenuto della community nei database che non forniscono alcuna verifica ACL. I nodi shadow forniscono una posizione nell'archivio locale a cui possono essere applicate le ACL.

Utilizzando l’API SRP, tutte le opzioni SRP eseguono lo stesso controllo della posizione shadow prima di tutte le operazioni CRUD.

Il controllo ACL utilizza un metodo di utilità che restituisce un percorso adatto per controllare le autorizzazioni applicate all'UGC della risorsa.

Vedi Essenze SRP e UGC per codice di esempio.

Per risorse non esistenti (NER) for-non-existing-resources-ners

Alcuni componenti di Communities sono inclusi all'interno di uno script e quindi richiedono un nodo indirizzabile Sling per supportare le funzioni di Communities. Componenti inclusi sono definite risorse non esistenti (NER).

I nodi shadow forniscono una posizione indirizzabile Sling nell'archivio.

Percorso di archiviazione storage-location

Di seguito è riportato un esempio di nodo shadow, utilizzando Componente Commenti in Guida ai componenti della community:

Non verrà trovato alcun UGC sotto il nodo ombra.

Il comportamento predefinito consiste nell’impostare i nodi shadow in un’istanza di pubblicazione ogni volta che si fa riferimento alla relativa sottostruttura per una lettura o scrittura.

Ad esempio, supponiamo che la distribuzione sia MSRP con una farm di pubblicazione TarMK.

Quando un membro post UGC su pub1 (memorizzato in MongoDB), i nodi shadow vengono creati in JCR su pub1.

La prima volta che l'UGC viene letto su pub2, se non è impostato nulla, il comportamento predefinito è quello di creare i nodi shadow.

Se desideri un comportamento diverso da quello predefinito, devi configurarlo nell’istanza di authoring e inoltrarlo a tutte le istanze di pubblicazione, che in genere è un processo manuale.