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

Introduzione introduction

A partire da Adobe Experience Manager (AEM) Communities 6.1, i contenuti della community, comunemente denominati contenuti generati dagli utenti (UGC, User-Generated Content), sono memorizzati 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:

Informazioni sull’archivio about-the-repository

Per comprendere la SRP, è utile comprendere il ruolo dell’archivio dell’AEM (Oak) in un sito della community dell’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 diverse funzioni aggiuntive di cui le applicazioni di contenuti hanno spesso bisogno.

Un’implementazione del JCR è l’archivio dell’AEM, Oak.

Apache Jackrabbit Oak
Oak è un’implementazione di JCR 2.0, un sistema di storage dei dati 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 Liti.

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 about-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 asrp

Se è presente ASRP, UGC non viene memorizzato in JCR, ma in un servizio cloud ospitato e gestito da Adobe. Le UGC memorizzate in ASRP potrebbero non essere visualizzate con CRXDE Liti o non essere 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 msrp

Se è presente, MSRP, UGC non è memorizzato in JCR, ma in MongoDB. Le UGC memorizzate in MSRP potrebbero non essere visualizzate con CRXDE Liti o non 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

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.

Se è presente JSRP mentre UGC è memorizzato in JCR ed è accessibile nelle API CRXDE Liti e JCR, l’Adobe consiglia di non utilizzare mai l’API JCR a tale scopo. In tal caso, le modifiche future potrebbero influire sul codice personalizzato.

Inoltre, l’archivio per gli ambienti Author e Publish non è condiviso. Anche se un cluster di istanze di pubblicazione genera un archivio di pubblicazione condiviso, l’UGC immesso al momento della pubblicazione non è visibile nell’istanza di authoring, pertanto non è possibile gestirlo dall’istanza di authoring. 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 about-shadow-nodes-in-jcr

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

Indipendentemente dall’implementazione SRP, l’UGC effettivo è non visibile nella stessa posizione del nodo ombra.

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

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) for-non-existing-resources-ners

Alcuni componenti di Communities sono inclusi in uno script e quindi 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 storage-location

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

Nessun UGC trovato 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.