SRP - Archiviazione dei contenuti della community

Introduzione

A partire da AEM Communities 6.1, il contenuto generato dall’utente (UGC) viene memorizzato in un singolo archivio comune fornito da un provider di risorse di archiviazione (SRP). Ci sono diverse opzioni SRP da scegliere, come ASRP, MSRP e JSRP.

A differenza delle versioni precedenti, non esiste una replica inversa/forward di UGC tra le istanze AEM. Al contrario, l’SRP rende l’UGC direttamente accessibile per le operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD) da tutte le istanze di authoring e pubblicazione, con un’eccezione per JSRP.

Di seguito sono riportate le caratteristiche di ogni opzione SRP, che sono informazioni cruciali per il processo decisionale quando si sceglie l'SRP appropriato e la distribuzione sottostante.

Per informazioni dettagliate sull'utilizzo dell'SRP per UGC, vedere Panoramica del provider di risorse di storage.

Caratteristiche delle opzioni SRP

ASRP - Provider risorsa di archiviazione Adobe

Con questa opzione, l’UGC viene mantenuto in remoto in un servizio cloud ospitato e gestito da Adobe. Richiede una licenza aggiuntiva e collabora con un rappresentante commerciale per fornire l'account per quella licenza specifica. L’ASRP richiede:

• Un servizio cloud associato fornito e supportato da Adobe per memorizzare i contenuti della community.

• Scelta di un centro dati in una specifica area geografica (Stati Uniti, EMEA, APAC).

• L’accesso programmatico a UGC può essere effettuato tramite l’API SRP.

ASRP è adatto:

• Per la farm di pubblicazione TarMK.
• Quando non si intende investire nello storage locale.

MSRP - Provider risorsa di archiviazione MongoDB

Con questa opzione, l’UGC viene mantenuto direttamente in un’istanza MongoDB locale.

MSRP richiede:

• Installazione locale con licenza di MongoDB per memorizzare i contenuti della community.
• Installazione locale di Apache Solr.
• L’accesso programmatico a UGC può essere effettuato tramite l’API SRP.

ASRP è adatto:

• Per una farm di pubblicazione TarMK esistente.
• Per un cluster MongoMK o RdbMK.
• Quando ci si aspetta grandi quantità di contenuti della community.

DSRP - Provider risorsa di archiviazione database relazionale

Con questa opzione, l'UGC viene mantenuto direttamente in un'istanza di database MySQL locale.

DSRP richiede:

• Installazione locale di MySQL per memorizzare il contenuto della community.
• Installazione locale di Apache Solr.
• L’accesso programmatico a UGC può essere effettuato tramite l’API SRP.

DSRP è adatto:

• Per una farm di pubblicazione TarMK esistente.
• Per un cluster MongoMK o RdbMK.
• Quando ci si aspetta grandi quantità di contenuti della community.

JSRP - Provider risorsa di archiviazione JCR

Con l'opzione predefinita, non esiste un archivio comune. L’UGC viene mantenuto solo nello stesso archivio JCR dell’istanza AEM in cui è stato inserito.

JSRP:

• Memorizza il contenuto della community nell’archivio JCR dell’istanza di authoring o pubblicazione AEM a cui è stato pubblicato.
• Richiede l’accesso programmatico a UGC tramite l’API SRP.
• Richiede un cluster di pubblicazione se vengono distribuite più istanze di pubblicazione (non esiste un meccanismo di replica tra le istanze di pubblicazione in una farm TarMK).
• la moderazione viene eseguita solo nell’ambiente di pubblicazione (non esiste un meccanismo di replica inversa/forward tra l’autore e la pubblicazione).
• È il migliore per lo sviluppo, le dimostrazioni e la formazione.

Configurazione dell’SRP

La specificazione dell'opzione di archiviazione predefinita, basata sulla distribuzione sottostante, viene eseguita tramite la console di configurazione dello storage.

Per i dettagli di configurazione di ciascuna opzione, vedi:

• ASRP - Provider risorsa di archiviazione Adobe
• MSRP - Provider risorsa di archiviazione MongoDB
• DSRP - Provider risorsa di archiviazione database relazionale
• JSRP - Provider risorsa di archiviazione JCR

Se non è selezionata alcuna opzione di archiviazione attiva, per impostazione predefinita JSRP è abilitato.

Informazioni aggiuntive

UGC non replicato

Nell’ambiente di authoring, un autore crea il contenuto della pagina e lo replica nell’ambiente di pubblicazione. Quando una pagina include una funzione di AEM Communities interattiva, ad esempio commenti, revisioni, forum, blog o QnA, l’interazione dei membri (connessi ai visitatori del sito) su un’istanza di pubblicazione si traduce in contenuti generati dagli utenti (UGC) inseriti nell’ambiente di pubblicazione.

In precedenza, il contenuto della community veniva replicato inverso nelle istanze dell’autore e dall’autore replicato alle istanze di pubblicazione. È stato problematico mantenere la coerenza tra le istanze AEM con la replica inversa e successiva.

A partire da AEM Communities 6.1, la necessità di replica di UGC è stata eliminata utilizzando lo storage condiviso per UGC, come descritto in precedenza.

Mentre il contenuto del sito viene replicato, UGC non viene mai replicato.

Gestione dei dati utente

Anche i siti CommunitIes sono utenti, gruppi di utenti e profili utente. Questi dati relativi all’utente, quando creati e aggiornati nell’ambiente di pubblicazione, devono essere resi disponibili ad altre istanze di pubblicazione quando la topologia è una farm di pubblicazione.

A partire da AEM Communities 6.1, i dati relativi all’utente vengono sincronizzati utilizzando la distribuzione Sling invece della replica. Per ulteriori informazioni, visita Sincronizzazione utente.

Aggiornamento ad AEM Communities 6.5

Quando si esegue l’aggiornamento a AEM 6.5 Communities, se è necessario mantenere gli UGC preesistenti, è necessario adottare misure a seconda che la comunità AEM 5.6.1 o AEM 6.0 utilizzasse lo storage Adobe on-demand o on-premise di UGC.

Per ulteriori informazioni, visita Aggiornamento ad AEM Communities 6.5.