企业官网建设流程全解析

做了这么多年SAP Fiori项目，我几乎每次去给业务部门演示“新系统”的时候，都会被人问到同一个问题：能不能把A系统的待办、B系统的报表、C系统的预警集中到一个页面上？最好打开这个页面，一眼就能看到今天什么事最紧急。早几年，面对这种需求我只能回答“可以做，但要开发定制页面”，开发周期两三周起步。直到我在某个客户项目里真正把Overview Page配合UI Adaptation用起来之后，这个问题的答案变成了“可以，而且你后天就能看到样子”。

这篇文章要聊的就是这件事：SAP Fiori Overview Page到底是什么，以及更关键的——**UI Adaptation（界面适配）**如何让我们在不写一行Java/JavaScript、不改标准应用代码的前提下，把复杂的业务信息“装进一页”。我会把我实际做过的“模拟项目X”里的步骤、踩过的坑、排查问题的思路完整写出来。适合正在做Fiori实施项目的顾问、负责业务模板配置的Key User，以及想搞清楚OVP和Adaptation到底能干什么的入门开发者。

1. Overview Page：给复杂业务一张“可扫视”的总览页

1.1 OVP的定位：不是报表工具，而是聚合入口

先纠正一个常见的误解：Overview Page不是报表工具，也不是仪表盘（Dashboard）。它更像是业务人员每天上班时打开的那个“工作台首页”。SAP官方给OVP的定位是“基于卡片的聚合式页面”，它把一个业务领域中最高频、最需要即时处理的信息，通过卡片的形式铺在一个页面上，让用户不用到处找入口。

我常喜欢拿“客厅”来打比方：传统Fiori应用就像一个个独立房间，你要看订单去订单室，看库存去库存室，看审批去审批室，来回跑很累。OVP则是把这些房间里最核心的“家具”——电视、沙发、茶几——拖到一个开放式客厅里，摆成你顺手的样子。你不需要进每个房间，站在门口就能看到全貌，需要深入处理时点一下卡片上的链接再进去。

从技术结构上讲，OVP页面本身是一个SAP Fiori标准页面类型，页面上承载内容的不是普通表格或表单，而是卡片（Card）。这些卡片各自绑定一个OData服务，独立加载、独立刷新。也就是说，某个卡片的数据源出问题了，不会导致整个页面挂掉，其他卡片该怎么展示还怎么展示。这个“模块隔离”特性在实际生产环境里太重要了，我在第4部分会展开讲。

1.2 卡片是OVP的“乐高块”：类型与选型

OVP能聚合这么多内容，全靠卡片这个“乐高块”设计。SAP在标准库里提供了几大类模板卡片，我们做UI Adaptation的时候，其实就是从这些模板里挑、配、排。常见的有：

每个卡片在底层的本质是一个XML片段，我在项目里从OVP页面源码里看到的典型结构大致长这样：

<overview:OverviewPage id="MyOverviewPage" ...> <overview:cards> <overview:Card id="SalesOrderCard" title="销售订单概览" cardClass="sap.suite.ui.commons.cards.ListCard"> <overview:attributes> <!-- 绑定OData实体集，配置显示字段 --> </overview:attributes> </overview:Card> </overview:cards> </overview:OverviewPage>

这个XML结构解释了为什么一张卡片能灵活适应不同业务：它本质上是“视图容器+OData数据绑定+模板控件”的组合。我们在UI Adaptation里做的所有可视化拖拽调整，最终都是改这类XML配置中的属性值。理解这一点有一个好处：当图形化界面某些属性改不动时，你知道是底层XML约束了你，而不是操作方式不对。

选卡片类型时有条经验：先问业务“你在这个页面上最频繁的动作是什么”。如果90%的动作是“判断今天有没有异常”，数值卡片加分析卡片就够了；如果动作是“进来处理单子”，列表卡片效率最高；如果只是需要一个导航门户，链接卡片轻巧不占空间。

2. UI Adaptation为什么能不碰代码改页面

2.1 灵活性服务与标准应用的边界

在项目初期，客户顾问们听到“不写代码就能改标准Fiori页面”时，第一反应通常是不信。确实，传统增强方式是做扩展项目，把标准应用复制出来改代码，然后每次升级都要处理冲突。UI Adaptation能真正做到不改代码，依靠的是SAP UI5底层的一个机制——灵活性服务（Flexibility Services）。

可以用“贴膜”来理解：标准应用是原装手机屏幕，UI Adaptation是在屏幕上贴一层保护膜，这层膜控制哪些内容可见、放在什么位置、字段怎么排列。它没有改动屏幕本身，只是在运行期叠加了“调整指令”。当标准应用升级时，因为底层代码没动，升级不会覆盖你贴上去的“膜”。

这层“膜”在技术实现上，是一份份存放在后台的JSON格式配置变更记录。每次你在UI Adaptation Editor里拖动一个卡片、隐藏一个字段，系统不是立刻修改应用代码，而是生成一条“变更指令”存储起来。应用加载时，这些指令会被动态应用，从而改变页面外观和交互。这就是为什么它叫“Adaptation”——自适应适配，而非“Modification”——修改代码。

2.2 Adaptation Project与UI Adaptation Editor的能力边界

实际操作中，这些“变更指令”不是零散存在的，而是按项目为单位组织起来的，这个单位就叫Adaptation Project（适配项目）。一个Adaptation Project对应一个标准应用/OVP页面及其一组变更集。我记得第一次创建项目时花了一会儿才反应过来这个抽象关系：一个页面建一个项目，项目只服务于该页面，不跨页面生效。

进入Adaptation Project后，打开的是UI Adaptation Editor。这个编辑器界面分三块：左侧大纲，列出页面所有元素结构；中间画布，所见即所得地预览页面；右侧属性栏，调整当前选中元素的属性。我们团队里一个从来没写过代码的顾问，在半小时内就学会了拖拽卡片和调整字段顺序，这个学习成本确实很低。

但UI Adaptation Editor不是万能的。我整理过一张“能做什么/不能做什么”的对照表，实战中很有用：

这张表说明了一个趋势：UI Adaptation解决的是“布局和展示层”问题，解决不了“业务逻辑和数据加工”问题。如果业务需要的是完全没见过的分析维度，那还是需要通过Fiori Elements开发或自定义扩展来补充，但这部分内容不在本文范围内。

2.3 为什么说这是企业级低代码的“正确打开方式”

软件行业现在都在谈低代码，SAP这套UI Adaptation的思路给了我很大启发。它选的切入点是“不让你从零造东西，而是提供足够的规则约束，让你在约束下高效调整”。

对比一下传统的Fiori页面定制：你要扩展一个标准应用，要么做Extensibility，复制标准应用然后在扩展项目里改视图；要么Request Change，把需求发给开发团队排队处理。这两种方式都存在“开发-测试-发布”的完整周期，最顺利也要一到两周。UI Adaptation则把这个周期压缩到“当天改完当天发布”，因为改动不涉及代码编译、不涉及传输程序代码，后台只是更新配置数据。

我在某客户现场演示时，业务主管当场把一张“未来7天交货预警”卡片从页面底部拖到顶部，标题改成“今日必看”，保存后刷新页面就生效了。他当时说了句“这不就是企业版的PowerPoint排版吗”。虽然这个类比不完全准确，但确实点中了UI Adaptation的核心理念——把“改配置”的权力交还给最懂业务的人。这也是它被称为“Key User Adaptation”的原因。

3. 从零完成一次OVP页面适配：完整实操记录

3.1 前置准备与权限检查

在实际动手之前，有几个前置条件必须满足，缺一个后面都会卡壳。我先放一个自检清单，照着检查即可：

• 系统版本支持：后端系统启用了Fiori标准功能，并有可以用于测试的Fiori Launchpad。
• 目标OVP页面已存在：你需要先有一个部署好的Overview Page应用，且能正常在Launchpad中打开。
• 用户权限：进行UI Adaptation的人需要有“SAP_UI_FLEX_KEY_USER”关键用户角色；如果还要把调整发布给其他人，需要在管理后台做相应设置。
• 传输功能：准备一个可用于创建CTS传输请求的开发/测试环境，确保有创建请求的权限。

我自己踩过的第一个坑就是权限不足：系统登录用户虽然有业务流程角色，但没有关键用户角色，结果在Launchpad用户菜单里根本找不到“Adapt UI”选项。后来联系管理员，在当前客户端为用户角色集里添加了SAP_UI_FLEX_KEY_USER，重新登录后才出现入口。所以如果你也在找“Adapt UI”按钮但找不到，先别在系统设置里死磕，大概率是权限问题。

3.2 创建Adaptation Project并进入编辑器

前置条件就绪后，我们开始实战。我在“模拟项目X”里做的场景是把销售订单、待审批、交货趋势三个标准应用合并到一个OVP页面上。

第一步，在Fiori Launchpad中打开目标的OVP页面。然后从右上角的用户头像下拉菜单里，选择“Adapt UI”选项。系统弹出对话框，询问是新建适配项目还是打开已有项目。这里有两个层级要理解清楚：

• “我的视图”：只影响当前登录用户自己的页面，属于个人偏好。
• “适配项目”：会影响整个页面的内容结构，适合作为团队共享配置。

我实际操作中通常直接选择创建新的Adaptation Project。确认后，系统会要求输入项目名称和描述，并自动生成一个项目ID。随后界面自动切换到UI Adaptation Editor。编辑器第一次加载稍慢，因为需要获取页面结构元数据和卡片注册信息，大约等待五到十秒是正常的。

这时你会看到页面以可编辑状态呈现，每张卡片周围出现边框和工具条。左侧大纲里列出页面的层级结构，顶部是OverviewPage节点，下面挂着一堆卡片子节点。我习惯在大纲视图里点击卡片在画布中定位，双方便于对照，尤其在卡片很多的时代很有用。

3.3 卡片布局、字段与过滤条件的调整

进入编辑器后的核心操作就是编排卡片。我们处理“模拟项目X”需求时，做了下面四类典型调整。

调整卡片大小和位置。点击任意卡片后，右侧属性栏会显示General属性，其中Size选项控制卡片跨列宽度。OVP一般按两栏/三栏栅格布局，可选Small、Medium、Large（部分卡片还支持ExtraLarge）。我们的待办列表需要更多空间展示明细，选了Large，数值卡片只放一个KPI数字，用Small就够。拖拽排序时注意卡片之间的间距，OVP会自动补偿底部空隙，但过于频繁拖拽会导致视觉上瞬时错位，保存后刷新即恢复。

修改卡片标题和副标题。业务部门不认“SalesOrderCard”这个技术名，我们在Title属性里改成“销售订单今日待办”，顺便在Subtitle里增加了“按优先级排列”的提示。这一步直观却容易被忽略——标题文字直接决定了用户对这个卡片用途的第一反应，值得认真写而不是用系统默认值。

调整字段可见性和顺序。选中卡片里的一个字段后，属性栏里会列出该卡片绑定的所有字段，勾选状态控制显示与否。我们把订单卡片里不常用的“内部备注”字段隐藏，把“请求交期”提到“优先级”后面。这个调整的颗粒度比传统扩展要细，效果立竿见影。需要提醒的是，有些卡片内置模板字段是被锁定的，你勾选选项后会收到提示“此字段在此模板中固定显示”，那就只能接受，不是操作错误。

配置过滤栏。OVP页面上方通常自带筛选条，我们给订单卡片添加了“状态=待审批”的默认过滤条件，这样一打开页面，卡片自动只显示出待办数据。过滤条件是作用在卡片的数据源级别的，等于每次加载卡片时OData请求都会带上这个筛选参数，所以能明显减少无用数据加载量，页面响应速度也更快。

3.4 保存、激活与传输发布

调整完成后，点击编辑器右上角的“保存”不会直接生效，还需要走“发布”动作。在UI Adaptation Editor里，点击“发布”时会弹出对话框，提示输入短描述，然后系统会在后台创建或绑定一个CTS传输请求。这一步对项目交付至关重要。

如果开发环境与生产环境分离，适配项目一旦发布到该系统的传输列表，后续由顾问在STMS中执行传输到下游测试/生产客户端。如果只在当前客户端生效而不做传输，那生产环境永远看不到调整。我见过不止一次“我明明改了怎么生产环境没变”的求助，最后发现都是漏了传输这一步。

发布后，让业务用户刷新Launchpad页面（必要时清除浏览器缓存），OVP页面就会按新的卡片配置展示。我们当时在测试系统上发布后，业务同事在虚拟机里第一次刷新就看到新布局，但第二次刷新后发现又回到旧版——排查下来是因为浏览器缓存了Fiori的metadata。强刷一次（Ctrl+F5）解决。后面我们每次发布完，都顺手提醒用户用无痕窗口或强刷验证，省了不少电话。

4. 实战中踩过的坑与排查清单

4.1 卡片不显示或内容空白

这个现象在OVP适配项目里出现频率不低。我的排查路径通常按下面顺序来：

1. 检查卡片是否被误隐藏。有可能在编辑时手滑取消了卡片的“可见”属性。进入UI Adaptation Editor，看大纲里卡片前面是否有“隐藏”图标，取消即可。
2. 检查OData服务的注解或实体集是否存在。OVP卡片的数据源配置很依赖后端元数据。如果后端某张表授权没有放开，卡片会正常出现但内容空白。这时去后端事务码SEGW里查看服务元数据，确认实体集和字段在目标用户角色下是可读的。
3. 看浏览器开发者工具Network面板。Fiori应用是基于UI5的，F12可以看到卡片向OData服务发起的请求。如果请求URL返回错误码，按错误码顺藤摸瓜。有一次我们遇到“404 Not Found”，是因为卡片绑定了一个被停用的服务版本，切换到激活版本后问题消失。

4.2 无法调整字段或卡片大小

在UI Adaptation Editor里，有些卡片根本没有Size下拉框，或字段勾选框置灰。这往往不是编辑器问题，而是卡片模板本身的约束。以“分析卡片”为例，它的图表类型决定了宽高比例，系统只允许在特定尺寸档位之间切换。以“数值卡片”为例，某些模板只支持Single Value，不支持双KPI并行，找不到对应属性改不进去是正常的。

遇到这种“改不动”的情况，我会先查SAP帮助文档里OVP卡片模板的属性列表，确认是产品限制而非问题，不要浪费时间在编辑器里找隐藏开关。如果确实需要更灵活的展示，方向有两个：选另一种模板更适配的卡片类型，或者让开发做一个自定义卡片并在后端注册。后者属于开发范围，权衡成本后再决策。

4.3 发布后其他测试环境看不到变化

上一部分提到的传输遗漏，是出现频次最高的坑。UI Adaptation的配置绑定的传输请求不是自动跟随系统流程走的，在“发布”对话框里如果你选择了不创建传输请求，那变更就停留在当前逻辑客户端。我们后来制定了一个团队约定：所有Adaptation Project命名时加入“TRANSPORT”标记，发布时强制检查请求号是否填写，并在每周发布窗口前由专人集中处理传输。从此以后再没出过“环境不一致”的幺蛾子。

还有一种特殊情况：如果系统配置了多个Fiori Launchpad或同一应用出现在不同Catalog/Group里，适配项目只针对单个应用ID。同一个OVP页面如果被封装成两个不同ID的应用，你改的是其中一个，另一个不会变。排查方法是去FLP内容管理器里确认实际使用的应用ID，而不是凭肉眼判断“长得一样”。

4.4 维护与回滚的几个经验

UI Adaptation项目里的变更记录是可以回退的。在UI Adaptation Editor中，有一个“Show Change History”功能，可以查看此前每一步调整的历史版本。需要撤销时，可以在对应记录上点击“Revert”恢复到某个历史状态，也可以整体删除变更项目回到标准页面的原始样式。

这里我建议团队养成两个习惯：一是每完成一个独立需求，就发布一个独立阶段，不要连续改两个需求再一起发布，否则回滚时就分不清边界；二是在传输发布前，在测试系统完整走一遍关键卡片点击流程再放行，配置类变更虽然风险低，但它影响的是全用户页面，出问题的影响面比个人偏好要大得多。另外，OVP页面如果卡片数量很多，注意控制在一个页面不要塞超过8到10张，否则拖拽经常错位，页面也因为并发请求过多而卡顿，我在第5部分会展开说为什么“少即是多”。

5. 从一次适配项目反推OVP的设计思路

5.1 卡片选型的业务逻辑

UI Adaptation培养了业务人员用“卡片思维”去拆解自己的日常作业：打开页面第一眼看什么、点进去要做什么、顺手要跳到哪里。当你用这套逻辑去反推，会发现很多“假需求”其实可以被删掉。

我遇到过业务方要求把十二个指标都放上OVP页面的情况，理由是“我要每天监控所有数据”。当我追问“哪些变化了你必须今天处理”，十二个指标被砍到四个，最终真正高频查看的只剩两个。卡片选型同理：如果字段里90%是系统状态文本，用列表卡片更直接；如果关键是看数值趋势，那就没必要放列表，给一个分析卡片就够了。这个前置沟通环节能极大降低后面配置返工率。

5.2 交给用户的“自助”边界

UI Adaptation能力的上线会让业务用户产生一种感觉：所有页面都能按自己意愿改。实际上不是。它对于“允许哪些用户调整自己的私有视图”“允许哪些关键用户调整公共视图”这些权限问题，是有严格边界的。

我在项目中设置了两条线：普通业务用户默认只有“个人视图”调整权，他们改的只影响自己的页面，不影响团队；被赋予关键用户角色的人员才能调整并发布公共适配项目。这样既满足了个人效率需求，又不至于出现某个用户把公共OVP页面改成只有他自己看得懂的布局，导致其他用户投诉。管理角度上，这也给后台运维留了充分掌控力。

5.3 后续扩展：从个人视图到团队模板

刚接触OVP适配的人，容易把这套能力当成一次性配置任务来用。但做熟练之后，我们会发现它其实带出了“页面模板化”的良性循环：针对销售团队做一套销售工作台布局，针对供应链团队做一套供应监控布局，每个团队打开OVP页面的时候看到的是属于自己的业务切片。多套Adaptation Project共存于同一个标准页面时互不干扰，这个能力对企业内部后续推广Fiori非常有用。

我们之后进一步体会到的另一个扩展方向，是把卡片配置与Fiori的“页面主页”概念结合，再配合SAP Fiori Launchpad的Group/Catalog规则，让不同岗位的人默认看到不同布局。这套组合逻辑完全围绕配置展开，实施周期短，业务获得感强，是目前我在项目中看到ROI最高的Fiori落地方式之一。

回头来看，OVP与UI Adaptation的价值不在于它多“智能”，而在于它把业务人员从“等待开发排期”变成了“轻量自助调整”。真正适合它的人，是那些每天都与系统打交道、却对代码束手无策的业务骨干。把复杂业务浓缩到一页，靠的正是这种能力下沉。

最后分享一个后续扩展思路，我们内部已经在慢慢推广的：把高消耗报表类页面从标准导航里拆出来，放到OVP页面上的链接卡片做为二级入口。这样既保留了报表系统原有的功能深度，又让日常高频操作停留在总览页面上，系统负载和用户体验都得到了优化。你也可以在自己的项目里试试，效果往往比预想中好。