Show Menu
ARGOMENTI×

Panoramica del provider di risorse di storage

Introduzione

A partire AEM Communities 6.1, i contenuti della community, comunemente denominati contenuti generati dall'utente (UGC), vengono memorizzati in un unico store comune fornito da un provider di risorse di storage (SRP).
Esistono diverse opzioni SRP, tutte con accesso a UGC tramite una nuova interfaccia AEM Communities , l'API Funzioni di base SRP e UGC 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 la topologia Topologie consigliate per community sottostante o la posizione dell'UGC.
L'API SocialResourceProvider è disponibile solo per i clienti autorizzati di AEM Communities.
Componenti personalizzati: Per i clienti con licenza di AEM Communities, l'API SRP è disponibile per gli sviluppatori di componenti personalizzati allo scopo di accedere a UGC senza riguardo alla topologia sottostante. Vedere Funzioni di base SRP e UGC .
Consulta anche:

Informazioni sull'archivio

Per comprendere meglio SRP, è utile comprendere il ruolo del repository AEM (OAK) in un sito AEM community.
Java Content Repository (JCR) Questo standard definisce un modello dati e un'interfaccia di programmazione applicazione (API jcr-api.html JCR) per i repository dei contenuti. Unisce le caratteristiche dei file system convenzionali a quelle dei database relazionali e aggiunge una serie di funzioni aggiuntive spesso necessarie per le applicazioni di contenuto.
Un'implementazione di JCR è il repository AEM, OAK.
Apache Jackrabbit Oak (OAK) OAK è un'implementazione di JCR 2.0 che è un sistema di archiviazione dei dati appositamente progettato per applicazioni incentrate sui contenuti. È un tipo di database gerarchico progettato per dati non strutturati e semi-strutturati. L'archivio 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 al repository AEM.
Dopo aver sviluppato il contenuto del sito nell’ambiente di authoring privato, questo deve essere copiato nell’ambiente di pubblicazione pubblica. Questa operazione viene spesso eseguita tramite un'operazione denominata replica . Ciò avviene sotto il controllo dell'autore/sviluppatore/amministratore.
Per UGC, il contenuto è immesso dai visitatori registrati del sito (membri della community) nell'ambiente di pubblicazione pubblica. Questo succede in modo casuale.
Ai fini della gestione e del reporting, è utile avere accesso a UGC dall’ambiente di authoring privato. Con SRP, l’accesso a UGC dall’autore è più coerente e performante, in quanto non è necessaria la replica inversa dalla pubblicazione all’autore.

Informazioni su SRP

Quando UGC viene salvato nello storage condiviso, esiste un'unica istanza di contenuto membro a cui, nella maggior parte delle distribuzioni, è possibile accedere sia dall'ambiente di creazione che da quello di pubblicazione. Indipendentemente dalla scelta SRP (MSRP, ASRP, JSRP), l'accesso a tutti deve essere programmaticamente effettuato con l'API SRP.
Consulta SRP e UGC Essentials per un esempio di codice e ulteriori dettagli.
Consultate Accesso a UGC con SRP per le best practice di codifica.

ASRP

Nel caso di ASRP, UGC non è memorizzato in JCR, è memorizzato in un servizio cloud ospitato e gestito da Adobe. L'UGC memorizzato in ASRP non può essere visualizzato né con CRXDE Lite né accessibile tramite l'API JCR.
Consulta ASRP - provider di risorse di storage di Adobe.
Gli sviluppatori non possono accedere direttamente all'UGC.
ASRP utilizza Adobe cloud per le query.

MSRP

Nel caso di MSRP, UGC non è memorizzato in JCR, è memorizzato in MongoDB. L'UGC memorizzato in MSRP non può essere visualizzato né con CRXDE Lite né accessibile tramite l'API JCR.
Consultate MSRP - Fornitore di risorse di storage MongoDB.
Sebbene MSRP sia paragonabile ad ASRP, poiché tutte AEM istanze server accedono allo stesso UGC, è possibile utilizzare strumenti comuni per accedere direttamente all'UGC memorizzato in MongoDB.
MSRP utilizza Solr per le query.

JSRP

JSRP è il provider predefinito per l'accesso 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.
Consulta JSRP - Provider risorse di storage JCR.
Nel caso di JSRP, mentre UGC è memorizzato in JCR, e accessibile tramite API CRXDE Lite e JCR, è fortemente consigliato che l'API JCR non venga mai utilizzata per farlo, altrimenti le modifiche future potrebbero influenzare il codice personalizzato.
Inoltre, l’archivio per gli ambienti di creazione e pubblicazione non è condiviso. Mentre un cluster di istanze di pubblicazione genera un archivio condiviso di pubblicazione, gli UGC immessi al momento della pubblicazione non saranno visibili all’autore, per cui non è possibile gestire UGC dall’autore. UGC è persistente solo nell'archivio AEM (JCR) dell'istanza in cui è stato immesso.
JSRP utilizza gli indici Oak per le query.

Informazioni sui nodi ombra 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 il controllo degli accessi (ACL)

Alcune implementazioni SRP, come ASRP e MSRP, memorizzano il contenuto della community in database che non forniscono alcuna verifica ACL. I nodi shadow forniscono una posizione nell'archivio locale in cui è possibile applicare gli ACL.
Utilizzando l'API SRP, tutte le opzioni SRP eseguono lo stesso controllo della posizione dell'ombra prima di tutte le operazioni CRUD.
Il controllo ACL utilizza un metodo di utilità che restituisce un percorso adatto per verificare le autorizzazioni applicate all'UGC della risorsa.
Per un esempio di codice, vedi SRP e UGC Essentials .

Per risorse non esistenti (NER)

Alcuni componenti Community sono inclusi in uno script e richiedono quindi un nodo indirizzabile Sling per supportare le funzioni Community. I componenti inclusi sono denominati risorse non esistenti (NER).
I nodi shadow forniscono una posizione indirizzabile Sling nella directory archivio.
Poiché il nodo ombra ha più usi, la presenza di un nodo ombra non implica che il componente sia un NER.

Posizione di archiviazione

Di seguito è riportato un esempio di un nodo shadow, utilizzando il componente comments.html Commenti nella Guida ai componenti community:
  • Il componente esiste nell’archivio locale in:
    /content/community-components/en/comments/jcr:content/content/includable/comments
  • Il nodo shadow corrispondente esiste nel repository locale in:
    /content/usergenerated/content/community-components/en/comments/jcr:content/content/includable/comments
Non verrà trovato alcun UGC sotto il nodo shadow.
Il comportamento predefinito consiste nell’impostare i nodi ombra su un’istanza di pubblicazione ogni volta che viene fatto riferimento alla relativa sottostruttura ad albero per una lettura o una scrittura.
Ad esempio, se la distribuzione è MSRP con una farm di pubblicazione TarMK,
Quando un membro inserisce UGC su pub1 (memorizzato in MongoDB), i nodi ombra vengono creati in JCR su pub1.
La prima volta che l’UGC viene letto su pub2, se non è impostato nulla, il comportamento predefinito consiste nel creare i nodi ombra.
Se si desidera un comportamento diverso da quello predefinito, è necessario impostarlo sull’istanza di creazione e inoltrarlo a tutte le istanze di pubblicazione, che in genere è un processo manuale.