企业官网建设流程全解析

我做过很多Fiori项目，最深的体会是：客户提得最多的需求，往往不是什么大功能，而是一堆“小别扭”——这个字段不想要、那个字段要往前挪一挪、这条列表别显示那么多列、这个按钮的位置能不能换一下。放在传统UI5开发里，每一个都是改动、测试、传输打一套流程，少则一天多则一周。而SAP给出的解法，就是Key User UI Adaptation（关键用户界面适配）。

这套机制的价值一句话就能讲清楚：让业务Key User不写代码、不改程序，直接在运行的Fiori界面里完成字段显隐、布局调整、排序筛选等调整，改完可以只给自己用，也可以发布给所有人，还能绑定传输请求走标准流程发到测试和生产。对实施团队来说，它是把“低价值高频次”的界面微调需求从开发队列里分流出去的最有效工具；对业务侧来说，它意味着不再为一个小改动等排期。

这篇文章我会结合实操经验，把这套机制的底牌、操作流、常见问题以及治理方法完整讲一遍。适合Fiori顾问、Basis同事、负责权限的运维人员，以及正在带业务侧Key User的团队参考。

1. Key User UI Adaptation 到底是什么：先搞懂机制底牌

很多人一听"UI Adaptation"，第一反应是"这不就是个性化吗"。严格说，它跟最终用户在头像菜单里改主题、调主面板布局的Personalization是两回事。Key User UI Adaptation面向的是业务关键用户，权限更大、可改范围更广，而且能通过发布机制影响其他用户。

1.1 名字里的三个关键词，决定了它的定位

拆开看这个名字，三个关键词缺一不可。

Key User：定位是业务骨干，懂业务场景，但不一定懂技术。SAP希望把这群人变成"配置型管理员"，让他们承担界面微调职责。

UI：改的是界面层，不是数据层。它不会改变底层数据模型、权限对象、增强逻辑，只是在运行时对界面的呈现方式做调整。这意味着它对后台表结构零侵入，风险天然较低。

Adaptation：是"适配"不是"开发"。区别于传统改程序，它是基于某个已部署的UI5应用做增量调整，改动以"增量记录"的形式存在，而不是直接动应用源码。

理解这个定位很重要。我在项目里遇到过业务把Key User UI Adaptation当成"万能改法"，希望用它去增加一个全新的字段，因为它根本不在界面数据模型里，那是做不到的——这是Key User Adaptation的边界，也是很多需求被驳回的原因。

1.2 层叠式存储：一次点击背后的三层数据

要理解这套机制怎么运作，必须先理解它的存储模型。SAPUI5的灵活性（Flexibility）框架用"层（Layer）"来管理变更，你可以把它想象成一张张透明贴膜叠在应用画面上：

• 用户层（Personalization）：每个人可以保存自己关心的界面调整，只对自己可见，不进入传输。
• 客户层（Client）：Key User在适配模式下作出的调整，如果直接保存，会存在这一层，只在当前系统生效，所有用户都能看到，但不绑定传输请求。
• 传输层（Transportable Public Layer）：Key User在发布时绑定传输请求，变更进入CTS管道，可以跨系统传递。

实际点击"Adapt UI"进入界面后，你会看到"保存"和"发布"两个动作，这背后就是在选择把这些增量写到哪个层。保存到客户层，对当前系统的所有人都生效；发布并绑定传输，则可以跟着传输请求走。这也是为什么很多人在测试环境改得好好的，到生产环境看不到改动——大概率是只保存了客户层，没有绑定传输。

提示：如果你希望改动只在特定系统出现，包括留存在客户层并不放入传输请求，这通常用于生产系统上绕过传输直接做热修复。但从治理角度，后续我会建议慎用这个口子。

1.3 能改什么、不能改什么：边界先画清楚

从实践来看，Key User UI Adaptation能做到以下事情：

• 隐藏、显示界面字段
• 调整字段顺序、移动字段到其他区域
• 调整表单分节、折叠/展开部分区域
• 配置表格列顺序、宽度、冻结列
• 恢复KPI、图表等卡片组件的部分属性
• 管理Smart Filter Bar的筛选字段、默认值
• 设置表格排序、过滤条件
• 配置多语言标签（在不改代码的前提下调整界面文案）

但它有明确的做不到的事：

• 增加一个数据模型里不存在的字段
• 改动后端逻辑、校验规则、读写权限
• 改变应用跳转逻辑（除非应用本身提供扩展点，但通常需要开发介入）
• 修改安全相关字段的控制属性

理解"边界"是管理好这套工具的第一步。如果一个需求是需要新增数据源或新增业务逻辑，那就不是Key User能覆盖的，应直接转入正式开发评估，而不是让Key User在界面上硬找入口。

2. 实操前的系统准备：角色、授权与前置条件

别以为Key User UI Adaptation是"开箱即用"的。到了实际项目里，我总结下来，真正卡住进度、最容易出问题的环节往往不在操作，而在前置准备。系统版本不对、角色没配齐、服务没激活，按钮都看不到。

2.1 前置条件清单，按顺序排查一遍

我在新项目里通常按下面这个清单做环境检查：

1. Fiori前端服务器（FES）版本需要满足最低要求，或使用嵌入式部署（S/4HANA内嵌网关+Fiori）。
2. 需要启用配置了相应的OData服务，这些服务通常跟UI灵活性管理相关，例如flexibility相关的数据服务，需要确保已激活、可访问。
3. 前端组件的版本支持运行时适配，涉及sap.ui.fl组件，老版本可能部分功能受限制。
4. 应用本身是"可适配的"，大部分标准Fiori元素应用默认支持，但自定义应用需要在应用描述中做适配性声明。
5. Key User的Fiori Launchpad站点需要能看到应用磁贴，并且该站点的角色分配正确。

其中第四点特别容易被忽略。我遇到过不少自定义开发的Fiori应用，顾问交付时没有考虑Key User UI Adaptation，导致Key User进入不了适配模式。对自定义应用，开发阶段就应该把适配开关打开（在manifest.json中增加相应配置），让运维后续能有管理余地。这不是不能后补，但需要修改应用重新打包，代价比一开始就预留要高得多。

2.2 角色与授权：把Key User的钥匙给到对应的人

在系统里，Key User能力是通过角色+授权对象控制的。标准做法是给Key User分配一个包含UI灵活性权限的角色，同时保留访问Fiori Launchpad与目标应用的权限。

从实践角度看，有几个细节要注意。

第一，Key User角色是独立于应用访问角色的。也就是说，你没有某个应用的访问权限，就算有全局Key User授权，也进不了那个应用的适配界面，因为应用根本看不到。反过来，有应用访问权限但没Key User授权，你只会看到本用户的Personalize，不会看到Adapt UI。

第二，授权对象有维护级别之分。有些系统里还区分"Key User"和"管理员"两种级别。管理员级别通常允许跨应用管理，用于IT运维。业务Key User应该使用普通级别，限定在自己需要维护的应用范围内。

提示：权限设计时，我通常会把Key User角色拆成两类：一类只读家，一类是可编辑家。有些业务骨干只需要"使用"适配后的界面，真正被授权做调整的Key User是少数。这样可以大幅降低后续治理风险。

2.3 新老系统差异：界面入口各有不同

Fiori的部署形态会影响Key User看到的入口。

在S/4HANA嵌入式部署里，Fiori Launchpad和后台在同一个系统，适配变更直接写回后台。此时Key User进入应用后在用户菜单通常能看到"Adapt UI"。

在集中式FES部署（Fiori前端服务器单独部署）模式下，前端系统和后端系统分离，Key User UI Adaptation涉及跨系统调用，配置复杂度明显上升。需要确保前端系统能与后端的灵活性服务正常通信，有时候还要额外配置路由和信任关系。

我在一个老版本FES的升级项目里就遇到过：系统版本太旧，前端运行时组件还没支持Key User UICLient层（不含传输），部署形态也会影响。如果代码注释，团队很容易误以为Key User工具不可用。

3. 从打开应用到落库，一次完整适配流程实录

这部分我按一次真实的适配操作来走一遍，包含我从进入模式到发布的完整路径，过程中穿插我实际遇到的反馈和调整。

3.1 进入适配模式：找到正确的入口

以一个标准的S/4HANA Fiori应用为例。登录Fiori Launchpad后，打开某个采购审批应用，点击右上角当前登录用户头像，菜单里会看到"Adapt UI"或"UI Adaptation"入口。

如果没有看到，常见原因有三个：

• 当前用户没有Key User适配授权
• 应用不支持运行时适配（尤其自定义应用需要检查预配置）
• Fiori Launchpad站点配置未加载完整最新角色

建议改完角色后，让用户重新登录，再做一次站点更新。用户全程不需要重启浏览器，但如果访问的Fiori Launchpad版本较旧，可能需要清除浏览器缓存。

3.2 进入适配模式后的界面调整操作

点击"Adapt UI"后，业界面会有一个明显的提示，表示现在是"适应模式"状态。此时你能看到一些编辑手柄、边框高亮、以及可操作的调整元素。我建议在操作时用一种心态：这不是自由画布，而是一个有约束的编辑器，可调整的点通常都有可视化标记。

常用的操作有几种：

字段调整：在表单或表格里，光标悬停在字段上会出现相关操作按钮，可以隐藏、移动、重命名。移动通常是用拖拽方式完成的，但在一些老组件上可能只能用上下移动按钮。

表格列调整：点击列头的“列设置”或“调整列”，可以设置显示/隐藏列，调整顺序。这一类的调整很快就能看到效果。

筛选条件：Smart Filter Bar里可以删除不用筛选器、设置默认值、调整筛选字段范围。

我做一个采购审批应用的示范时，业务部门提出三个需求：隐藏"审批历史"里对业务无意义的内部技术字段；把"供应商"字段从第二屏提到第一屏；默认表格按"申请日期"倒序排列。整套操作完成只花了十几分钟，Key User自己完成配合截图。相比提开发单，时间上是天壤之别。

注意：操作过程中不要同时用多个浏览器标签页打开同一个应用的适配模式，容易造成变更覆盖。我在项目里要求Key User只在一个标签页内操作。

3.3 保存、发布与传输绑定

调整完成后，点击"停止编辑"或"完成"按钮。系统会弹出操作选择，常见是两类：

• 保存：保存为个人适配，只对你自己生效。
• 发布给所有用户：Key User适配真正生效，并出现在所有用户界面上。

这里就要讲回传输的概念了。在开发或测试系统里，发布通常还会让你选择是否分配传输请求。选择"是"，系统会创建一个传输请求，填入标题，你可以把这个请求释放到下一步，例如从测试环境传到预发、生产。

在生产系统上，大多数情况你会希望避免直接发布到客户层。如果生产系统允许直接发布，那意味着变更没有经过测试和记录。我在治理规范里通常会强制要求：生产系统上的Key User适配必须要有传输请求来源，不允许直接在生产上保存。

3.4 发布之后的确认与回看

发布完成后，建议做一个快速回归：

• 换一个普通业务账号登录，打开同一应用，确认调整已生效。
• 检查是否存在布局异常，例如隐藏某个字段后，其他字段是否发生错位。
• 如果涉及排序或筛选，确认数据展示是否正确。

我遇到过一个情况：Key User在适配模式里隐藏了一个字段，但另一个字段也受影响被隐藏了。这就是典型的"字段联动"问题，原因通常是对某些字段设置了关联显隐规则，适配操作并不会自动解除。需要开发参与吗？多数时候不需要，只要Key User回看时能找到关联关系并手动恢复即可。

所以我的习惯是：发布之前用“另存为版本”或先"保存"成个人适配,换账号确认无误后，再发布。虽然发布也支持撤销，但撤销对已发布的全球用户层面来说操作成本更高。

4. 常见问题与排查思路：这些年我踩过的坑

Key User UI Adaptation用起来很顺手，但坑也不少。下面这张表整理了我遇到的高频问题，排在前面的是最常见的原因。

4.1 “保存成功但发布不了”才是真正的高频坑

表面上是单个错误提示，但背后可能有多种原因：没有可用的传输请求、对象被其他传输锁定、请求类型不支持Key User适配等。

我在测试环境见过很多次：Key User在适配完成后点发布，系统提示"请分配一个传输请求"，但下拉列表里什么都没有。原因通常是请求类型不支持，或者后台系统里没做传输目标配置。

解决办法是先确认CTS配置没问题，再手动创建一个空传输请求（请求类型最好选择变更请求或自定义请求，而不是任务请求），发布时手动填入该请求号。这个操作本身不难，但对业务Key User来说已经超纲了。所以我的建议是：把"传输请求是否可用"作为Key User工单的必检项，由实施顾问或Basis在前期做好系统准备。

4.2 “Adapt UI”入口键消失的复现场景

我处理过一个很典型的情况：某个用户一开始能看到Adapt UI入口，到了一段时间后入口消失了，能确定的是角色没变。排查后发现，是他登录的Fiori Launchpad站点没有包含某个基础业务角色，这个角色在升级后从站点配置里被抽掉了。

这个案例给我们的启示是：Key User UI Adaptation授权不是单独授权的，它依赖站点角色组合。如果你发现授权了但入口不可见，建议把重点放在两个地方：站点分配的角色集合、以及FLP站点是否做了角色缓存刷新。

运维上，我在SAP GUI中用策略执行角色刷新，通常就能解决入口缓存不刷新的问题。用户如果还是看不到，就检查Clear Cache参数是否打开。

4.3 回退与撤销：比想象中的稍微复杂

Key User UI Adaptation是支持撤销的，但路径比较隐蔽。

对于刚发布的适配，在管理入口或应用管理区能找到对应变更记录，可以执行"撤销/删除"操作，然后重新发布。对于已经传送到生产环境的变更，撤销需要重新创建一个反向变更并再次走传输流程，因为已发布的适配已经被其他用户加载。

这一点对治理很重要：绝对不要假设"撤销是即时全局的"。如果一项变更是重要调整，撤销也要走变更管理，通知到所有使用者。我在项目里给业务侧的规则是：想清楚了再发布，别把发布当保存来频繁使用。

5. 别让“灵活”变成“失控”：Key User Adaptation的治理之道

讲完了怎么用、怎么排错，接下来才是真正决定这套工具成败的部分：治理。没有治理的Key User UI Adaptation，大概率运行一年后会积累大量无序变更，到时候做界面回归测试，你都不知道哪些是标准、哪些是调整。

5.1 Key User角色怎么分配：宁精勿滥

我强烈反对把所有业务骨干都设置为Key User。每个业务部门建议只设1到2位Key User，而且要经过IT的培训考核后授权。这些人今后不只是自己改，还要成为本部门的需求收口人，负责判断哪些需求能走Key User适配，哪些必须提开发。

再设置一个精确授权的动作：Key User角色只开放给他们需要维护的少数应用即可。不要用一个全局Key User角色覆盖所有应用，这样可以极大缩小变更影响范围。

5.2 传输策略与变更单生命周期

Key User UI Adaptation一旦走传输，它就是一个技术变更，必须遵守项目变更管理流程。

我在项目里定了一套约定：

• 开发、测试系统上Key User可以做调整和发布，但目标只是验证。
• 任何要上生产的适配，必须有明确的变更单号，通过CTS传输链路上线。
• 生产系统上关闭直接发布权限，所有变更从测试系统发起。
• 每周回顾传输队列，定期整理变更单状态。

如果系统上确实存在允许生产系统保存客户层的方式，建议把OData服务权限从生产系统的Key User角色中拿掉，只保留在测试系统里。生产上的适配全部由运维通过回顾传输栈完成。

5.3 变更审计与定期界面“体检”

适配不像程序代码，改动后不一定有很明显的报错，问题通常是慢慢累积的。比如某个字段在三次适配里被反复隐藏、取消隐藏，最终结果可能和最开始的需求完全相反。

我的做法是在项目上线后，每季度做一次"界面适配体检"：导出一份已发布的Key User适配清单，与业务确认每一项是否仍然有效，清掉过期适配。这个清单系统里是可以查到的，通过应用管理相关入口可以列出所有已发布变更及其传输号。

5.4 培训、沟通与容器边界

说到最后的落地，关键还是人。我见过最成功的案例中，IT并没有扮演"审批机器"的角色，而是搭建平台、提供培训，让业务Key User快速建立信心和能力。

培训内容至少包括四块：适配工具的入口和基本操作；哪些能改、哪些必须提开发；发布的权限边界和流程；出错时如何联系IT进行回退。

同时，IT要维护一份简单的需求分流表：如果改动只是字段调整、布局优化，走Key User；如果涉及数据模型、逻辑变更，自己花两周走了开发流程。这套规则没有多高深，但需要一直坚持。

提示：所有让业务自服务的工具，最后都需要一份"谁可以怎么做"的明确边界记录。Key User UI Adaptation尤其如此，因为它权力下放的度很高，但对系统的影响很小，恰恰是最容易失控也最容易补救的一环。

我个人在几个项目里总结出的体会是：Key User UI Adaptation并不是一个锦上添花的功能，它其实是Fiori时代运维模式转变的标志。把它用好了，IT和业务的协作方式都会发生变化——业务第一次有了对自己界面的话语权，IT从琐碎的微调需求中解放出来。关键是，一开始就要把角色边界、传输链路、回退机制和审计节奏设计清楚，让"灵活"和"可控"这两件事可以同时成立。