Storage Resource Provider Overview storage-resource-provider-overview

Introduction introduction

As of AEM Communities 6.1, community content, commonly referred to as user generated content (UGC), is stored in a single, common store provided by a storage resource provider (SRP).

There are several SRP options, all of which access UGC through a new AEM Communities interface, the SocialResourceProvider API (SRP API), which includes all create, read, update, and delete (CRUD) operations.

All SCF components are implemented using the SRP API, allowing code to be developed without knowledge of either the underlying topology or location of UGC.

The SocialResourceProvider API is available only to licensed customers of AEM Communities.

See also:

About the Repository about-the-repository

To understand SRP, it is helpful to understand the role of the AEM repository (OAK) in an AEM community site.

Java Content Repository (JCR)
This standard defines a data model and application programming interface (JCR API) for content repositories. It combines characteristics of conventional file systems with those of relational databases, and adds a number of additional features that content applications often need.

One implementation of JCR is the AEM repository, OAK.

Apache Jackrabbit Oak (OAK)
OAK is an implementation of JCR 2.0 that is a data storage system specifically designed for content-centric applications. It is a type of hierarchical database designed for unstructured and semi-structured data. The repository stores not only the user-facing content but also all code, templates and internal data used by the application. The UI for accessing content is CRXDE Lite.

Both JCR and OAK are typically used to refer to the AEM repository.

After developing site content in the private author environment, it must by copied to the public publish environment. This is often done through an operation called replication. This happens under control of the author/developer/administrator.

For UGC, the content is entered by registered site visitors (community members) in the public publish environment. This happens randomly.

For purposes of management and reporting, it is useful to have access to UGC from the private author environment. With SRP, access to UGC from author is more consistent and performant as reverse replication from publish to author is not necessary.

About SRP about-srp

When UGC is saved to shared storage, there is a single instance of member content that may, in most deployments, be accessed from both the author and publish environments. Regardless of SRP choice (MSRP, ASRP, JSRP), all must be accessed programmatically with the SRP API.

ASRP asrp

In the case of ASRP, UGC is not stored in JCR, it is stored in a cloud service hosted and managed by Adobe. UGC stored in ASRP may neither be viewed with CRXDE Lite nor accessed using the JCR API.

See ASRP - Adobe Storage Resource Provider.

It is not possible for developers to access the UGC directly.

ASRP uses Adobe cloud for queries.

MSRP msrp

In the case of MSRP, UGC is not stored in JCR, it is stored in MongoDB. UGC stored in MSRP may neither be viewed with CRXDE Lite nor accessed using the JCR API.

See MSRP - MongoDB Storage Resource Provider.

While MSRP is comparable to ASRP, as all AEM server instances are accessing the same UGC, it is possible to use common tools to directly access the UGC stored in MongoDB.

MSRP uses Solr for queries.

JSRP jsrp

JSRP is the default provider for accessing all UGC on a single AEM instance. It provides the ability to quickly experience AEM Communities 6.1 without the need for setting up MSRP or ASRP.

See JSRP - JCR Storage Resource Provider.

In the case of JSRP, while UGC is stored in JCR, and accessible via both CRXDE Lite and JCR API, it is strongly recommended that JCR API never be used to do so, else future changes may affect custom code.

Further, the repository for the author and publish environments is not shared. While a cluster of publish instances results in a shared publish repository, UGC entered on publish will not be visible on author, hence no ability to manage UGC from author. UGC is only persisted in the AEM repository (JCR) of the instance on which it was entered.

JSRP uses the Oak indices for queries.

About Shadow Nodes in JCR about-shadow-nodes-in-jcr

Shadow nodes, which mimic the path to UGC, exist in the local repository to serve two purposes:

Regardless of SRP implementation, the actual UGC will *not *be visible at the same location as the shadow node.

For Access Control (ACLs) for-access-control-acls

Some SRP implementations, such as ASRP and MSRP, store community content in databases which provide no ACL verification. Shadow nodes provide a location in the local repository to which ACLs can be applied.

Using the SRP API, all SRP options perform the same check of the shadow location prior to all CRUD operations.

The ACL check uses an utility method that returns a path suitable for checking the permissions applied to the resource’s UGC.

See SRP and UGC Essentials for sample code.

For Non-Existing Resources (NERs) for-non-existing-resources-ners

Some Communities components are includable within a script and thus require a Sling addressable node to support Communities features. Included components are referred to as non-existing resources (NERs).

Shadow nodes provide a Sling addressable location in the repository.

Storage Location storage-location

Following is an example of a shadow node, using the Comments component in the Community Components Guide:

No UGC will be found under the shadow node.

The default behavior is to set up shadow nodes on a publish instance whenever the relevant subtree is referenced for a read or write.

As an example, suppose the deployment is MSRP with a TarMK publish farm.

When a member posts UGC on pub1 (stored in MongoDB), shadow nodes are created in JCR on pub1.

The first time the UGC is read on pub2, if nothing is set up, the default behavior is to create the shadow nodes.

If other than the default behavior is desired, it must be set up on the author instance and rolled forward to all publish instances, which is typically a manual process.