动态

详情 返回 返回

將您的基於 Accelerator 的 SAP 電商雲 Storefront 遷移到 Spartacus Storefront - 动态 详情

原文:Migrate Your Accelerator-based Storefront to Project Spartacus

如果您已閲讀過“遷移到 Spartacus javascript storefront 項目的五個原因”和“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 文檔並查看模塊和組件目錄。它看起來像這樣:

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

BannerModule

@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 店面的描述,以瞭解主要區別。

Accelerator Storefront

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

大多數狀態都保存在服務器端。

Spartacus Storefront

在無頭店面中,前端加載在瀏覽器上,頁面結構和佈局從服務器檢索(除非它具有靜態佈局)。 Spartacus 組件(參見上面的模塊和組件)用於在客户端構建頁面,它們執行對服務器的 OCC 調用(參見上面的 OCC API)以檢索渲染所需的數據。 但是,出於性能和 SEO 的目的,初始頁面可能最初是在服務器上構建的(使用稱為服務器端渲染 - SSR 的技術)。

狀態保存在客户端。

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

還需要更改內容目錄,Spartacus 文檔很好地概述了加速器和 Spartacus 示例數據之間的差異。

最後,您可以在 Chrome 開發人員工具的幫助下分析產品詳細信息頁面的示例調用,以瞭解所有內容是如何組合在一起的。使用網絡選項卡查看 Spartacus 生成的請求。

使用 Augury Chrome 插件,您可以在瀏覽器中構建頁面後查看生成的組件層次結構。

Starting the Migration

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

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

在編輯現有店面中的給定頁面以檢索組件詳細信息時,您可以在 SmartEdit 中過濾對 /pagescontentslotscomponents 的請求。

Components used in the Accelerator Product Details Page

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) 佈局的部分組件化。

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

// 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 的技術)。 狀態保存在客户端。

Conclusion

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

更多Jerry的原創文章,盡在:"汪子熙":

user avatar 6fafa 头像 yunpan-plus 头像 qqxx6661 头像 minghuajiwu 头像 slnongchang 头像
点赞 5 用户, 点赞了这篇动态!
点赞

Add a new 评论

Some HTML is okay.