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.

Note:

Custom Components : For licensed customers of AEM Communities, the SRP API is available to developers of custom components for the purpose of accessing UGC without regard to the underlying topology. See SRP and UGC Essentials.

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

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.

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

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)

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.

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.

Caution:

As the shadow node has multiple uses, the presence of a shadow node does not imply that the component is a NER.