Show Menu
SUJETS×

Aperçu du fournisseur de ressources

Présentation

Depuis la version 6.1 des Communautés AEM, le contenu de la communauté, communément appelé contenu généré par l’utilisateur (UGC), est stocké dans un seul magasin commun fourni par un fournisseur de ressources (SRP).
Il existe plusieurs options SRP, qui accèdent toutes à l’UGC via une nouvelle interface Communautés AEM, l’API SRP et UGC Essentials SocialResourceProvider (API SRP), qui comprend 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 de développer le code sans connaître la topologie Topologies recommandées pour Communities sous-jacente ou l’emplacement de l’UGC.
L’API SocialResourceProvider est disponible uniquement pour les clients titulaires d’une licence des communautés AEM.
Composants personnalisés : Pour les clients disposant d’une licence pour les communautés AEM, l’API SRP est disponible pour les développeurs de composants personnalisés en vue d’accéder à l’UGC sans tenir compte de la topologie sous-jacente. Voir SRP et UGC Essentials .
Voir également :

A propos du référentiel

Pour comprendre SRP, il est utile de comprendre le rôle du référentiel AEM (OAK) dans un site de la communauté AEM.
Java Content Repository (JCR) Cette norme définit un modèle de données et une interface de programmation d’applications (API jcr-api.htmlJCR) pour les référentiels de contenu. Il combine les caractéristiques des systèmes de fichiers conventionnels avec celles des bases de données relationnelles et ajoute un certain nombre de fonctionnalités supplémentaires dont les applications de contenu ont souvent besoin.
Une implémentation du JCR est le référentiel AEM, OAK.
Apache Jackrabbit Oak (OAK) OAK est une implémentation de JCR 2.0 qui est un système de de données spécialement conçu pour les applications axées sur le contenu. Il s’agit d’un type de base de données hiérarchique conçue pour les données non structurées et semi-structurées. Le référentiel stocke le contenu affiché aux utilisateurs et l’ensemble du code, des modèles et des données internes utilisés par l’application. L’interface utilisateur d’accès 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'auteur privé , il doit être copié dans le public de publication . Cela se fait souvent au moyen d’une opération appelée réplication . Cela se produit sous le contrôle de l’auteur/développeur/administrateur.
Pour l’UGC, le contenu est entré par les enregistrés du site (membres de la communauté) dans la publication publique le . Ça se passe de manière aléatoire.
Pour les besoins de la gestion et de la , il est utile d'avoir accès à l'UGC de l'auteur privé . Avec SRP, l’accès à l’UGC à partir de l’auteur est plus cohérent et performant, car la réplication inversée de la publication à l’auteur n’est pas nécessaire.

À propos de SRP

Lorsque l’UGC est enregistré dans le de partagé, il existe une instance unique du contenu des membres qui peut, dans la plupart des déploiements, être accessible à partir de l’auteur et de la publication de l’ de. Quel que soit le choix SRP (MSRP, ASRP, JSRP), tous doivent être accessibles par programmation avec l’API SRP.
Voir SRP et UGC Essentials pour obtenir un exemple de code et des détails supplémentaires.
Voir Accès UGC avec SRP pour connaître les meilleures pratiques en matière de codage.

ASRP

Dans le cas d’ASRP, l’UGC n’est pas stockée dans le JCR, mais dans un service cloud hébergé et géré par Adobe. L’UGC stocké dans ASRP ne peut être ni affiché avec CRXDE Lite, ni accessible à l’aide de l’API JCR.
Voir ASRP - Adobe fournisseur de ressources.
Il n'est pas possible pour les développeurs d'accéder directement à l'UGC.
ASRP utilise Adobe Cloud pour les de.

MSRP

Dans le cas de MSRP, UGC n’est pas stocké dans JCR, il est stocké dans MongoDB. L’UGC stocké dans MSRP ne peut être ni affiché avec CRXDE Lite, ni accessible à l’aide de l’API JCR.
Bien que MSRP soit comparable à ASRP, puisque toutes les instances de serveur AEM accèdent au même UGC, il est possible d’utiliser des outils courants pour accéder directement à l’UGC stocké dans MongoDB.
MSRP utilise Solr pour les de.

JSRP

JSRP est le fournisseur par défaut pour accéder à l’ensemble des fichiers UGC sur une seule instance AEM. Il permet de découvrir rapidement les communautés AEM 6.1 sans avoir à configurer MSRP ou ASRP.
Voir JSRP - JCR fournisseur de ressources.
Dans le cas du JSRP, alors que l’UGC est stockée dans le JCR et accessible via CRXDE Lite et l’API JCR, il est vivement recommandé de ne jamais utiliser l’API JCR pour ce faire, faute de quoi les modifications futures peuvent affecter le code personnalisé.
De plus, le référentiel pour l’auteur et la publication le n’est pas partagé. Alors qu’un cluster d’instances de publication génère un référentiel de publication partagé, l’UGC saisi lors de la publication ne sera pas visible sur l’auteur, ce qui empêche la gestion de l’UGC à partir de l’auteur. L’UGC n’est conservée que dans le référentiel AEM (JCR) de l’instance sur laquelle elle a été entrée.
JSRP utilise les indices Oak pour les de.

A propos des noeuds fantômes dans JCR

Les noeuds d’ombre, qui imitent le chemin d’accès à UGC, existent dans le référentiel local pour deux raisons :
Quelle que soit l’implémentation SRP, l’UGC réel ne sera *pas *visible au même emplacement que le noeud fantôme.

Pour les de (ACL)

Certaines implémentations SRP, telles que ASRP et MSRP, stockent le contenu de la communauté dans des bases de données qui ne fournissent aucune vérification ACL. Les noeuds d’ombre fournissent un emplacement dans le référentiel local auquel les listes de contrôle d’accès peuvent être appliquées.
A l’aide de l’API SRP, toutes les options SRP effectuent la même vérification de l’emplacement de l’ombre 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 fichier UGC de la ressource.
Voir SRP et UGC Essentials pour obtenir un exemple de code.

Pour les ressources non existantes (NER)

Certains composants Communities sont inclus dans un script et nécessitent donc un noeud adressable Sling pour prendre en charge les fonctionnalités Communities. Les composants inclus sont appelés ressources non existantes (NER).
Les noeuds d’ombre fournissent un emplacement adressable Sling dans le référentiel.
Comme le noeud fantôme a plusieurs utilisations, la présence d’un noeud fantôme n’implique pas que le composant est un NER.

emplacement du

Voici un exemple de noeud fantôme, à l’aide du composant comments.html Commentaires du Guide des composants de la communauté :
  • Le composant existe dans le référentiel local à l’adresse suivante :
    /content/community-components/en/comments/jcr:content/content/includable/comments
  • Le noeud fantôme correspondant existe dans le référentiel local à l’adresse suivante :
    /content/usergenerated/content/community-components/en/comments/jcr:content/content/includable/comments
Aucune UGC ne sera trouvée 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 batterie de publication TarMK.
Lorsqu’un membre publie l’UGC sur pub1 (stocké dans MongoDB), les noeuds d’ombre sont créés dans JCR sur pub1.
La première fois que l’UGC est lu sur pub2, si rien n’est configuré, le comportement par défaut est de créer les noeuds d’ombre.
Si vous souhaitez autre chose que le comportement par défaut, vous devez le configurer sur l’instance d’auteur et l’étendre à toutes les instances de publication, ce qui est généralement un processus manuel.