Présentation du fournisseur de ressources de stockage storage-resource-provider-overview

Présentation introduction

Depuis Adobe Experience Manager (AEM) Communities 6.1, le contenu de la communauté, communément appelé contenu généré par l’utilisateur, est stocké dans un seul magasin commun fourni par un fournisseur de ressources de stockage (SRP).

Il existe plusieurs options de SRP, qui accèdent toutes au contenu généré par l’utilisateur via une nouvelle interface AEM Communities, l’ API SocialResourceProvider (API SRP), qui inclut toutes les opérations de création, de lecture, de mise à jour et de suppression (CRUD).

Tous les composants SCF sont implémentés à l’aide de l’API SRP, ce qui permet au code d’être développé sans connaissance de la topologie sous-jacente ou de l’emplacement du contenu généré par l’utilisateur.

L’API SocialResourceProvider est disponible uniquement pour les clients sous licence d’AEM Communities.

Voir également :

À propos du référentiel about-the-repository

Pour comprendre la SRP, il est utile de comprendre le rôle du référentiel AEM (Oak) dans un site de communauté AEM.

Java™ Content Repository (JCR)
Cette norme définit un modèle de données et une interface de programmation d’application (API JCR) pour les référentiels de contenu. Il combine les caractéristiques des systèmes de fichiers classiques avec celles des bases de données relationnelles et ajoute plusieurs fonctions supplémentaires dont les applications de contenu ont souvent besoin.

Une implémentation de JCR est le référentiel AEM, Oak.

Apache Jackrabbit Oak
Oak est une implémentation de JCR 2.0 qui est un système de stockage de données conçu pour les applications centrées sur le contenu. Il s’agit d’un type de base de données hiérarchique conçu pour les données non structurées et semi-structurées. Le référentiel stocke non seulement le contenu destiné à l’utilisateur, mais également l’ensemble du code, des modèles et des données internes utilisés par l’application. L’interface utilisateur pour accéder au contenu est CRXDE Lite.

JCR et Oak sont généralement utilisés pour faire référence au référentiel AEM.

Après avoir développé le contenu du site dans l’environnement de création privé, il doit être copié dans l’environnement de publication public. Cela est souvent effectué au moyen d’une opération appelée replication. Cela se produit sous le contrôle de l’auteur/du développeur/de l’administrateur.

Pour le contenu généré par l’utilisateur, le contenu est saisi par les visiteurs enregistrés du site (membres de la communauté) dans l’environnement de publication public. Cela se produit de manière aléatoire.

À des fins de gestion et de création de rapports, il est utile d’avoir accès au contenu généré par l’utilisateur à partir de l’environnement de création privé. Grâce à la SRP, l’accès au contenu généré par l’utilisateur à partir de l’auteur est plus cohérent et performant, car la réplication inverse de Publish vers l’auteur n’est pas nécessaire.

À propos de SRP about-srp

Lorsque le contenu créé par l’utilisateur est enregistré dans le stockage partagé, il existe une instance unique du contenu membre qui peut, dans la plupart des déploiements, être accessible à partir des environnements de création et de publication. Quel que soit le choix de SRP (MSRP, ASRP, JSRP), tous ces éléments doivent être accessibles par programmation avec l’API SRP.

ASRP asrp

S’il existe un ASRP, le contenu généré par l’utilisateur n’est pas stocké dans JCR, il est stocké dans un service cloud hébergé et géré par Adobe. Le contenu généré par l’utilisateur stocké dans ASRP ne peut pas être affiché avec le CRXDE Lite ni accessible à l’aide de l’API JCR.

Voir ASRP - Fournisseur de ressources de stockage d’Adobe.

Il n’est pas possible pour les développeurs d’accéder directement au contenu créé par l’utilisateur.

ASRP utilise Adobe Cloud pour les requêtes.

MSRP msrp

Si tel est le cas, MSRP, UGC n’est pas stocké dans JCR, il est stocké dans MongoDB. Le contenu généré par l’utilisateur stocké dans MSRP ne peut pas être affiché avec CRXDE Lite ni accessible à l’aide de l’API JCR.

Voir MSRP - MongoDB Storage Resource Provider.

Bien que MSRP soit comparable à ASRP, puisque toutes les instances AEM serveur accèdent au même contenu généré par l’utilisateur, il est possible d’utiliser des outils communs pour accéder directement au contenu créé par l’utilisateur stocké dans MongoDB.

MSRP utilise Solr pour les requêtes.

JSRP jsrp

JSRP est le fournisseur par défaut pour accéder à tout le contenu créé par l’utilisateur sur une seule instance AEM. Il vous permet de tester rapidement AEM Communities 6.1 sans avoir à configurer MSRP ou ASRP.

Voir JSRP - JCR Storage Resource Provider.

S’il existe une JSRP alors que le contenu créé par l’utilisateur est stocké dans JCR et qu’il est accessible dans l’API CRXDE Lite et JCR, Adobe recommande de ne jamais utiliser l’API JCR pour le faire. Si vous le faites, les modifications futures peuvent affecter le code personnalisé.

De plus, le référentiel pour les environnements Auteur et Publish n’est pas partagé. Bien qu’un cluster d’instances de publication génère un référentiel de publication partagé, le contenu créé par l’utilisateur entré sur Publish n’est pas visible sur l’auteur, ce qui empêche la gestion du contenu créé par l’auteur. Le contenu généré par l’utilisateur n’est conservé que dans le référentiel AEM (JCR) de l’instance sur laquelle il a été saisi.

JSRP utilise les index Oak pour les requêtes.

À propos des noeuds fantômes dans JCR about-shadow-nodes-in-jcr

Les noeuds fantômes, qui imitent le chemin d’accès au contenu généré par l’utilisateur, existent dans le référentiel local pour servir deux objectifs :

Quelle que soit l’implémentation de la SRP, le contenu généré par l’utilisateur réel est not visible au même emplacement que le noeud fantôme.

Pour le contrôle d’accès (ACL) for-access-control-acls

Certaines mises en oeuvre de la SRP, telles que ASRP et MSRP, stockent le contenu de la communauté dans des bases de données qui ne fournissent aucune vérification de l’ACL. Les noeuds fantômes fournissent un emplacement dans le référentiel local auquel les listes de contrôle d’accès peuvent être appliquées.

À l’aide de l’API SRP, toutes les options de SRP effectuent la même vérification de l’emplacement fantôme avant toutes les opérations CRUD.

La vérification ACL utilise une méthode utilitaire qui renvoie un chemin approprié pour vérifier les autorisations appliquées au contenu généré par l’utilisateur de la ressource.

Voir SRP et UGC Essentials pour consulter un exemple de code.

Pour les ressources non existantes (NER) for-non-existing-resources-ners

Certains composants de Communities sont inclus dans un script et nécessitent donc un noeud adressable Sling pour prendre en charge les fonctionnalités de Communities. Les composants inclus sont appelés ressources non existantes (NERs).

Les noeuds fantômes fournissent un emplacement adressable Sling dans le référentiel.

Emplacement de stockage storage-location

Voici un exemple de noeud fantôme, à l’aide du composant Comments du Guide des composants de la communauté :

Aucun contenu généré par l’utilisateur n’est trouvé sous le noeud fantôme.

Le comportement par défaut consiste à configurer des noeuds fantômes sur une instance de publication chaque fois que la sous-arborescence appropriée est référencée pour une lecture ou une écriture.

Par exemple, supposons que le déploiement soit MSRP avec une ferme de publication TarMK.

Lorsqu’un member publie du contenu généré par l’utilisateur sur pub1 (stocké dans MongoDB), les noeuds fantômes sont créés dans JCR sur pub1.

La première fois que le contenu créé par l’utilisateur est lu sur pub2, si rien n’est configuré, le comportement par défaut est de créer les noeuds fantômes.

Si un autre comportement que le comportement par défaut est souhaité, il doit être configuré sur l’instance de création et déployé sur toutes les instances de publication, ce qui est généralement un processus manuel.