知識點：

  • 解釋Sitecore如何使用伺服器角色進行擴展
  • 描述Sitecore的基本開發架構
  • 確定關鍵Sitecore術語
  • 確定xConnect的優勢

1 架構概述

Sitecore 9 產品系列包括三個重要組件：

  • Sitecore Experience Manager
  • Sitecore Experience Platform
  • SItecore Experience Commerce

每個Sitecore組件都包含許多邏輯實體，這些實體與許多雲服務一起構成Sitecore平台的整個功能。

1.1 Sitecore Experience Manager

Sitecore Experience Manager (XM) 是Sitecore Experience Platform的Web內容管理（WCM）的核心，XM包含內容創建，管理，個性化和發布所涉及的功能。Sitecore Experience Manager包含邏輯角色的子集：

XM

1.2 Sitecore Experience Platform

Sitecore Experience Platform (XP) 將Experience Manager 與 xConnect 和 xDB提供的營銷和客戶智能功能相結合。xConnect和xDB引入了許多其他伺服器角色和存儲機制。

  • xConnect是位於xDB和任何希望通過HTTPS收集和搜索體驗數據的可信客戶端、設備或介面之間的一組服務的名稱。
  • xDB是存儲和處理體驗數據的服務和存儲角色集合的名稱。

XP

XP的角色擴展了Sitecore體驗管理器的內容管理，個性化和交付功能，其功能可實現跨渠道體驗，客戶和業務洞察，收集可操作的客戶信息，並在為客戶塑造體驗時提供上下文。

1.3 Sitecore Experience Commerce

Sitecore Experience Commerce (XC) 配置為單一和多租戶開箱即用。

通過單一租賃設置，您可以使用Content Delivery角色提供的單個網站（或店面）。

此店面調用商業引擎，訪問為其配置的實體和業務邏輯。

通過多租戶設置，Content Delivery角色可以容納多個店面，您的引擎可以託管多個實體和業務邏輯配置。

換句話說，您可以擁有一個內容交付和商務引擎，託管多個站點，每個站點都具有完全定製的功能，不僅是用戶界面，還包括商務引擎。

2 Sitecore 角色概述

整個Sitecore產品套件包含50多個邏輯系統角色或實體，可以在各種拓撲中進行擴展和配置，以形成滿足特定業務需求或要求的Sitecore解決方案。

可以根據目標從不同角度對邏輯角色進行分組和描述：

  • 按產品 - 角色按照許可和安裝的產品進行分組，並且主要使用這些產品。
  • 按類型 - 角色按其用途或技術分組。例如，它們是運行業務邏輯還是存儲數據。
  • 通過組合 - 出於可伸縮性或簡單性的原因，可以組合一些邏輯角色以在拓撲中形成單個運行實體。這通常是共享代碼庫的應用程序角色，但也可以是存儲角色。

3 Changing Configurations

3.1 Layers

Sitecore 作為一個.NET web的應用，也存在一個web.config文件，但是大多數配置都是在App_Config文件夾和子文件夾中定義的，這些文件都在web.config中引用，並在應用啟動時讀取，由這些文件逐步構建Sitecore的設置和配置。因此，處理這些文件的順序很重要，因為一個文件可以修改另一個文件設置的選項；Sitecore按層對文件進行分組，每個層都映射到父App_Config文件夾中的特定文件夾。一個名為layers.config的文件決定了處理這些層的順序。

注意點：

1 Sitecore的配置不僅僅只是web.config

2 web.config + App_Config文件夾中包含數百個文件，他們結合處理Sitecore的配置3 順序很重要，因為後一層可能會覆蓋前一層的設置

4 文件按層分組 - 每個層都映射到App_Config文件夾中的一個特定文件夾

5 layers.config文件定義了層的讀取順序

當Sitecore啟動時，它會讀取Web.config、connectionstrings.config和layers.config,這個文件定義了按順序載入的四個層：

  • Sitecore層：包含Sitecore實例的基本標準配置。
  • Module層：系統中安裝的模塊所需的任何額外配置（例如發布服務）
  • Custom層：在這個層中，您將為特定的應用程序添加擴展或修改Sitecore的任何配置。在Sitecore層和Modules層之後載入這一點很重要，因為您可能需要修改這些層中設置的配置。
  • Environment層：最後一層保留用於添加特定於環境的更改：例如，用於開發伺服器或QA等。

在每個層中，文件首先按字母順序從基礎文件夾載入，然後從子文件夾載入。 您可以向layers.config添加額外配置，以定義不同的載入順序。

還可以通過在layers.config中的層定義中添加mode =「off」屬性來禁用整個層。 如果要一次禁用所有配置自定義，例如調試問題並嘗試確定是否由自定義配置更改引起，這非常有用。

注意點：

1. 這些層按順序載入

2. 首先載入層文件夾中的文件，然後按子文件夾遞歸文件 - 始終按字母順序排列3. 可以使用<loadOrder>屬性強制首先載入某些patch文件，例如： <loadOrder>

<add path="CMS.Core" type="Folder"/>

</loadOrder>4. 可以通過在layers.config文件中添加mode =「off」屬性來禁用層

3.2 Basic config Includes Syntax

將以下Sitecore名稱空間聲明為.config文件：

Patch – sitecore.net/xmlconfig/

Before, After, Delete, Attribute

Set – sitecore.net/xmlconfig/

Set (similar effect to attribute)

以下注意點:

添加配置文件中的新元素

找到現有元素，可以使用set或attribute進行修改在匹配現有元素之前或之後使用，並指定新元素的順序

添加到層的欄位稱為補丁配置文件，或包含文件。這些文件允許你修改web.config的<sitecore>部分中的現有XML配置。每個文件是一個帶有額外XML命名空間聲明的標準配置文件。

當Sitecore讀取補丁文件的內容時，它將嘗試將聲明的XML元素的路徑與其正在編譯的配置匹配。如果未找到元素，則將其添加到配置中。如果找到，那麼它將使用補丁文件中的額外指令來修改它。

這些指令可以在兩個命名空間、補丁或集合中聲明。

修補程序命名空間定義了刪除元素和修改屬性的語法。還可以使用集合命名空間來修改具有更簡單語法的屬性。

在配置中聲明細節的順序很重要，所以在插入新元素時，常常可以使用補丁名稱空間來定義新元素的精確位置。使用兩個關鍵字，可以在XML中定義插入新元素的位置。

如果要臨時禁用文件，可以只更改其擴展名。只有配置了.CONFIG擴展名的文件才能進行配置處理。

3.3 查看有效配置

由於有效的配置是Sitecore處理數百個文件的結果，所以您可以看到它正在使用的配置非常重要。Sitecore提供了web.config中編譯的<sitecore>部分的視圖，它是通過層構建的部分。您可以使用/sitecore/admin/showconfig.aspx頁面，也可以通過Visual Studio中的Sitecore Rocks看到相同的信息。

除了顯示整個配置之外，Sitecore還將標記任何修改或添加了patch:source屬性的元素。這將具有導致配置更改的文件的名稱。

3.4 角色

Sitecore可以通過添加滿足相同功能的更多伺服器來水平擴展。它可以通過將單個伺服器的工作分成多個伺服器來進行垂直擴展。垂直擴展的一個例子是內容交付和內容管理伺服器的專業化。即使兩個伺服器都運行Sitecore。它們以不同的方式配置以在環境中執行不同的功能。

Sitecore提供了角色的概念，以幫助改變伺服器的配置，從而執行特定的任務。通過在web.config文件中添加AppSetting來定義希望伺服器執行的特定角色。Sitecore識別四個專門角色，內容管理、內容交付、處理和報告。有一個額外的可能性：獨立，使所有功能。這是默認設置以及通常為開發環境配置實例的方式。

站點配置文件由屬性「role:require」裝配，這些屬性可以根據實例的角色啟用或禁用部分配置。

垂直擴展

根據伺服器的功能啟用/禁用配置塊。通過AppSetting在web.config中啟用：

<AppSettings>
<add key=」role:define」 value=」[server role]」/>
</AppSettings>

配置文件用以下內容裝配：

<sitecore role:require="Standalone or ContentManagement">

可用角色如下：

Content Management

使作者能夠創建和發布內容到網站。

Content Delivery使您的網站內容可供您的網站聯繫人使用。Processing從捕獲的原始分析數據中提取信息，並將其轉換為適合用於報告應用程序的形式。Reporting獲取來自各種數據源（例如收集和報告資料庫）的報告數據，以在Sitecore報告應用程序中使用，例如Experience Analytics。Standalone執行所有伺服器角色的單個Sitecore實例。

4 Sitecore Modules and Packages

4.1 擴展Sitecore框架

Sitecore是一個可擴展的應用程序，您可以通過以下方式擴展Sitecore功能：

  • Package

1. 由開發人員創建

2. Sitecore安裝嚮導使用的Zip文件3. 包含序列化的Sitecore項目4. 可以包含代碼和配置文件5. 用於在Sitecore實例之間傳輸項目和文件
  • Module

1. 大多數模塊都是包

2. 用於擴展功能3. 在市場上找到
  • Update Package

1. 閱讀發行說明

2. 包含對實例，項目和文件的更改3. 按照升級指南進行其他步驟

Packages由開發人員通過開發工具中的包設計器或Sitecore Rocks創建。它們用於在環境之間移動項目和文件，以及添加自定義功能。Package是一個zip文件，包含序列化的Sitecore項，代碼和配置文件。

Packages還可以包含角色和用戶。請注意，安裝軟體包時，將禁用所有用戶並重置其密碼。

Sitecore模塊用於擴展Sitecore的功能。大多數模塊實際上都是Packages，因為擴展Sitecore通常涉及部署項目和文件。模塊可直接從Sitecore獲得，也可通過Marketplace從社區獲得。

還有另一種類型的Packages，可以通過其.update擴展名識別的更新包。它們使用Sitecore UpdateIntallationWizard.aspx頁面安裝。更新通常會修改項目和文件。在更新現有Sitecore實例之前，請務必閱讀發行說明並按照更新指南進行操作。

這些也是第三方產品（例如，來自Hedgehog或Sitecore Courier的Sitecore的Team Development），它們生成用於在環境之間移動項目，代碼和配置的更新包。

4.2 構建一個Package

您可以通過兩種方式創建常規Sitecore包：

1. Sitecore Package Designer是Sitecore客戶端的一部分，此工具可以生成Package，但它也可以以XML格式存儲包定義，這使您可以輕鬆地重新創建Package並共享Package配置。 在現有Sitecore安裝中導入Package時，目標資料庫中可能已存在項。 作為開發人員，您可以預定義安裝程序在存在項目時的行為方式。 默認為Ask User。 在這種情況下，會出現一個窗口，用戶可以選擇該行為。

2. 或者，可以使用Sitecore Rocks直接從Visual Studio創建Package，方法是直接選擇項目或文件或運行查詢。 您還可以使用Sitecore Rocks創建Anti-Package。 這可用於撤消安裝，但必須在安裝軟體包之前創建anti-package。

Sitecore Package Designer

靜態或動態添加項目設置安裝選項：

  • Overwrite
  • Merge
  • Skip
  • Ask User

Package定義可以保存為XML文件：

Sitecore Rocks

  • 管理Visual Studio中的Package
  • 可以創建撤消功能的Anti-package
  • 在Package中設置依賴關係

5 安裝一個Package

您可以使用Sitecore Rocks或Sitecore客戶端界面安裝一個Package，與Sitecore客戶端界面不同，當項目或文件已存在時，Sitecore Rocks不會提示用戶解決衝突。 它只是覆蓋它們。 在安裝軟體包之前，請務必使用Sitecore Rocks Analyze功能，以提醒您任何衝突。

我們建議您在安裝一個package之前創建實例的備份，當您需要撤消安裝時，您可以恢復到備份時刻。手動刪除Package並不總是可行，因為某些Package會覆蓋現有項。 當您確定沒有覆蓋任何項目時，您可以手動刪除該Package。

可以使用以下方法安裝包：

  • Sitecore Rocks
  • Control Panel

5.1 在多站點解決方案中配置新站點

Sitecore配置

在多站點環境中，每個站點都在Sitecore.config文件的<site>節點中單獨配置。 每個站點都有一個唯一的名稱屬性。 當請求到達Sitecore時，它將使用此節點中的信息來查找匹配的站點。 特別是Sitecore將使用請求URL中的埠，主機名和初始路徑將其與站點定義相匹配。 Sitecore按照配置中定義的順序評估每個站點。 它會選擇第一個匹配的定義。 這就是添加新定義時訂單的重要性。 您通常希望在默認網站引用之前添加自己的自定義網站定義。

請記住，您不直接修改sitecore.config文件，通常在自定義層中創建配置補丁文件。

您可以使用管道分隔列表將多個主機名分配給單個站點定義。 hostname屬性還可以包含通配符,例如：* .tac.local。

每個站點定義都在內容樹中定義一個開始項， 這將是用作解決URL其餘部分並找到相關上下文項的起點的主項。

默認站點配置位於<sites>節點下的/Website/App_Config/Sitecore.config中，可以使用許多個別設置將新網站添加到此部分，包括：

  • Site name (must be unique)
  • Root path + start item = the home item
  • Default language
  • Database
  • Cache settings

可用站點

以下是Sitecore空白副本中定義的所有網站的列表。 Sitecore配置為開箱即用的多個網站。

  • Shell是Sitecore客戶端應用程序，包括Launchpad以及可從中訪問的所有內容。
  • 管理員保護管理工具，例如<yoursite> /sitecore/admin/showconfig.aspx。
  • 網站是與Sitecore一起安裝的默認網站。

請記住，Order是非常重要的，缺少Order是多站點問題的主要原因之一。 例如，您可以配置通配符URL，但不要將它們放在列表中的第一位，否則其他站點將無法解析。

此列表中的最後三個站點，scheduler，system和 publisher與作業相關，可以在後台運行進程，如indexing，publishing， 或者其他的scheduled tasks。

默認安裝定義一個單個發布的網站和許多邏輯網站（在Sitecore.config中定義）。 這些邏輯站點在Sitecore內部使用（publishing，scheduling等）

Site 和 API

通常，您創建的組件可能需要同時在多個網站中使用。 您的代碼可能需要解析當前站點定義是什麼，哪個項對應於站點的根。

Sitecore.Context類包含有關當前請求的有用信息，包括哪個是當前站點。 以下是Sitecore.Context中可用的一些屬性的列表：

  • User - 發出請求的當前用戶（默認為extranet anonymous）。
  • Database - 包含此請求內容的資料庫。 例如，Web是對當前活動站點發出的請求的上下文資料庫。
  • Language - 當前請求的語言
  • Device - 包含發出請求的設備的信息
  • Site - 當前主機名所屬的站點定義

站點的開始項是<site>節點的rootPath和startItem屬性的組合。 使用Sitecore.Context.Site.StartPath屬性，您可以檢索站點的開始item的位置，然後可以使用該位置來檢索該項目。

Sitecore.Context類還包含Item屬性，在Sitecore MVC開發中，我們不建議再使用此屬性，因為它不會始終返回預期的Item，而是使用RenderingContext來檢索當前Item。

Sitecore.Context類是一個靜態類，包含有關當前HTTP請求和Sitecore安裝的信息。

  • Sitecore.Context.User
  • SItecore.Context.Database
  • Sitecore.Context.Language
  • Sitecore.Context.Device
  • Sitecore.Context.Site

站點的home page或開始item是定義在Sitecore.config中的， 它是<site>節點的rootPath和startItem屬性的組合，要輕鬆檢索網站的開始item位置，請使用：

string startPath = Sitecore.Context.Site.StartPath;
Item Homepage = Sitecore.Context.Database.GetItem(startPath);

多站點實現和內容結構

當您安裝Sitecore時，您將獲得一個Home itemm和Single website，您可以將您的網站內容放在Home item下。

在多站點實現中，我們建議您在content tree的 content section 中為每個站點創建一個文件夾。 每個站點文件夾都有自己的Home item，並且都在Sitecore站點配置中定義。 站點文件夾映射到rootPath屬性，而Home item名稱是startItme，即使您只有一個站點，也可以按照多站點建議進行操作。 如果您以後需要添加其他網站，這將避免出現一些問題。

創建一個與網站密切相似的content structure。 這使您可以輕鬆構建導航控制項，還允許您使用安全規則輕鬆拒絕或授予對content tree的各個部分的訪問許可權，以及簡化在content structure中查找任何給定項目的任務。

默認情況下，樹的結構會對URL產生影響，如果將項目放在文件夾中，則該文件夾名稱將成為URL的一部分。 不要將應該通過URL訪問的項目（並且設置了演示文稿詳細信息）放在站點的Home item之外，因為這會將/Sitecore/content添加到URL。

在「Media Library」、「Layouts」和「Templates」文件夾中，我們建議您創建一個Project或站點文件夾，並在其下構建邏輯子文件夾結構。

默認安裝使用Path： sitecore / Content / Home定義單個網站和Home item：

知識點

對於多站點實施，我們建議：

  • 為每個站點創建一個文件夾
  • 確保每個站點文件夾都有自己的Home Item
  • 共享內容應存儲在每個站點文件夾之外

相關資料:

Architecture overview?

doc.sitecore.com圖標xConnect?

doc.sitecore.com

2.1. Architecture Principles?

helix.sitecore.net圖標
推薦閱讀：
相关文章