儲存資源提供者概觀

簡介

截至Adobe Experience Manager (AEM) Communities 6.1，社群內容(通常稱為使用者產生的內容(UGC))會儲存在由提供的單一通用存放區中。 儲存資源提供者 (SRP)。

有數個SRP選項，所有選項都可透過新的AEM Communities介面( SocialResourceProvider API (SRP API)，包括所有建立、讀取、更新和刪除(CRUD)作業。

所有SCF元件皆使用SRP API實作，因此程式碼可在不瞭解 基礎拓撲 或UGC的位置。

SocialResourceProvider API僅適用於AEM Communities的授權客戶。

注意

自訂元件：對於AEM Communities的授權客戶，自訂元件的開發人員可以使用SRP API來存取UGC，而不考慮基礎拓撲。 另請參閱 SRP和UGC Essentials.

另請參閱:

關於存放庫

若要瞭解SRP，瞭解AEM存放庫(Oak)在AEM社群網站中的角色會很有幫助。

Java™內容存放庫(JCR)
此標準會定義資料模型和應用程式設計介面(JCR API)時，不會顯示任何額外資訊。 它結合了傳統檔案系統與關聯式資料庫的特性，並新增了內容應用程式經常需要的幾項額外功能。

JCR的一個實作是AEM存放庫Oak。

Apache Jackrabbit Oak
Oak 是JCR 2.0的實作，是一種專為以內容為中心的應用程式而設計的資料儲存系統。 這是一種階層式資料庫，專為非結構化和半結構化的資料而設計。 存放庫不僅儲存面向使用者的內容，也儲存應用程式使用的所有程式碼、範本和內部資料。 用於存取內容的UI是 CRXDE Lite.

JCR和Oak通常用於表示AEM存放庫。

在私人作者環境中開發網站內容後，必須將其複製到公開發佈環境。 這通常是透過名為的作業來完成 復寫. 這會發生在作者/開發人員/管理員的控制下。

對於UGC，內容是由公共發佈環境中的註冊網站訪客（社群成員）輸入。 這是隨機發生的。

為了管理和報告，從私人作者環境存取UGC會很有用。 使用SRP時，由於不需要從發佈反向復寫至作者，因此從作者存取UGC會更一致，而且效能更高。

關於SRP

UGC儲存至共用儲存體時，在大部分部署中，成員內容的單一例項可同時從製作和發佈環境存取。 無論SRP選擇為何(MSRP、ASRP、JSRP)，所有選項都必須使用SRP API以程式設計方式存取。

注意

另請參閱 SRP和UGC Essentials 以取得範常式式碼和其他詳細資訊。

另請參閱 使用SRP存取UGC 以取得編碼時的最佳實務。

ASRP

如果有ASRP，UGC不會儲存在JCR中，而是儲存在由Adobe託管和管理的雲端服務中。 ASRP中儲存的UGC不可使用CRXDE Lite檢視或使用JCR API存取。

另請參閱 ASRP -Adobe儲存資源提供者.

開發人員無法直接存取UGC。

ASRP會使用Adobe雲端進行查詢。

MSRP

如果有，MSRP、UGC就不會儲存在JCR中，而是儲存在MongoDB中。 儲存在MSRP中的UGC不可使用CRXDE Lite檢視或使用JCR API存取。

另請參閱 MSRP - MongoDB儲存資源提供者.

雖然MSRP可與ASRP相提並論，因為所有AEM伺服器執行個體都存取相同的UGC，所以可以使用通用工具直接存取儲存在MongoDB中的UGC。

MSRP使用Solr進行查詢。

JSRP

JSRP是存取單一AEM執行個體上所有UGC的預設提供者。 它可讓您快速體驗AEM Communities 6.1，而不需要設定MSRP或ASRP。

另請參閱 JSRP - JCR儲存資源提供者.

如果有JSRP，而UGC儲存在JCR中，並可透過CRXDE Lite和JCR API存取，則建議您不要使用JCR API來存取，否則日後的變更可能會影響自訂程式碼。

此外，不會共用作者和發佈環境的存放庫。 雖然發佈執行個體的叢集會產生共用發佈存放庫，但在發佈時輸入的UGC將不會顯示在作者身上，因此無法管理來自作者的UGC。 UGC只會保留在輸入它的執行個體的AEM存放庫(JCR)中。

JSRP會使用Oak索引進行查詢。

關於JCR中的陰影節點

模擬指向UGC的路徑的陰影節點存在於本機存放庫中，有兩個用途：

  1. 存取控制(ACL
  2. 非現有資源(NER)

不論SRP實作為何，實際的UGC將不會在與陰影節點相同的位置可見。

用於存取控制(ACL)

有些SRP實作（例如ASRP和MSRP）會將社群內容儲存在不提供ACL驗證的資料庫中。 陰影節點會提供本機存放庫中ACL可套用的位置。

使用SRP API時，所有SRP選項會在執行所有CRUD作業之前，對陰影位置執行相同的檢查。

ACL檢查會使用公用程式方法，傳回適合檢查套用至資源UGC之許可權的路徑。

另請參閱 SRP和UGC Essentials 以取得範常式式碼。

針對非現有資源(NER)

部分Communities元件不可包含在指令碼中，因此需要Sling可定址節點來支援Communities功能。 包含的元件 稱為非現有資源(NER)。

陰影節點在存放庫中提供Sling可定址位置。

注意

由於陰影節點有多重用途，陰影節點的存在會 not 表示該元件是NER。

儲存位置

以下是陰影節點的範例，使用 註解元件 在 社群元件指南：

  • 元件存在於本機存放庫中：

    /content/community-components/en/comments/jcr:content/content/includable/comments

  • 對應的陰影節點存在於本機存放庫中：

    /content/usergenerated/content/community-components/en/comments/jcr:content/content/includable/comments

在陰影節點下找不到UGC。

預設行為是在發佈執行個體上設定陰影節點，只要參照相關的子樹狀結構以進行讀取或寫入。

例如，假設部署是 MSRP TarMK發佈伺服器陣列。

當 會員 在pub1上發佈UGC （儲存在MongoDB中），在pub1上的JCR中建立陰影節點。

第一次在pub2上讀取UGC時，如果未設定任何專案，預設行為是建立陰影節點。

如果需要預設行為以外的其他行為，則必須在編寫執行個體上將其設定並前滾到所有發佈執行個體，這通常是手動過程。

本頁內容