Panoramica del provider di risorse di archiviazione

Introduzione

A partire da AEM Communities 6.1, il contenuto della community, comunemente denominato user generated content (UGC), viene memorizzato in un unico archivio comune fornito da un provider di risorse di archiviazione (SRP)

Esistono diverse opzioni SRP, tutte accessibili da 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 vengono implementati utilizzando l’API SRP, consentendo lo sviluppo del codice senza la conoscenza di topologia sottostante o la posizione dell'UGC.

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

Consulta anche:

• Nozioni di base su SRP e UGC - Metodi ed esempi di utilità SRP.
• Accesso a UGC con SRP - Linee guida per la codifica.
• Refactoring SocialUtils - Mappatura dei metodi di utilità obsoleti sui metodi di utilità SRP correnti.

Informazioni sull’archivio

Per comprendere i criteri 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 le applicazioni di contenuti hanno spesso bisogno.

Un’implementazione del JCR è l’archivio dell’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. Si tratta di un tipo di database gerarchico progettato per i dati non strutturati e semistrutturati. 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 l’accesso al contenuto è CRXDE Lite.

Sia JCR che OAK vengono in genere 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. Questo viene spesso fatto attraverso un'operazione chiamata replica. Questo accade sotto il controllo dell’autore/sviluppatore/amministratore.

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

A scopo di gestione e reporting, è utile avere accesso a UGC dall’ambiente di authoring privato. Con SRP, l’accesso a UGC da Author è più coerente ed efficiente, in quanto non è necessaria la replica inversa da Publish a Author.

Informazioni su SRP

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

ASRP

Nel caso di ASRP, UGC non viene memorizzato in JCR, ma in un servizio cloud ospitato e gestito da Adobe. Le UGC memorizzate in ASRP non possono essere visualizzate con CRXDE Lite né accessibili utilizzando l’API JCR.

Consulta ASRP - Provider risorsa di archiviazione Adobe.

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

ASRP utilizza Adobe Cloud per le query.

MSRP

Nel caso di MSRP, UGC non viene memorizzato in JCR, ma in MongoDB. I contenuti generati dagli utenti (UGC) memorizzati in MSRP non possono essere visualizzati con CRXDE Lite né essere accessibili utilizzando l’API JCR.

Consulta MSRP - Provider risorsa di archiviazione MongoDB.

Anche se MSRP è paragonabile ad ASRP, poiché tutte le istanze del server AEM accedono allo stesso UGC, è possibile utilizzare strumenti comuni per accedere direttamente al UGC memorizzato in MongoDB.

MSRP utilizza Solr per le query.

JSRP

JSRP è il provider predefinito per l’accesso a tutti i contenuti generati dagli utenti su una singola istanza AEM. Consente di utilizzare rapidamente AEM Communities 6.1 senza la necessità di configurare MSRP o ASRP.

Consulta JSRP - Provider risorsa di archiviazione JCR.

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

Inoltre, l’archivio per gli ambienti di authoring e pubblicazione non è condiviso. Anche se un cluster di istanze di pubblicazione genera un archivio di pubblicazione condiviso, l’UGC immesso al momento della pubblicazione non sarà visibile nell’autore, pertanto non sarà possibile gestire l’UGC dall’autore. L’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

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

1. Controllo degli accessi (ACL)
2. Risorse non esistenti (NER)

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 a cui possono essere applicati gli ACL.

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

Il controllo ACL utilizza un metodo di utilità che restituisce un percorso adatto per la verifica delle autorizzazioni applicate all’UGC della risorsa.

Consulta Nozioni di base su SRP e UGC per il codice di esempio.

Per le risorse non esistenti (NER)

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

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

Percorso di archiviazione

Di seguito è riportato un esempio di nodo ombra che utilizza Componente Commenti nel Guida ai componenti della community:

• Il componente esiste nell’archivio locale in:

  /content/community-components/en/comments/jcr:content/content/includable/comments

• Il nodo shadow corrispondente esiste nell’archivio locale in:

  /content/usergenerated/content/community-components/en/comments/jcr:content/content/includable/comments

Non verrà trovato alcun contenuto generato dall'utente (UGC) nel nodo shadow.

Il comportamento predefinito consiste nell’impostare nodi shadow in un’istanza Publish ogni volta che si fa riferimento alla sottostruttura pertinente per una lettura o una 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 ombra vengono creati in JCR su pub1.

La prima volta che l'UGC viene letto su pub2, se non viene configurato nulla, il comportamento predefinito consiste nel creare i nodi ombra.

Per un comportamento diverso da quello predefinito, è necessario impostarlo sull’istanza di authoring e riportarlo a tutte le istanze di pubblicazione, solitamente un processo manuale.

Risorse Business.Adobe.com

Ecommerce Integrations Auto Text Summarization Content Intelligence Theme Editor Customer Experience Management Digital Signage