Overzicht van opslagbronprovider

Inleiding

Vanaf AEM Communities 6.1 wordt community-inhoud, die doorgaans door gebruikers gegenereerde inhoud (UGC) wordt genoemd, opgeslagen in één gemeenschappelijke opslagruimte die wordt geleverd door een opslagbronprovider (SRP).

Er zijn verscheidene opties SRP, die allen tot UGC door een nieuwe interface van AEM Communities toegang hebben, SocialResourceProvider API (SRP API), die allen creeer, lezen, update, en schrapt (CRUD) verrichtingen omvat.

Alle componenten SCF worden uitgevoerd gebruikend SRP API, toestaand code om zonder kennis van of onderliggende topologie of plaats van UGC worden ontwikkeld.

De API voor SocialResourceProvider is alleen beschikbaar voor klanten met een licentie van AEM Communities.

OPMERKING

Aangepaste componenten: Voor gelicentieerde klanten van AEM Communities, is SRP API beschikbaar aan ontwikkelaars van douanecomponenten voor de toegang tot van UGC ongeacht de onderliggende topologie. Zie SRP en UGC Essentials.

Zie ook:

Informatie over de opslagplaats

Om SRP te begrijpen, is het nuttig om de rol van de AEM bewaarplaats (OAK) in een AEM communautaire plaats te begrijpen.

Java Content Repository (JCR)
Deze standaard definieert een gegevensmodel en een programmeerinterface voor toepassingen (JCR API) voor opslagruimten voor inhoud. Het combineert kenmerken van conventionele dossiersystemen met die van relationele gegevensbestanden, en voegt een aantal extra eigenschappen toe die inhoudstoepassingen vaak nodig hebben.

Eén implementatie van JCR is de AEM opslagplaats, OAK.

Apache Jackrabbit Oak (OAK)
🔗 OAK is een implementatie van JCR 2.0. Dit is een gegevensopslagsysteem dat speciaal is ontworpen voor inhoudgerichte toepassingen. Dit is een soort hiërarchische database die is ontworpen voor ongestructureerde en semi-gestructureerde gegevens. De dataopslag slaat niet alleen de gebruikersgerichte inhoud op, maar ook alle code, sjablonen en interne gegevens die door de toepassing worden gebruikt. De UI voor de toegang tot van inhoud is CRXDE Lite.

Zowel JCR als OAK worden typisch gebruikt om naar de AEM bewaarplaats te verwijzen.

Nadat u site-inhoud hebt ontwikkeld in de omgeving van de privéauteur, moet u deze kopiëren naar de openbare publicatieomgeving. Dit wordt vaak gedaan door een verrichting genoemd replicatie. Dit gebeurt onder controle van de auteur/ontwikkelaar/beheerder.

Voor UGC wordt de inhoud ingevoerd door geregistreerde sitebezoekers (leden van de community) in de publicatieomgeving van het publiek. Dit gebeurt willekeurig.

Voor beheer en rapportage is het nuttig om vanuit de omgeving van de particuliere auteur toegang tot UGC te hebben. Met SRP, is de toegang tot UGC van auteur consistenter en uitvoerender aangezien de omgekeerde replicatie van publiceren aan auteur niet noodzakelijk is.

Informatie over SRP

Wanneer UGC aan gedeelde opslag wordt bewaard, is er één enkel geval van lidinhoud die, in de meeste plaatsingen, van zowel de auteur als publicatiemilieu's kan worden betreden. Ongeacht de keus SRP (MSRP, ASRP, JSRP), moeten allen programmatically met SRP API worden betreden.

OPMERKING

Zie SRP en UGC Essentials voor steekproefcode en extra details.

Zie Toegang tot UGC met SRP voor beste praktijken wanneer het coderen.

ASRP

In het geval van ASRP, wordt UGC niet opgeslagen in JCR, wordt het opgeslagen in de wolkendienst die door Adobe wordt ontvangen en wordt beheerd. UGC die in ASRP is opgeslagen, kan niet met CRXDE Lite worden bekeken en kan niet worden benaderd met behulp van de JCR API.

Zie ASRP - Adobe Storage Resource Provider.

Ontwikkelaars hebben niet rechtstreeks toegang tot de UGC.

ASRP gebruikt de wolk van Adobe voor vragen.

MSRP

In het geval van MSRP, wordt UGC niet opgeslagen in JCR, wordt het opgeslagen in MongoDB. UGC die is opgeslagen in MSRP kan niet worden weergegeven met CRXDE Lite en kan niet worden benaderd via de JCR API.

Zie MSRP - MongoDB Storage Resource Provider.

Terwijl MSRP aan ASRP vergelijkbaar is, aangezien alle AEM serverinstanties tot zelfde UGC toegang hebben, is het mogelijk om gemeenschappelijke hulpmiddelen te gebruiken om tot UGC direct toegang te hebben die in MongoDB wordt opgeslagen.

MSRP gebruikt Solr voor vragen.

JSRP

JSRP is de standaardleverancier voor de toegang tot van al UGC op één enkele AEM instantie. Het verstrekt de capaciteit om AEM Communities 6.1 zonder de behoefte aan vestiging MSRP of ASRP snel te ervaren.

Zie JSRP - JCR Storage Resource Provider.

In het geval van JSRP, terwijl UGC wordt opgeslagen in JCR, en toegankelijk via zowel CRXDE Lite als JCR API, wordt ten zeerste geadviseerd dat JCR API nooit wordt gebruikt om dit te doen, anders kunnen toekomstige veranderingen douanecode beïnvloeden.

Bovendien wordt de opslagplaats voor de auteur- en publicatieomgevingen niet gedeeld. Hoewel een cluster met publicatie-instanties resulteert in een gedeelde publicatierecorder, is UGC die tijdens publicatie wordt ingevoerd, niet zichtbaar voor de auteur, zodat de auteur de UGC niet kan beheren. UGC blijft alleen behouden in de AEM repository (JCR) van de instantie waarin het werd ingevoerd.

JSRP gebruikt de indexen van het Eak voor vragen.

Informatie over schaduwknooppunten in JCR

Schaduwknooppunten, die het pad naar UGC nabootsen, bestaan in de lokale opslagruimte voor twee doeleinden:

  1. Toegangsbeheer (ACLs)
  2. Niet-bestaande bronnen (NER's)

Ongeacht de implementatie SRP, zal daadwerkelijke UGC *not zichtbaar op de zelfde plaats zoals de schaduwknoop zijn.

Voor Toegangsbeheer (ACLs)

Sommige implementaties SRP, zoals ASRP en MSRP, slaan communautaire inhoud in gegevensbestanden op die geen ACL controle verstrekken. De knopen van de schaduw verstrekken een plaats in de lokale bewaarplaats waarop ACLs kan worden toegepast.

Met de SRP API voeren alle SRP-opties dezelfde controle uit op de schaduwlocatie voorafgaand aan alle CRUD-bewerkingen.

De ACL controle gebruikt een nutsmethode die een weg geschikt voor het controleren van de toestemmingen terugkeert die op UGC van het middel worden toegepast.

Zie SRP en UGC Essentials voor steekproefcode.

Voor niet-bestaande Middelen (NERs)

Sommige componenten van Gemeenschappen zijn inbegrepen binnen een manuscript en vereisen daarom een Sling adressable knoop om de eigenschappen van Gemeenschappen te steunen. Opgenomen componenten worden bedoeld als niet-bestaande middelen (NERs).

Schaduwknooppunten bieden een adresseerbare locatie in de opslagplaats.

LET OP

Aangezien de schaduwknoop veelvoudige toepassingen heeft, impliceert de aanwezigheid van een schaduwknoop not dat de component NER is.

Opslaglocatie

Hieronder ziet u een voorbeeld van een schaduwknooppunt, waarbij de component Comments in de Community Components Guide wordt gebruikt:

  • De component bestaat in de lokale opslagplaats op:

    /content/community-components/nl/comments/jcr:content/content/include/comments

  • Het corresponderende schaduwknooppunt bestaat in de lokale opslagruimte op:

    /content/usergenerated/content/community-components/nl/comments/jcr:content/content/include/comments

Er wordt geen UGC gevonden onder het schaduwknooppunt.

Standaard worden schaduwknooppunten ingesteld op een publicatie-instantie wanneer naar de relevante substructuur wordt verwezen voor lezen of schrijven.

Als voorbeeld, veronderstel de plaatsing MSRP met een TarMK publiceert landbouwbedrijf is.

Wanneer een lid UGC op pub1 (opgeslagen in MongoDB) plaatst, worden de schaduwknopen gecreeerd in JCR op pub1.

De eerste keer dat de UGC op pub2 wordt gelezen, als er niets is ingesteld, is het standaardgedrag dat de schaduwknooppunten worden gemaakt.

Als u een ander gedrag wilt gebruiken dan het standaardgedrag, moet u dit instellen voor de instantie van de auteur en doorsturen naar alle publicatie-instanties. Dit is doorgaans een handmatig proces.

Op deze pagina