我第一次看到这张图时，觉得它挺有意思的。
因为这张图表面上是在讲 SAP Fiori 的几种部署方式，embedded、hub、BTP、Cloud Connector、Gateway、Integration Suite，这些方块一摆，看起来像一张标准架构图。
但真正做过 Fiori 项目的朋友们都懂，在实际项目里，大家反复争论的，根本不只是技术组件放哪儿这么简单。
大家反复斟酌和讨论的，是入口要不要统一，前端生命周期能不能和后端解耦，OData 服务谁来承接，权限和角色怎么分层，内网系统怎么安全接到云上，未来到底是继续守着一套 ABAP 系统做到底，还是慢慢走向 BTP 上的统一体验。
更准确一点讲，SAP Fiori Deployment options 这件事，讨论的从来都不是部署本身，而是企业到底想把自己的数字化体验做成什么样子。
我们再回到这张图，先看看它的整体结构。
上半部分是 SAP Business Technology Platform，也就是大家现在最常聊的 SAP BTP.
这个区域里放了 SAP Fiori UIs、Custom Apps、FLP content、API Management，还有 SAP Integration Suite.
这个摆法其实已经把 SAP 的态度写在图里了，SAP BTP 不是单纯拿来放几个前端工程的静态文件的。
它想承接的，是统一入口、扩展应用、API 治理和集成编排这一整套能力。
换句话讲，云上这块不只是一个前端托管层，更像一个体验和集成的中枢。
这里有几个概念，项目里特别容易混。
SAP Fiori UIs，指的是用户真正看到的那些应用界面。
它可能是 SAP 标准 Fiori 应用，也可能是基于 SAPUI5、Fiori Elements，甚至一些扩展方案做出来的页面。
Custom Apps 则更偏向企业自己做的 side-by-side extension，很多时候是为了补 SAP 标准流程里没有覆盖好的业务细节。
至于 FLP content，它不是业务数据，也不是页面代码，它管的是用户怎么进入这些应用，catalog 怎么组织，tile 怎么展示，target mapping 指向哪儿，space 和 page 怎么安排，角色和内容怎么映射。
这一块内容笔者之前的文章已经详细介绍过：
很多 Fiori 项目上线的时候，最开始很多项目开发人员觉得应用能打开就算完成了，结果业务一进系统，发现找不到入口，或者测试环境和生产环境 launchpad 里内容不一致，最后问题都落在 FLP content 没被当成正式交付物去管理。
这个坑，真的太常见了。
其实笔者之所以能写出上面这许多文章，无非也是这些坑我都踩过，早已身经百战。
再往下看，中间那条很醒目的橙色横条，就是 Cloud Connector。
这个组件很关键。它不是把内网系统直接暴露到公网，也不是一个随便的代理层。
它本质上是一条受控连接通道，让 SAP BTP 上的应用可以安全访问 on-premise 系统。
图里从 SAP BTP 往下连 SAP S/4HANA、Business Suite、其他 SAP 系统，甚至 non-SAP 系统，这些通路背后都在提醒我们一件事，今天很多 Fiori 项目已经不是单一系统内部署了，而是一个云上体验层去连接企业原来那些复杂的内网能力。
然后，就可以真正进入 Deployment options 了。
FES embedded deployment
先聊最左边的 FES embedded deployment.
这种模式其实最直观。
FLP content、Fiori UIs、GW Hub FW、GW Back-End FW，还有业务后端，都放在同一个 SAP S/4HANA 或 Business Suite 系统里。
对于很多 SAP S/4HANA on-premise 项目来说，这就是最自然的起点。
前端资源、launchpad 内容、Gateway runtime、业务逻辑，全都在一套 ABAP 系统里，开发、配置、排错，路径都比较短。
浏览器发起一个 OData 请求，进入 ICF，走 SAP Gateway runtime，再到后端的实现逻辑，整条链路很清楚。
开发人员查日志的时候，/IWFND/ERROR_LOG、/IWBEP/ERROR_LOG、ST22、SU53、ST05 这些事务码，基本也都在一套系统里打转。
对顾问和开发来说，这种排错体验是很舒服的。
这种 embedded 模式的优点，就是简单。
系统少，边界清晰，少很多跨系统联调的问题。
尤其当你的企业就是一套主 ERP，流程也没有特别复杂的跨系统协作时，它真的很务实。
很多标准 Fiori 激活、角色配置、task list 自动化设置，在这种模式下也最顺手。
项目推进时，不容易因为系统过多把问题搞得特别绕。
但 embedded 的代价也很明显。
UI 层和后端层绑得很紧。
前端应用版本、Fiori UI 组件、业务功能版本、系统升级节奏，基本是绑在一起走的。
短期看很省事，长期看会有点重。
尤其当企业开始有多套 ERP、多套 S/4HANA，或者不同业务线需要统一入口时，你就会慢慢发现，一个系统一个入口，一个系统一套内容，用户体验很容易被切碎。
今天采购进这个 launchpad，明天销售进另一个 URL，后天财务又去第三个地方。
久而久之，所谓的企业级统一体验，其实就没了。
FES hub deployment
这时候，FES hub deployment 的价值就出来了。
这个方案的思路是，把 SAP Fiori Front-end Server 单独拉出来。
独立的 FES 系统里放 FLP content、Fiori UIs、GW Hub FW，而真正的业务后端仍然留在 SAP S/4HANA 或 Business Suite 里，后端系统保留 GW Back-End FW.
这样做的好处很直接，前端入口和 UI 资源可以集中管理。
一个企业如果同时跑 ECC、CRM、SRM、BW，甚至还有不同区域的 S/4HANA，各套系统都自己带一个入口，用户体验一定是裂开的。
FES hub 的意义，就是把这些后端能力往一个统一前端入口上收。
从架构治理角度看，hub 模式特别适合多后端景观。
因为它把 UI 和 launchpad 这层抽离出来了。你可以集中维护 catalog、tile、target mapping、主题、角色映射，用户只需要记住一个入口。
对于企业 IT 来说，这比到处散着几个 Fiori launchpad 要整齐太多。
尤其是一些集团型组织，区域公司、事业部、共享服务中心背后系统很多，这种集中入口的意义，不只是好看，而是真的能降低使用门槛。
但 hub 模式也不是没有代价。
代价就是复杂度上来了。
前端资源在 FES，OData 服务可能在 FES 注册，但业务实现并不在那台机器上，而是在另一个后端系统里。
于是权限会分层，日志会分层，问题也会分层。
用户能看到 tile，不代表后端就有业务授权。
后端业务对象有权限，不代表 launchpad 一定能展示入口。
你排查一个 403、404、500，有时候不能只盯着浏览器 Network 面板，要同时去看 hub 和 back-end 两边的日志，甚至还得看 RFC、system alias、服务激活状态。
做过这种项目的朋友，应该都懂那个感觉：前端看起来像是一个简单报错，背后经常是一串跨系统链路。
Gateway embedded
再往中间看，图里还有一组容易被忽视的东西，Gateway embedded 和 Gateway hub.
这个地方很容易和 FES embedded、FES hub 混在一起聊，但它们其实不是一个维度。
前者讨论的是 FLP content 和 UI 放在哪里，后者更关注的是 OData provider 由谁承接，Gateway runtime 怎么布置。
也就是说，前端入口是一层问题，数据服务承接是另一层问题。
Gateway embedded，可以理解成 Gateway hub framework 和 Gateway back-end framework 都靠近业务系统。
图里的意思其实很明确，就算你的前端入口已经放到了 BTP，上面的 FLP content 和 Fiori UIs 不再在内网 FES 里，OData 请求穿过 Cloud Connector 回到企业内网后，仍然可能由业务后端系统里的 Gateway runtime 来接。
这个模式的好处，是业务语义离数据最近。
你做 OData 服务、CDS、RAP、注解、value help、draft、side effect，很多东西都不用再经过额外一层转发，链路更直接。
Gateway hub
Gateway hub 则是另一种思路。
它把 Gateway hub framework 单独放在一个网关系统里，后端系统只保留 GW Back-End FW.
这个部署方式在老一点的 Business Suite 整合场景里很常见，因为它能用一套 Gateway hub 去服务多套后端系统，统一暴露 OData endpoint，统一做服务注册和管理
。对于一些历史包袱比较重、后端系统不想大动的企业，这种方式很现实。
我们不用在每个后端里都去折腾 UI 相关组件，但代价就是多了一层转发，多了一层系统别名、多了一层缓存和排错复杂度。
尤其做 Fiori Elements 的时候，一旦 metadata、annotation、service registration、system alias 这些地方有一点点不一致，前端表现出来的症状经常很诡异。
像字段莫名其妙不见了，Smart Filter Bar 行为不对，Value Help 加载异常，开发人都快看麻了，说多了都是泪。
API Management
然后我们再抬头，看图上方那个带星号的 API Management。
这个星号挺传神的，因为它在很多场景下确实是 optional component.
不是所有 Fiori 项目都需要套一层 API Management.
很多内部应用，前端通过 destination 加 Cloud Connector 去访问 OData 服务，其实已经够用了。
既然我们有了 principal propagation，有基础的权限设计，系统边界又比较清晰，这时候再硬塞一层 API Management，未必真的有收益。
但只要接口的消费方开始变多，情况就不一样了。
比如同一组 API 要被多个前端应用、移动端、合作伙伴系统、低代码平台，甚至一些非 SAP 系统反复调用，这时候 API Management 的价值就出来了。
它更像一个 API 产品化的治理边界，能做限流、认证、Header 和路径改写、监控、审计、配额控制、开发者门户管理这些事。
它适合做门禁，做流量治理，做观测，不适合承载复杂业务逻辑。
业务语义还是要留在 OData 服务设计和后端模型里，如果脑子一热把权限判断和业务规则塞进 policy 脚本，后面维护起来真的会有点灾难。
再看图里另一大块，SAP Integration Suite.
这个组件出现的位置，已经说明它处理的不是单纯 OData 转发，而是更宽的集成问题。
图右上角单独画了 OData Service 和 Data Source，这个细节特别关键。
OData Service 更贴近 Fiori 的消费方式，它很适合列表页、对象页、筛选、导航、表格绑定这些典型 SAP Fiori 交互。
可企业真实世界里的数据源，哪有这么规整？
我们会遇到 REST、SOAP、文件、消息、第三方 SaaS、JDBC、事件流，各种都有。
要是让前端直接去连这些东西，浏览器就会背上巨大的集成复杂度，最后 UI 不像 UI，集成不像集成。
Integration Suite 的价值，就是把这种复杂性放回平台层。
前端该关心的是用户任务流和交互语义，集成平台关心的是协议适配、数据转换、跨系统编排、消息可靠性、流程联动。
这个分层特别重要。
一个成熟的 Fiori 架构，不是让前端应用自己东拼西凑地去调一堆接口，而是让它站在一个更干净的平台能力之上。
这样做出来的 UI，才不会越来越重，越来越难维护。
说到这里，SAP 想在这张图背后真正表达的东西，其实已经很清楚了。
不是组件越多越高级，也不是上了 BTP 就天然先进。
核心是统一入口和任务连续性。
SAP Fiori Launchpad 不只是一个放 tile 的壳子，它承载的是 shell、角色入口、intent-based navigation、personalization、跨应用跳转这些体验基础设施。
用户做业务的时候，不会按照系统边界思考问题。
销售不会说，我现在先切去 S/4HANA，再切去 CRM，再切去第三方报价平台。
他想的是，我今天要把这个客户的事处理完。
好的部署方案，就是把这些系统边界尽量藏到后面，让用户看见的是一条连续的任务路径。
这也是为什么 SAP BTP 那个大框看起来格外显眼。
它代表的是一种更面向未来的思路，把标准 Fiori、Custom Apps、统一 launchpad 内容、API 治理、集成编排，都往一个云上的体验平面里收。
这样做的好处，不只是前端托管更灵活，而是企业可以逐步把原来分散在不同系统里的体验组织起来。
今天先把入口统一，明天再把自研扩展放进去，后天再接几个非 SAP 系统。
这个过程不是一夜之间重构所有东西，而是慢慢把原来散乱的数字化体验收拢起来。
当然，这也不代表所有项目都要一股脑全搬到 SAP BTP 上。
真到 Fiori 项目里，选部署方案还是得看现实。
单一 SAP S/4HANA on-premise，标准流程为主，团队想尽量简化复杂度，embedded FES 往往是很稳的起点。
多后端系统并存，需要统一入口和集中前端治理，FES hub 会更合适。
老系统多、OData 服务暴露需要集中化，又不方便大改后端，Gateway hub 可能仍然有实际价值。
混合云场景明显、非 SAP 系统也深度参与业务、扩展应用越来越多，那 BTP、Cloud Connector、Integration Suite，再加上必要时的 API Management，这套组合就会更自然。
所以，怎么判断自己该选哪条路？
如何选择合适的部署模式？
我一般会先问客户几个很实际的问题。
你的企业到底有几套后端系统？
是真的一套 ERP 打天下，还是一堆历史系统并存？
你要不要一个统一入口，还是每个系统各自登录也能接受？
前端应用的生命周期，是否需要和后端升级解耦？
你现在的接口形态，主要是 OData，还是已经有很多非 SAP、非 OData 的数据源进来了？
安全团队是不是很强调 API 审计、限流和统一治理？
运维团队能不能承担多系统架构带来的排障成本？
把这些问题想清楚，部署方案基本就不会选得太离谱。
对 SAP UI5 和 Fiori Elements 开发团队来说，这个选择尤其重要。
因为它会直接改变你的开发方式和交付方式。嵌入式 FES 下，你可能更多面对的是 BSP repository、系统内服务激活、同系统配置协同。
到了 SAP BTP，你的日常就会变成 HTML5 application repository、destination、身份传播、approuter、launchpad service 这类东西。
到了 Gateway hub 场景，service registration、system alias、RFC destination 和后端实现之间的对应关系，如果文档不清楚，后面从 DEV 到 QAS 再到 PRD，真的很容易出幺蛾子。
那种 UI 能打开，但数据源指错了，或者 metadata 缓存没刷新，或者 annotation 版本不一致的痛，做过的朋友都会有体会。
最后总结一下。
这张图里每个方块都不是孤立的。
FLP content 管入口，Fiori UIs 管界面资源，GW Hub FW 管前台 OData runtime，GW Back-End FW 管后端服务实现，Cloud Connector 管云到内网的安全连接，API Management 管 API 的治理边界，Integration Suite 管跨系统集成。
真正好的 SAP Fiori Deployment，不是把这些组件堆满，也不是追求一个听起来最先进的名字，而是让每一层只做自己最擅长的事。
UI 层轻一点，业务语义留在服务和后端模型里，复杂集成交给 Integration Suite，API 出入口交给 API Management，用户入口由 FLP content 统一组织。
这样搭出来的 Fiori 架构，才不是几个页面能不能打开的问题。
而是一套能长期演进、能跨系统协作、也能被团队真正维护住的企业级体验底座。
更多阅读
扫一扫
1772
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
