关于sap:SAP-Spartacus简介

35次阅读

共计 2470 个字符，预计需要花费 7 分钟才能阅读完成。

终于写到 Jerry 目前正在做的开发工作了。

2015 年的时候，那时 Jerry 曾经做了一年多的 SAP UI5 开发，想进一步精进本人的开发技能，就申请了一个位于德国 Walldorf 总部的 UI5 Extensibility 开发的 Fellowship Program，为期 6 个月。Jerry 发了简历给接管 Fellowship 的团队老板，很快收到回复，团队老板对我的简历很感兴趣，然而示意这个 Program 没有 Relocation Budget，如果我过来，在 Walldorf 的住宿得我本人掏钱解决。因为这不是商务出差，因而也不会有专门的共事帮我在当地租房。想到这一系列的麻烦，最初我只能放弃。

没想到五年之后，我再次取得了另一个纯前端的开发机会，SAP Spartacus.

什么是 Spartacus？Spartacus 是 SAP Commerce Cloud 的 Storefront(电商铺面)利用，基于 Angular 开发而成。

借助 SPA(Single-Page-Application)和 PWA(Progressive-Web-Application)个性的反对，Spartacus 可能提供近似原生利用的用户体验，同时具备高度的可配置性和可扩展性。

先看看 Spartacus 长什么样。对于国内习惯了网购的敌人来说，无需任何培训就能毫无艰难地应用 Spartacus 进行购物下单，这些操作流程咱们曾经相熟得不能再相熟了。

浏览商品，增加到购物车，领取。

可能大家会感觉下面截图的界面比拟奢侈，不够好看？后面曾经提到，Spartacus 具备高度的可配置型和可扩展性，SAP 客户能够基于 Spartacus 开发出具备本人举世无双格调的 Storefront 利用。

一个胜利案例就是，乐高的在线销售 Storefront.

Spartacus 最显著的两个特点：

开源(https://github.com/SAP/sparta…
以库文件的模式公布

也就是说，客户只须要新建一个 Angular 利用，在 package.json 里增加对 SAP Spartacus 库文件的依赖，就能够应用上图所示的 Spartacus Core 和 UI Component，开发满足本人理论需要的 Storefront 了。

下图就是 Angular 利用中的 package.json 文件中导入 Spartacus 的四个依赖库文件的形式：

客户采纳这种形式开发而成的 Storefront 利用，其自开发代码 (下图淡黄色矩形框所示) 是降级平安的，即自开发代码不会因为 Spartacus 库文件的版本升级而被笼罩掉。

Spartacus 是一个仍在继续开发的我的项目，目前最新的版本是 3.0. 通常状况下，每隔 6 个月会进行 Major 版本的更新，比方从 2.0 到 3.0. 每隔 6 周，会进行 Minor 版本的更新，比方从 2.0 到 2.1.

对 SAP Commerce Cloud 有所理解的敌人们都晓得，Hybris 以前还有一个基于 JSP 的 Accelerator，也能提供浏览店铺商品，退出购物车，结帐领取的性能，那么为什么 SAP 依然会启动 Spartacus 的开发，并在 2019 年 7 月正式公布了 1.0 版本呢？

我的共事张健 (Zhang Jonathan) 在他的文章从产品展现页面谈谈 Hybris 的特有概念和设计构造里给大家介绍过，Commerce Cloud 的前身 Hybris 是一个 monolithic(单体)利用，其中 Storefront 即 Accelerator 实现的技术栈是 JSP + Java，没有前后端拆散的概念。

Accelerator 尽管如张健文章里介绍的那样，具备高度可扩展性，然而也存在一些问题：

因为 monolithic(单体)利用的个性，Accelerator 自身也是 Commerce 平台的一部分，通过 Java 调用经 Facade Layer 作为入口，生产 Service Layer 的服务：

如下图高亮代码所示：

因而，Accelerator 和 Commerce 平台无奈别离进行降级。

另外，SAP 官网明确指出，因为 SAP 以源代码的形式公布 Accelerator，作为施行的模板，因而一旦客户开始了 Storefront 的定制化工作，批改了这些模板的源代码后，就无奈再导入针对当前工作版本的 Accelerator 的 bug fix. 这个情理同 ABAP Netweaver 外面，如果开发人员间接批改了规范代码后，打不了 SAP note 是一样的。

这也就是 SAP 官网上称 Accelerator 为 ”Extendable but not Upgradable” 的起因。

Commerce Accelerator 的这些有余，通过 2019 年诞生的 Spartacus Storefront 失去了补救：

Spartacus 和 Commerce 后盾的所有交互均通过 API 实现，Commerce API endpoint 通过环境变量 SPARTACUS_BASE_URL 注入 Spartacus，如下图所示：

应用 Spartacus，SAP Commerce Storefront 开发人员只须要专一于 Angular 开发。前后端拆散之后，Storefront 的开发，不再须要 Accelerator 时代的全栈开发模式。

以周为单位的 patch 公布频率，使得继续交付成为可能。同时，客户通过导入 Spartacus 库文件的形式进行 Storefront 的二次开发，其定制化代码和 Spartacus 库文件是独立的实体，能够别离进行降级；Spartacus 和 SAP Commerce 能够别离进行部署，亦可进行各自的降级。

更多对于 SAP Spartacus 的介绍，请参考 openSAP 上的公开课.

要获取更多 Jerry 的原创文章，请关注公众号 ” 汪子熙 ”:

更多浏览