ITPub博客

Multiple Country Site Support 为管理包含多个内容目录并使用内容继承的站点提供原生支持。它可以重用从顶级父目录到较低级别的国家、地区和本地内容目录的组件和页面，以及无缝站点导航。 在多国家、多渠道或多品牌的背景下，多个网站需要跨不同的网站显示相同的页面和/或组件，但它们也可能希望显示特定于每个地区、渠道或品牌的内容。SmartEdit 支持通过使用共享的全局内容目录和

B2C Accelerator module 是一组扩展(extensions)的集合，提供了启用能够完全正常工作的店面所需的所有 sample 数据。所包含的数据集用于服装店面(apparel)和电子产品(electronics)店面。 从下图能够看出，apparelstore 和 electronicsstore 都依赖于 core-Accelerator 的 acceleratorser

我们可以在 SAP Commerce Cloud Backoffice Administration Cockpit 中为 CMSSite 设置默认语言。可以通过为 CMSSite 实例或 BaseStore 实例设置默认语言来设置它。 站点的默认语言设置为 SmartEdit 提供了关于在其界面中显示的语言的信息。 CMSSite：在 CMSSite 实例中设置默认语言。 BaseSt

Spartacus中的 checkout 特性是CMS驱动的，这意味着 checkout 流中的每个页面都基于CMS页面、slots 和 Component。因此，开发可以更改每个页面的内容、添加新组件、将 checkout 转换为单步骤签出，或者在店面应用程序中只需要少量配置就可以创建非常复杂的多步骤 checkout 工作流。 在 checkout 过程中，通常有从一个步骤到另一个步骤的链接

Spartacus是一个开源的JavaScript web应用程序，允许您快速创建自己的基于JavaScript的SAP商务云店面。Spartacus是用Angular编写的，并以库的形式发布。使用Spartacus的推荐方法是构建自己的JavaScript web应用程序并导入库。无需修改，店面就能开箱工作，但 Spartacus 被设计为可升级、可定制和可扩展的，以满足您所有的品牌和功能需求。

Spartacus是一个基于 Angular 的店面，是为SAP Hybris Commerce/ SAP Commerce Cloud设计的。它使用REST API与Hybris Commerce交互。在初始阶段，它就提供了Hybris店面的大部分核心功能。Spartacus 是可扩展和可定制的。 Spartacus有一个解耦的架构，这意味着店面本身作为一个独立的实体，在它的OOTB特性之

商业体验的数字化一直是许多 SAP 客户的主要关注点，为了在品牌和消费者之间建立信任关系，客户生命周期是至关重要的。SAP 客户数据云(Customer Data Cloud)和 SAP 商务云(Commerce cloud)不仅为解决这些挑战提供了解决方案，而且还通过标准的开箱即用功能和集成简化了实现过程。 在我们讨论具体的功能和设计注意事项之前，了解每种产品的作用是很重要的。 SAP Cu

在SAP官网 help.sap.com 上根据关键字 commerce 搜索，结果列表里会显示出好几个名称相近的产品，这难免会让一些 SAP commerce (电商云)的初学者感到有点疑惑。 其实只需要耐心地打开这些链接逐一阅读一会儿，就能弄清楚这几个产品间的差异： SAP Commerce：SAP On-Premises上的电商解决方案 SAP Commerce Cloud on

From another side, Spartacus itself doesn’t provide a way to implement sitemap, but we have tickets open pending implementation: https://github.com/SAP/spartacus/issues/6244 and https://github.com/SAP

问题和观察关于由 Spartacus 驱动的页面或组件请求的一个疑问。 请求负载中的 componentIds 是由 CmsService.getComponentData 调用定义的，堆叠起来，然后通过一些优化立即发送到后端。 如果二次开发人员连续多次调用 CmsService.getComponentData（在同一个 JS 宏任务中），那么 Spartacus 会将这些调用分组，并且

打开 saample 仓库里 manifest.json 文件，地址如下： https://github.com/SAP-samples/cloud-commerce-sample-setup/blob/2105-spartacus/js-storefront/manifest.json 在 Application 数组里添加新的元素： 将清单文件中声明的新应用程序的文件添加到代码存储库

SAP Commerce Cloud 使用单个 Git 存储库作为项目 Customization 的来源，采用单一构建过程来构建整个应用，并且将整个应用程序的构建结果，采用单一部署过程部署到目标环境。 Commerce Cloud 构建过程使用递归选项克隆项目存储库。它允许您将其他存储库（称为Sub modules）插入主存储库。 当多个团队为同一个项目存储库做出贡献时，这种方法很有用。 每个

在构建时，SAP Commerce Cloud 标准的文件目录是可写的，因为构建过程本身需要修改这些文件目录。但是不推荐客户的 Customization 里也对这些 SAP Artifacts 做修改，因为这违反了开闭原则，可能会引起潜在的问题。SAP 推荐客户使用 Commerce Cloud 自带的 Extension 机制来进行定制化。 不要在不受构建过程管理的任意目录中写入任何内容，即

SAP Commerce Cloud 的构建发生在一个专门的构建环境中，该环境不同于最终的 Commerce Cloud 运行环境上。 二者的差异包括： 构建环境具有与 Commerce Cloud 不同的 Credential 目录结构不同 扩展是由命令行 ant production 打包的，因此它们的结构与构建时不同 构建环境可以安装不同的工具，例如 Java 编译器。 基础

SAP Commerce Cloud 的构建与环境无关，即所谓的 environment agnostic，这意味着同一个构建可以适用于多个 Commerce Cloud 环境。这种设计的优点是，在开发或 staging 环境中测试的相同代码，可以不被修改地直接部署到生产环境中。 特定于环境的设置包含但不局限于下列这些示例： 域名IP 地址SSL 证书资源（数据库、媒体存储）的 URL 或

SAP Commerce Cloud 中的构建过程，会根据客户的 Github 代码存储库中的信息，构建出最终运行的软件。 Github 仓库的一个例子如下： Commerce Cloud 中的构建过程包含下列这些操作： 克隆包含了客户实现项目 Customization 的 Github 仓库下载所需的 artifacts 构建最终软件将软件打包到 Docker 镜像中将镜像上传到

Commerce Cloud 中的构建过程在项目存储库中查找项目自定义 customization. 有两种支持的自定义目录结构。 Separate subdirectories for each customization这是默认并且推荐的选择。 每个自定义使用单独的子目录。如下图所示： 在此配置中，构建器希望找到一个 core-customize 子目录和几个可选目录。 cor

SAP Commerce Cloud CCV2 构建过程期望您的代码存储库具有特定的结构(Specific Structure)。 当您的存储库遵循预期的结构时，构建会正确生成。 默认情况下，所有自定义项都存储在单个 Github 存储库中。 它可以包含核心定制（扩展、配置）、数据中心定制和 Javascript 店面。 您可以使用 git submodules 功能将内容拆分为多个存储库。

loading 从 true 变为 false： 单从这个 initiator 栏，是很难找到是哪一行应用代码，发起的这个 cart 加载： 根据 [Cart] Load Cart 关键字搜索是能找到的： 最后找到了准确的代码行数，调用 CartConnector 去读取数据： 首先查看针对这个 cart，是否存在 pending 请求： 使用 withLatestFrom

IsStable：首先 false，然后 true @NgModule() export class CartPersistenceModule { static forRoot(): ModuleWithProviders<CartPersistenceModule> { return { ngModule: CartPersistenceModul