一份最近国内外 SAP 从业者在技术交流群里讨论的记录分享：为什么选 UI5 而不选 React

最近群里进行了一次有意思的讨论。因为微信群的聊天记录无法像 Slack 那样能够自动保存，所以我打算把这些有价值的讨论记录手动保存下来，也方便更多的朋友查阅。

有朋友提出，"公司 VP 认为，不管是什么技术，底层的 Foundation 要稳，这样才能在基础扎实的前提下，do correct things and do things correctly".

有一些朋友所在的项目，前端选型需要在 Fiori 和 React 之间做选择。

他们觉得疑惑，想知道 SAP 用 Fiori 而不用其他外部三大框架的意义在哪里？是 Fiori 某些地方更加契合吗？还是纯粹为了推而推？

上图两位来自上海和大连的朋友都指出了，Fiori 不是单纯的前端框架，而是设计规范，不限制开发语言。

确实笔者之前两篇文章，也提到了这些观点，对 SAP Fiori 和 SAP UI5 的区别和联系，做了辨析：

而且关于 "Fiori 没有 CI/CD", 这是一个伪命题。

SAP UI5 的 CI/CD 解决方案已经比较完善了，比如可以参考这篇 2018 年发表的 SAP 社区博客：

https://blogs.sap.com/2018/08/01/ci-cd-for-sapui5-on-abap-with-gitlab/

如果用其他前端框架开发企业级 Web 应用，我们还得另外找一套组件库。

Fiori 主要优势是有大量原生开箱即用的东西，有朋友提到："命运掌握在自己手里"，"毕竟 react 不能按照 SAP 的想法改吧"。

这里笔者可以举个例子。我们知道 SAP UI5 控件绑定了 OData 模型后，框架可以帮助我们自动向 OData 服务的实现者发送 HTTP 请求，背后是通过 datajs.js 这个第三方工具库实现的：

https://sapui5.hana.ondemand.com/resources/sap/ui/thirdparty/datajs-dbg.js

我们在 datajs.js 这个第三方实现的源代码里，看到了上图绿色注释的声明。

让 ChatGPT 机翻一下：

版权所有 (c) 微软。保留所有权利。

特此免费授予任何获得本软件及相关文档副本的人，以无偿的方式，在不受限制的情况下处理本软件的权限，包括但不限于使用、复制、修改、合并、发布、分发、许可和/或出售软件的副本，并允许有权处理本软件的人员在遵守以下条件的情况下这样做：

所有副本或实质性部分的软件必须包含上述版权声明和此许可声明。

本软件按"原样"提供，无论明示或暗示的，包括但不限于适销性、特定目的的适用性和非侵权性的任何保证。在任何情况下，作者或版权持有人均不对任何索赔、损害或其他责任承担责任，无论是合同、侵权或其他行为的结果，与软件或软件的使用或其他交易有关。

我们在 datajs.js 源代码里可以清楚的看到 SAP 对其进行的改动，SAP UI5 使用的正是这个修改之后的版本。

有朋友问：RAP(Restful ABAP Programming Model)替换之前 BOPF 的编程模型，意义在哪里？除了支持云以外。

Fiori 控件设计风格都是面向 business 的，2B，默认支持 Accessibility 键盘操作，给盲人操作啥的。因为 SAP 开发的标准产品，在全球各地销售，需要满足各种产品标准(Product Standards), 否则连发版的机会都没有。而国内不少公司特别是小型企业，销售的软件则不受这个限制，所以可以选择更轻量级的框架来开发。

所谓三大前端开发框架，是基于消费产品的，对于企业级应用支持的成熟度较差，需要很多工作量去适应企业应用的需求，而且前后台集成性比较弱。

基于 SAP UI5 做，最后至少节省一半的成本。

一位朋友做过三个内部项目，从所谓的前端流行技术栈转到 SAP 技术栈，基本整体成本降低到原来的 25%.

如果是简单的增删改查，通过 CDS View 的注解， 确实效率很高。

而且开发企业级应用，supportability 也是技术选型时需要考虑的因素之一。

有朋友吐槽，如果选择 React 等流行框架，出了问题得自己修。相反选择 SAP UI5，需要支持的时候，通过创建 ticket 走标准 Support 流程就行了。

SAP Fiori 应用这种前端 SAP UI5，后端 CDS View + 注解的开发方式，很像全栈开发，一个人干两个人的活，降低了沟通成本。

比如 SAP Fiori，假设需求是要一个 List Report，马上前台后台都知道怎么干活，List Report 这一个名词里，包含了千言万语。

如果想用 React 实现一个 List Report，估计光定义清楚 List Report 背后涵盖的用户需求，就需要用几个月的时间。

总之，SAP UI5 有开箱即用的组件，包括用 Fiori Elements，这些会缩短开发工期和成本，而且开发过程中如果出问题了，可以报 incident 给 SAP，这样运维压力小很多，压力分摊了部分给 SAP。

这道理好比采用 SAP CPI(Cloud Platform Integration) 和用 Java 自研一个类似 CPI 的集成平台，两种方案二选一。如果选择后者，最后遇到问题了，这种情况能找 SAP 抱怨吗？CPI 还有日志监控功能，系统连接啥的也挺容易，配置配置就出来了。Java 自研的话，这一切都得自己搞。

如果大家没有用过 React 的，可以尝试做一两个项目，算算成本。

就跟 Apple 自己搞一套 UI 和 Swift 一样，更好的封装，更好客户体验。拿过来苹果的产品，UI 操作逻辑都差不多，拿来就上手。SAP 的产品不也是么，除了极个别的没用 Fiori 的，其他的产品来操作逻辑都一样的，按钮的颜色位置，操作习惯都一样的，你不用 SAP S/4HANA 用别的系统也能快速上手。

一位朋友给出了一个具体的例子，找了两个 React 做前台，做了九个月，基本就是做了一个 Fiori List Report.

而用 SAP 正宗的技术做 List Report，不熟悉的朋友可以参考我这篇教程：

相信大家就算对 Fiori Elements 没有丝毫基础，算上从头开始学习的时间，做一个专业的 List Report 出来，也花不了 9 个月的时间。

有朋友认为，再一个优点是 Fiori 其实能把开发人员的技术水平极可能的拉平。

我们自有产品就用 React，结果这个技术选型虽然没问题，但是一到了不同的开发人员手上，那开发出的前端应用可就千差万别了。Fiori 能最大限度的让你技术水平不是很高的开发人员，开发出来的 App 质量也没那么的差。这个优点，几乎 SAP 所有的技术栈上都能体现出来，包括 ABAP.

在应用稳定性上来说，SAP 全系产品都给予了最大的保障。

再说到 Fiori 应用比 React 应用慢的问题，有朋友不是很理解，因为通常来讲企业级应用的性能瓶颈都在后台。如果觉得 Fiori 比 React 慢很多，这位朋友推测，要么后台连的不是 SAP，要么就是电脑配置太低了。

笔者注：如果觉得 SAP UI5 应用执行实在太慢，可以首先用 Chrome 开发者工具检测是否是前端渲染存在性能问题：

如果 UI5 应用采用 Fiori Elements 开发而成，前端渲染出现性能问题的可能性微乎其微。如果是 SAP UI5 Freestyle 应用出现了性能问题，可以按照笔者上面这篇文章，用工具让执行低效的 JavaScript 代码现出原形。

SAP UI5 和 React 这两个框架相比，SAP UI5 就像是工厂，用最快的生产效率，生产出符合所有规范，质量优秀的产品。React 是手工作坊，用来打造艺术品。

其实我们更多的时候，不就是在人员参差不齐或者交替变更的情况下，让我们的产出的品质尽量得保持一个较高的水平吗？这一点不是一直在追求吗？其实 SAP 这个套路已经符合这个目的了。