[原文：Migrate Your Accelerator-based Storefront to Project Spartacus](https://www.sap.com/cxworks/article/527293202/migrate_your_accelerator_based_storefront_to_project_spartacus)

如果您已閱讀過“[遷移到 Spartacus javascript storefront 專案的五個原因](https://www.sap.com/cxworks/article/480453417/five_reasons_to_move_to_a_project_spartacus_javascript_storefront)”和“[SAP Commerce Cloud Project Spartacus 入門](https://www.sap.com/cxworks/article/455575580/getting_started_with_sap_commerce_cloud_project_spartacus)”這兩篇文章，您可能想要遷移到基於無狀態高效能架構的 storefront, 並且想知道如何實際準備 migration。 本文將討論一種適用於小型 storefront的遷移方法，但其流程也可以幫助大型專案遷移。不過對於後者，建議完全重新實施。

# To Migrate or Not?

儘管建議將遷移到 Spartacus 作為重新開始和重新考慮您的店面體驗的機會，但您可能需要遷移到 Spartacus 並保持相同的體驗。根據自定義基於加速器的店面的數量和方法，您發現嘗試將現有體驗遷移到 Spartacus 變得簡單或困難。如果您不確定，您可以使用以下步驟進行練習，以確定更改的數量，而不必花時間實施。這可以讓您瞭解遷移與從綠地方法開始相比可能需要多少工作。

正如“SAP Commerce Cloud Project Spartacus 入門”中所述，您可以同時執行 Accelerator 和 Spartacus 店面以降低風險，但建議不要長時間這樣做。在兩個技術堆疊上維護兩個店面會使開發和測試變得非常困難，更不用說您可能會根據客戶點選的店面頁面給他們帶來不一致的使用者體驗。

# Prerequisites

建議您在升級到 SAP Commerce 1905 或更高版本後開始遷移到 Spartacus 店面，因為 Omni Commerce Connect (OCC) 應用程式程式設計介面 (API) 的安裝方式已得到簡化（它們現在可用作擴充套件 extensions 而不是附加元件 addon）。

要開始使用，您還需要以下內容：

## 初始設定

* 檢視 Spartacus 的發行說明和路線圖，以確保您瞭解哪些功能具有同等性，哪些可能已更改，哪些可能缺失
* 升級您現有的店面以至少使用 SAP Commerce 1905
* 任何現有的 OCC 外掛都已轉換為常規擴充套件（如果使用 SAP Commerce 2005 或更高版本）
* 您已完成“構建和部署您的第一個 SAP Commerce Cloud 專案”的步驟。 您可能還需要檢視安裝 SAP Commerce Cloud 2005 以與 Spartacus 一起使用中涵蓋的內容，並確保您已配置並執行了 Spartacus 專案設定。

## Front-End Team

前端團隊將構建由佈局和 Angular 模組組成的店面使用者介面。 開發人員的核心技能將是：

* Angular
* RxJS 
* Spartacus
* HMTL5

## Back-End Team

後端團隊將構建前端團隊所需的 OCC API。 所需的核心開發人員技能是：

* SAP Commerce
* OCC

# Anatomy of a Spartacus-based Storefront

在開始遷移之前，您應該熟悉 Spartacus 店面的工作方式。 首先訪問 Spartacus Storefront 文件並檢視模組和元件目錄。它看起來像這樣：

![](https://img-blog.csdnimg.cn/img_convert/e01805bc4fbbca30a3a6a0d9bfc93736.png)

瀏覽模組和元件並熟悉 Spartacus 提供的功能。 特別注意提供預設 CmsConfig 的模組，它定義了標準 CMS 元件和 Spartacus 元件之間的對映。 在下面的示例中，BannerComponent 提供到 SimpleResponsiveBannerComponent、BannerComponent 和 SimpleBannerComponent 的對映。

## BannerModule

```typescript
@NgModule({
  imports: [CommonModule, RouterModule, GenericLinkModule, MediaModule],
  providers: [
    provideDefaultConfig(<cmsconfig>{
      cmsComponents: {
        SimpleResponsiveBannerComponent: {
          component: BannerComponent,
        },
        BannerComponent: {
          component: BannerComponent,
        },
        SimpleBannerComponent: {
          component: BannerComponent,
        },
      },
    }),
  ],
  declarations: [BannerComponent],
  entryComponents: [BannerComponent],
  exports: [BannerComponent],
})
export class BannerModule {}
```

# Accelerator-based Storefront vs Spartacus-based Storefront

您可能熟悉下圖左側的標準基於 Spring-MVC 的加速器，但請仔細檢視右側 Spartacus 店面的描述，以瞭解主要區別。

![](https://img-blog.csdnimg.cn/img_convert/0af35ab78173335fe3d546e718e84b97.png)

## Accelerator Storefront

在傳統的店面中，瀏覽器向伺服器發出請求，伺服器檢索頁面結構並執行控制器、外觀和服務來處理和檢索呈現檢視所需的資訊。

大多數狀態都儲存在伺服器端。

## Spartacus Storefront

在無頭店面中，前端載入在瀏覽器上，頁面結構和佈局從伺服器檢索（除非它具有靜態佈局）。 Spartacus 元件（參見上面的模組和元件）用於在客戶端構建頁面，它們執行對伺服器的 OCC 呼叫（參見上面的 OCC API）以檢索渲染所需的資料。 但是，出於效能和 SEO 的目的，初始頁面可能最初是在伺服器上構建的（使用稱為伺服器端渲染 - SSR 的技術）。

狀態儲存在客戶端。

在遷移過程中，您將現有的加速器控制器功能分解為單獨的 Spartacus Angular 元件（也包括檢視/模板邏輯）和 OCC API，如虛線所示。 請注意，在某些情況下，可能還需要修改現有的底層外觀和服務。

還需要更改內容目錄，Spartacus 文件很好地概述了加速器和 Spartacus 示例資料之間的差異。

最後，您可以在 Chrome 開發人員工具的幫助下分析產品詳細資訊頁面的示例呼叫，以瞭解所有內容是如何組合在一起的。使用網路選項卡檢視 Spartacus 生成的請求。

![](https://img-blog.csdnimg.cn/img_convert/a1421e737c34af8082aefd8276a6f5fb.png)

![](https://img-blog.csdnimg.cn/img_convert/0bbe1d0d74ab44ab86c328e9ea22b845.png)

使用 Augury Chrome 外掛，您可以在瀏覽器中構建頁面後檢視生成的元件層次結構。
![](https://img-blog.csdnimg.cn/img_convert/6bae8521c0b4d04515304d940e6a26ae.png)

# Starting the Migration

## 步驟 1 - 清點您的 CMS 元件和頁面

對當前店面中使用的頁面和元件進行清點非常重要，如下表所示。 對於每個頁面，列出使用的控制器和自定義 CMS 元件，併為每個元件找出它需要顯示或處理的資料。 一些需要的資訊乍一看可能不可見，例如下拉框或彈出視窗。

在編輯現有店面中的給定頁面以檢索元件詳細資訊時，您可以在 SmartEdit 中過濾對 /pagescontentslotscomponents 的請求。

## Components used in the Accelerator Product Details Page

```typescript
0: {componentId: "SiteLogoComponent",…}
1: {componentId: "HomepageNavLink",…}
2: {componentId: "OrderComponent",…}
3: {componentId: "MiniCart",…}
4: {componentId: "ElectronicsCategoryNavComponent",…}
5: {componentId: "breadcrumbComponent",…}
6: {componentId: "TabPanelContainer",…}
7: {componentId: "FooterNavigationComponent",…}
8: {componentId: "MyAccountComponent",…}
9: {componentId: "MyCompanyComponent",…}
10: {componentId: "SearchBox",…}
11: {componentId: "VariantSelector",…}
12: {componentId: "AddToCart",…}
13: {componentId: "Similar",…}
14: {componentId: "CookieNotificationComponent",…}
15: {componentId: "AnonymousConsentManagementComponent",…}
16: {componentId: "AssistedServiceComponent",…}
17: {componentId: "ProfileTagScriptComponent",…}
18: {componentId: "PersonalizationScriptComponent",…}
19: {componentId: "BundleCarouselComponent",…}
```

開箱即用的 Spartacus 支援幾乎所有響應式 B2C CMS 元件，因此您只需關注自定義元件，以及來自標準庫中未涵蓋的第三方外掛或市場擴充套件的元件。 根據功能區域對它們進行分組和分類，使用如下所示的元件清單。 請注意，與 Accelerator Page 方法不同，Spartacus 中的所有內容都需要是一個元件，因此您可能需要將現有 Jakarta Server Page (JSP) 佈局的部分元件化。

以下查詢為您提供了店面中使用的元件、頁面模板和頁面的概覽：

```sql
// Component list
select
    {ct.code},
    {c.id},
    {ct.extensionName},
    count(*) as cnt
from {
    AbstractCMSComponent as acc
    join ComposedType as ct on {ct.pk} = {acc.itemtype}
    join CatalogVersion as cv on {cv.pk} = {acc.catalogversion}
    join Catalog as c on {cv.catalog} = {c.pk}
}
where {c.id} LIKE '%ContentCatalog' and {cv.version} = 'Online'
group by {ct.code}, {cv.version}, {c.id},{ct.extensionName}
order by cnt desc
// Page Templates
select
    {ct.code},
    {c.id},
    {pt.name},
	{pt.frontendTemplateName}
from {
    PageTemplate as pt
    join ComposedType as ct on {ct.pk} = {pt.itemtype}
    join CatalogVersion as cv on {cv.pk} = {pt.catalogversion}
    join Catalog as c on {cv.catalog} = {c.pk}
}
where {c.id} LIKE '%ContentCatalog' and {cv.version} = 'Online'
order by {ct.code}
// Pages
select 
	{ct:code},
    {c:id},
    {ap:name[de]},
    {ap:uid}
from {
    AbstractPage  as ap
    join ComposedType as ct on {ct.pk} = {ap.itemtype}
    join CatalogVersion as cv on {cv.pk} = {ap.catalogversion}
    join Catalog as c on {cv.catalog} = {c.pk}
}
where {c.id} LIKE '%ContentCatalog' and {cv.version} = 'Online'
order by {ct.code}
// Pages, Components and Slots
select
    {c.id},
    {cv.version},
    {p.uid}              as "Page",
    {pt.uid}             as "Template",
    {s4p.position}       as "Template assigned position",
    {st.uid}             as "content slot id 4t",
    {st.active}          as "content slot 4t active",
    {sn.templatePOS}     as "pos",
    {sn.name}            as "template available position",
    {comp.uid},
    {compt.code},
    {comp.visible}
from {
    AbstractPage as p
    join CatalogVersion as cv on {cv.pk} = {p.catalogVersion}
    join Catalog as c on {c.pk} = {cv.catalog}
    join PageTemplate as pt on {pt.pk} = {p.masterTemplate}
    join ContentSlotForPage as s4p on {s4p.page} = {p.pk}
    join ContentSlot as st on {st.pk} = {s4p.contentSlot}
    left join ContentSlotName as sn on {sn.template} = {pt.pk} and {sn.name} = {s4p.position}
    join ElementsForSlot as e2s on {st.pk} = {e2s.source}
    join AbstractCMSComponent as comp on {comp.pk} = {e2s.target}
    join ComposedType as compt on {compt.pk} = {comp.itemtype}
} where 
{cv.version} = 'Online' and {c.id} like '%ContentCatalog' 
order by {cv.version},{c.id},{p.uid},{sn.templatePOS},{comp.uid}
// Templates, components and slots
select
    {c.id},
    {cv.version},
    {p.uid},
    {pt.uid},
    {s4t.position}       as "template assigned position",
    {st.uid}             as "content slot id 4t",
    {st.active}          as "content slot 4t active",
    {s4t.allowOverwrite} as "template allow overwrite",
    {sn.templatePOS}     as "pos",
    {sn.name}            as "template available position",
    {comp.uid},
    {compt.code},
    {comp.visible}
from {
    AbstractPage as p
    join CatalogVersion as cv on {cv.pk} = {p.catalogVersion}
    join Catalog as c on {c.pk} = {cv.catalog}
    join PageTemplate as pt on {pt.pk} = {p.masterTemplate}
    join ContentSlotForTemplate as s4t on {s4t.pageTemplate} = {pt.pk}
    join ContentSlot as st on {st.pk} = {s4t.contentSlot}
    left join ContentSlotName as sn on {sn.template} = {pt.pk} and {sn.name} = {s4t.position}
    join ElementsForSlot as e2s on {st.pk} = {e2s.source}
    join AbstractCMSComponent as comp on {comp.pk} = {e2s.target}
    join ComposedType as compt on {compt.pk} = {comp.itemtype}
} where 
{cv.version} = 'Online' and {c.id} like '%ContentCatalog' 
order by {cv.version},{c.id},{p.uid},{sn.templatePOS},{comp.uid}
```

在標準加速器中，PageController（基於 AbstractPageController）準備呈現頁面所需的上下文。 在 Spartacus 中，大部分工作已經由框架執行，但手動檢查可能需要移動到自定義 OCC 擴充套件或單個元件的邏輯是個好主意。

## Step 2 - Perform a GAP Analysis

對於每個元件，確定是否有相應的 OCC API 提供所需的資料（和相應的可注入服務），否則描述將需要的 OCC 擴充套件。 此外，為每個元件設定開發優先順序（或重要性）。

## Step 3 - Start the API Implementation

使用 API First 方法，建立缺失的 OCC 擴充套件並根據現有 OCC 服務的語義定義介面。 從空（或模擬）實現開始，因為這將允許前端團隊在下一步中並行開始工作。

使用 Swagger CodeGen 自動生成前端需要的 Typescript Angular 客戶端程式碼。 使用必要的缺失欄位增強 DTO。

## Step 4 - Implement the CMS Pages and Components

建立一個基本的 Web 內容管理系統 (WCMS) 結構來複制您當前的店面並啟動您的 Spartacus 應用程式。 在 Chrome 開發者工具中開啟您的控制檯選項卡，您將看到每個沒有相應 Angular 元件的 CMS 元件的警告，也將顯示可用 CMS 插槽的警告。

驗證此資訊是否與您的 CMS 元件清單相匹配。

在無頭店面中，前端載入在瀏覽器上，頁面結構和佈局從伺服器檢索（除非它具有靜態佈局）。 Spartacus 元件（參見上面的模組和元件）用於在客戶端構建頁面，它們執行對伺服器的 OCC 呼叫（參見上面的 OCC API）以檢索渲染所需的資料。 但是，出於效能和 SEO 的目的，初始頁面可能最初是在伺服器上構建的（使用稱為伺服器端渲染 - SSR 的技術）。 狀態儲存在客戶端。

![](https://img-blog.csdnimg.cn/img_convert/ddc825f27fc089eb9e84878f2526afdf.png)

# Conclusion

本文提供了對 Spartacus 以及遷移現有加速器店面所需的技術的更多技術介紹。 遷移可能涉及大量的重新設計，但有切實的效能和維護優勢使其值得。 仔細準備是成功遷移的關鍵。</cmsconfig>

將您的基於 Accelerator 的 SAP 電商雲 Storefront 遷移到 Spartacus Storefront

相關文章