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

如果您已閱讀過“遷移到 Spartacus javascript storefront 項目的五個原因”和“SAP Commerce Cloud Project Spartacus 入門”這兩篇文章，您可能想要遷移到基于無狀態(tài)高性能架構(gòu)的 storefront, 并且想知道如何實際準備 migration。 本文將討論一種適用于小型 storefront的遷移方法，但其流程也可以幫助大型項目遷移。不過對于后者，建議完全重新實施。

To Migrate or Not?

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

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

Prerequisites

建議您在升級到 SAP Commerce 1905 或更高版本后開始遷移到 Spartacus 店面，因為 Omni Commerce Connect (OCC) 應(yīng)用程序編程接口 (API) 的安裝方式已得到簡化（它們現(xiàn)在可用作擴展 extensions 而不是附加組件 addon）。

要開始使用，您還需要以下內(nèi)容：

初始設(shè)置

• 查看 Spartacus 的發(fā)行說明和路線圖，以確保您了解哪些功能具有同等性，哪些可能已更改，哪些可能缺失
• 升級您現(xiàn)有的店面以至少使用 SAP Commerce 1905
• 任何現(xiàn)有的 OCC 插件都已轉(zhuǎn)換為常規(guī)擴展（如果使用 SAP Commerce 2005 或更高版本）
• 您已完成“構(gòu)建和部署您的第一個 SAP Commerce Cloud 項目”的步驟。 您可能還需要查看安裝 SAP Commerce Cloud 2005 以與 Spartacus 一起使用中涵蓋的內(nèi)容，并確保您已配置并執(zhí)行了 Spartacus 項目設(shè)置。

Front-End Team

前端團隊將構(gòu)建由布局和 Angular 模塊組成的店面用戶界面。 開發(fā)人員的核心技能將是：

• Angular
• RxJS
• Spartacus
• HMTL5

Back-End Team

后端團隊將構(gòu)建前端團隊所需的 OCC API。 所需的核心開發(fā)人員技能是：

• SAP Commerce
• OCC

Anatomy of a Spartacus-based Storefront

在開始遷移之前，您應(yīng)該熟悉 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

您可能熟悉下圖左側(cè)的標準基于 Spring-MVC 的加速器，但請仔細查看右側(cè) Spartacus 店面的描述，以了解主要區(qū)別。

Accelerator Storefront

在傳統(tǒng)的店面中，瀏覽器向服務(wù)器發(fā)出請求，服務(wù)器檢索頁面結(jié)構(gòu)并執(zhí)行控制器、外觀和服務(wù)來處理和檢索呈現(xiàn)視圖所需的信息。

大多數(shù)狀態(tài)都保存在服務(wù)器端。

Spartacus Storefront

在無頭店面中，前端加載在瀏覽器上，頁面結(jié)構(gòu)和布局從服務(wù)器檢索（除非它具有靜態(tài)布局）。 Spartacus 組件（參見上面的模塊和組件）用于在客戶端構(gòu)建頁面，它們執(zhí)行對服務(wù)器的 OCC 調(diào)用（參見上面的 OCC API）以檢索渲染所需的數(shù)據(jù)。 但是，出于性能和 SEO 的目的，初始頁面可能最初是在服務(wù)器上構(gòu)建的（使用稱為服務(wù)器端渲染 - SSR 的技術(shù)）。

狀態(tài)保存在客戶端。

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

還需要更改內(nèi)容目錄，Spartacus 文檔很好地概述了加速器和 Spartacus 示例數(shù)據(jù)之間的差異。

最后，您可以在 Chrome 開發(fā)人員工具的幫助下分析產(chǎn)品詳細信息頁面的示例調(diào)用，以了解所有內(nèi)容是如何組合在一起的。使用網(wǎng)絡(luò)選項卡查看 Spartacus 生成的請求。

使用 Augury Chrome 插件，您可以在瀏覽器中構(gòu)建頁面后查看生成的組件層次結(jié)構(gòu)。

Starting the Migration

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

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

在編輯現(xiàn)有店面中的給定頁面以檢索組件詳細信息時，您可以在 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 支持幾乎所有響應(yīng)式 B2C CMS 組件，因此您只需關(guān)注自定義組件，以及來自標準庫中未涵蓋的第三方插件或市場擴展的組件。 根據(jù)功能區(qū)域?qū)λ鼈冞M行分組和分類，使用如下所示的組件清單。 請注意，與 Accelerator Page 方法不同，Spartacus 中的所有內(nèi)容都需要是一個組件，因此您可能需要將現(xiàn)有 Jakarta Server Page (JSP) 布局的部分組件化。

以下查詢?yōu)槟峁┝说昝嬷惺褂玫慕M件、頁面模板和頁面的概覽：

// Component list select{ct.code},{c.id},{ct.extensionName},count(*) as cnt from {AbstractCMSComponent as accjoin 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 ptjoin 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 apjoin 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 pjoin 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 pjoin 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）準備呈現(xiàn)頁面所需的上下文。 在 Spartacus 中，大部分工作已經(jīng)由框架執(zhí)行，但手動檢查可能需要移動到自定義 OCC 擴展或單個組件的邏輯是個好主意。

Step 2 - Perform a GAP Analysis

對于每個組件，確定是否有相應(yīng)的 OCC API 提供所需的數(shù)據(jù)（和相應(yīng)的可注入服務(wù)），否則描述將需要的 OCC 擴展。 此外，為每個組件設(shè)置開發(fā)優(yōu)先級（或重要性）。

Step 3 - Start the API Implementation

使用 API First 方法，創(chuàng)建缺失的 OCC 擴展并根據(jù)現(xiàn)有 OCC 服務(wù)的語義定義接口。 從空（或模擬）實現(xiàn)開始，因為這將允許前端團隊在下一步中并行開始工作。

使用 Swagger CodeGen 自動生成前端需要的 Typescript Angular 客戶端代碼。 使用必要的缺失字段增強 DTO。

Step 4 - Implement the CMS Pages and Components

創(chuàng)建一個基本的 Web 內(nèi)容管理系統(tǒng) (WCMS) 結(jié)構(gòu)來復(fù)制您當(dāng)前的店面并啟動您的 Spartacus 應(yīng)用程序。 在 Chrome 開發(fā)者工具中打開您的控制臺選項卡，您將看到每個沒有相應(yīng) Angular 組件的 CMS 組件的警告，也將顯示可用 CMS 插槽的警告。

驗證此信息是否與您的 CMS 組件清單相匹配。

在無頭店面中，前端加載在瀏覽器上，頁面結(jié)構(gòu)和布局從服務(wù)器檢索（除非它具有靜態(tài)布局）。 Spartacus 組件（參見上面的模塊和組件）用于在客戶端構(gòu)建頁面，它們執(zhí)行對服務(wù)器的 OCC 調(diào)用（參見上面的 OCC API）以檢索渲染所需的數(shù)據(jù)。 但是，出于性能和 SEO 的目的，初始頁面可能最初是在服務(wù)器上構(gòu)建的（使用稱為服務(wù)器端渲染 - SSR 的技術(shù)）。 狀態(tài)保存在客戶端。

Conclusion

本文提供了對 Spartacus 以及遷移現(xiàn)有加速器店面所需的技術(shù)的更多技術(shù)介紹。 遷移可能涉及大量的重新設(shè)計，但有切實的性能和維護優(yōu)勢使其值得。 仔細準備是成功遷移的關(guān)鍵。

更多Jerry的原創(chuàng)文章，盡在：“汪子熙”:

總結(jié)

以上是生活随笔為你收集整理的将您的基于 Accelerator 的 SAP Commerce Cloud Storefront 迁移到 Spartacus Storefront的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。