2007 年 ~ 2025 年，深耕 SAP 技术 18 年

笔者 12 年 SAP UI5 开发岁月中写下的 595 篇 SAP UI5 学习笔记，全部收录到《SAP UI5 百科全书》专栏中去，目录如下。请大家按照自己的学习需要，根据关键字搜索到对应的文章，然后进行学习。

笔者知识星球里有朋友提问，他接到了一个 SAP UI5 开发任务，需要给 Manage Product Master Data 这个 Fiori 应用做一些增强：具体需求是让 Notes 区域的文本编辑，支持 markdown 格式的输入，并能实时看到渲染效果。简而言之，就是给 SAP S/4HANA 的物料主数据编辑应用里，增添一个「在线 markdown 编辑器」的小功能。这个朋友拿到这个需求有点无从下手，于是找我咨询。我们把这个需求进行拆解，有两个功能点需要实现。

凭借的细粒度控制，团队能够在保障生产安全的前提下，把庞大的 SAP UI5 遗留系统拆解成一系列可验证、可回退的微升级步骤。配合蓝绿、金丝雀、影子流量等 DevOps 实践，升级不再是豪赌式的一次性替换，而是可度量、可恢复、可持续演进的日常工程活动。当开关的设计原则、监控体系、清理机制等软治理与 ABAP Switch Framework、SAP Feature Flags Service 等硬支撑结合后，现代化之路将变得清晰且可重复。

是 SAP UI 注解族里的一枚核心术语，用来声明哪些实体属性将在 Fiori Elements 应用的过滤栏中作为“基础筛选条件”出现，以及出现的先后顺序。当后端 CDS View、CAP 服务或 EDMX 本地注解文件里为实体类型添加这一注解后，生成式框架就会据此在 SmartFilterBar（OData V2）或 FilterBar（OData V4）里渲染对应字段；同时它决定了Compact模式下可见的“精选”字段集合，而其余可筛选字段则被折叠到弹窗中。

JSONModel 将 JSON 作为“一等公民”嵌入到 UI5 MVC 架构里，既保留了 ECMAScript 对象的直观，又继承了 UI5 数据绑定的声明式优势。它适合快速原型、离线缓存、本地配置及微交互数据场景。当项目进入海量数据或复杂事务阶段，可自然切换到 ODataModel；但在单页应用拆分微前端、需要零依赖启动时，JSONModel 依然是不可或缺的利器。

在 OData 元数据里，每个EntitySet都引用一个EntityType。当开发者用应用生成器创建 List Report 时，向导会要求选定①，这一实体类型随后被标记为，并在 manifest 的配置段落里作为entitySet的基础记录下来②。动态地产生字段，完全基于该 Entity Type 的属性和引入的 UI、Common 注解③。如果应用包含多标签视图 ()，未明确声明entitySet的标签会默认继承，间接继承其 Entity Type④。在 Navigation 规则里，

凭借对各子属性与分层覆写逻辑的掌握，你可以零代码地为业务用户定制适配大屏、移动、深度分析或批量处理的表格体验；同时通过参数化控制把性能、密度与可用性调到最佳。下一次当需求只是在 List Report 上加一个「多选 + 全选」或「压缩行高」时，别急着写控件扩展——修改 manifest.json 的往往就够了。

Device Model 是 SAP UI5 在运行期自动感知设备特征并驱动界面自适应的关键机制。它把收集的操作系统、浏览器、输入方式、屏幕尺寸等信息，包装成一个只读的 JSONModel，并通过一名为device的全局模型暴露给视图与控制器。开发者由此可以在数据绑定表达式、布局规则或控制器逻辑里精准区分 phone、tablet、desktop，乃至 touch、mouse、orientation 等细粒度属性，实现真正的 Responsive 与 Adaptive Design。

EndUserText.label: `销售订单按年份汇总`key vbeln,erdat,auart,netwr进入 List Report 时，若用户未手动输入会计年度，模板会给塞入当前年份，并透过参与首轮查询，无需控制器编码即可实现智能默认。虽不显山不露水，却是 Fiori Elements 模板能“自我驱动”的核心秘密。充分理解并善用它，能让开发者在不写或少写控制器代码的前提下完成复杂的动态页面要求，大幅提升 Fiori 项目的交付效率与可维护性。

词汇文件Common.xml此处表明DraftRoot只能贴在EntitySet层面，意味着整棵草稿树从该集合的根实体开始(GitHubDraftRoot通过对根实体集加注统一协议，协调 CDS、OData 与 UI 运行时，赋能 Fiori Elements 在复杂长事务场景下提供无感草稿体验。无论在 ABAP CDS 还是 CAP 服务，只要遵循词汇表约定，即可享受自动生成的草稿表、锁机制与激活流程。在实施中务必关注字段一致性、动作映射与元数据完整性，以充分发挥 SAP 平台提供的草稿框架价值。

【代码】SAP Fiori Elements 框架运行时如何判断一个 OData entity 是否开启了 draft handling？

下列最小项目演示如何在 Fiori Elements FreeStyle 页面里，加入自定义日期范围与供应商多选下拉，同时对字段设置默认值与顺序。说明：示例中的所有双引号已替换为反引号以满足排版要求；若需直接运行，请替换回标准双引号。通过聚合，可把任意 XML Fragment 嵌入 SmartFilterBar。

在 Fiori Web 应用里，控件承担着“让数据主动靠近用户”的入口角色。它不仅提供即输即得的liveChange交互，也支持经典的search触发模式；它可以与FilterBarSuggest等机制无缝协作，还内置无障碍 ARIA 属性，确保键盘及屏幕阅读器可用。下面是。

如果应用需要在ObjectPage内展示业务标签，可单独创建Tokenizer，绑定到 JSONModel 的/tags数组。通过限制最大字符数或防止重复值，从而获得比List更紧凑的视觉占用。通过极简容器思路，把多值输入这一复杂交互拆解为若干高度一致的小 Token，再辅以自动折行、键盘导航与统一事件流，既提升了视觉层次，也降低了业务逻辑处理成本。理解其设计初衷、掌握各类 API 细节，并在性能与可用性之间取得平衡，将帮助开发者在 Fiori 与自定义 UI5 项目中构建更友好的多值体验。

是 SAP UI5 提供的极其轻量的隐藏文本控件；它不在视觉层面呈现，却在辅助技术层面扮演关键角色。通过在 DOM 中插入仅对屏幕阅读器可见的span元素，该控件为各种视觉组件提供可朗读的语义补充，从而让 Fiori 应用在遵循 WCAG、ARIA 等标准的同时保持 UI 简洁(SAPUI5 SDKSAPUI5 SDK控件自 1.27 版本引入，已被 Fiori 元素框架、大量标准控件以及第三方扩展广泛调用，用以完成关联、动态状态提示、实时无障碍消息播报等任务(

在任何需要大规模筛选的 SAP Fiori 元应用里，多值选择是业务人员最常点击的入口之一。`sap.ui.comp.smartfilterbar.SFBMultiComboBox` 正是 SmartFilterBar 自动生成的多选控件，它在 OData 元数据与用户交互之间搭起桥梁，用与 `sap.m.MultiComboBox` 同级别的交互，提供了更一致的过滤体验。本篇从框架视角揭开它的继承关系、渲染逻辑与 OData 后端交互细节，并通过一个可运行的代码示例，展示如何在真实项目中善用这把“多选瑞士

的价值在于朴素却稳定：当业务只需线性展示，或需要在 Fiori Elements 扩展中快速拼装小段 UI 时，它提供零负担的首选方案。若日后对齐与弹性需求升级，再平滑迁移至VBox即可延续设计一致性。把握这条垂直脊梁，能让你的 Fiori 页面骨架更清晰、渲染更高效，也让维护者在阅读代码时一眼了然。参考资料SAPUI5 SDKVBoxvs讨论 (StackOverflow — Alignment 建议 (SAP Community — 旧版已弃用 (

把流式布局与栅格对齐两种看似矛盾的需求优雅结合，在 Fiori Elements 的过滤与搜索场景里扮演关键角色。理解其列槽算法、响应式行为以及与 FilterBar 的耦合方式，不仅能帮助你快速构建出整洁的搜索面板，也能在复杂查询界面中保持一贯的 Fiori 体验。

SmartFilterBar 把复杂的检索界面“模板化”，让开发者聚焦业务逻辑与后端数据质量，而非 UI 小细节。通过精准运用 CDS 注解与 OData 元数据，它能在几毫秒内拼装出专业级筛选体验；结合事件钩子与控制配置，又足以满足极端个性化需求。拥抱 SmartFilterBar，意味着在 Fiori 生态中以最少代码赢得最快价值交付——这正是现代企业应用开发追求的极致效率。

UI 层扩展主要关注在不修改标准生成界面的基础上，自定义用户界面元素和交互逻辑。典型需求包括：在现有 Fiori Elements 界面上添加新的字段（如表格列或表单项）、增加自定义按钮并绑定操作、以及通过控制器扩展加入事件处理等。无论在 RAP 还是传统 BOPF 架构下，前端 UI 扩展通常采用 SAPUI5 提供的**扩展点（Extension Points）和控制器扩展（Controller Extension）**机制来安全地插入自定义代码。下面分别说明两种后端架构下 UI 扩展的实现方式。

在 SAP UI5 的官方扩展模型里，充当了框架与开发者自定义内容之间的插槽：标准视图（或由 Fiori Elements 在运行时生成的视图）通过在 XML 或 JS 代码中显式声明，把未来可插入的位置牢牢锚定；而业务团队则可通过 fragment、view 或运行时 API将全新的控件树注入到这一锚点，从而实现零修改（mod‑free）的升级安全扩展。其设计初衷是用最小侵入式手段，把交付版本与后续客制化解耦，既保护了 SAP 提供的升级路径，又给项目留出了充足的差异化空间(

隶属于命名空间，自 1.27.1 版本引入，专门服务于的处理。官方文档给出的描述是，强调它只在 XML 视图（含片段）层面工作，而不会触碰运行期生成的控件树。在执行顺序上，模板预处理位于视图加载之后、控件实例化之前。其输入是带有template命名空间指令的 XML，输出则是纯净且已消除元数据依赖的 XML。把数据模型元数据与视图结构绑定在一起，让 SAP UI5 能在浏览器完成元数据到 UI 的即时编译。

SAP 官方 API 文档指出，sap.uxap.ObjectPageHeaderActionButton 是一个Button子类，用于放置在 sap.uxap.ObjectPageHeader 控件的actions聚合中。) 该按钮继承自 sap.m.Button，因此保留了 icon、text、type 等通用特性，并额外针对 Object Page Header 场景做了视觉和可访问性上的细节优化。

自 UI5 1.34 版本正式引入，与早期的模式相比，它更关注一维层级而非对象元信息；与相比，它只依赖sap.m生态，重量更轻，在自由式页面也能单独使用。API 文档指出：控件内部维护两类聚合——links与。如果父容器宽度不足，前段链接会折叠到下拉列表中，最近的三个层级永远可见，从而兼顾信息量与布局美观。不只是视觉装饰，更是承载用户心智模型的导航枢纽。

OverflowToolbar 控件把 Fiori 哲学中“自适应”“可访问”“一致性”的理念落到代码层面, 提供了比传统 Toolbar 更优雅的响应式解决方案。掌握prioritygroup等参数后, 开发者可以在各种复杂页面中精准控制按钮展示, 同时消除尺寸变化带来的布局抖动。结合本文的算法拆解与性能调优建议, 相信读者能在今后的 UI5 项目中游刃有余地运用 OverflowToolbar, 塑造兼具美观与可用性的企业级界面。

笔者之前的教程文章，对于 SAP UI5 应用描述符文件最近笔者在持续更新 Fiori Elements 的开发教程，有不少学习者反映，Fiori Elements 应用的扩展场景，往往需要在里添加扩展配置项，比如和这些配置项比较繁琐，容易出错。一旦配置项出错，manifest.json 无法正确被解析，此时需要开发人员去调试 SAP UI5 框架解析 manifest.json 时，到底哪里出了问题。对于这种情况我们需要知道从哪里设置断点进行分析。本文就来聊聊这个话题。

本文把它分拆为七个 token，逐一解释它们的来源、含义以及在开发、自动化测试、性能诊断中的价值，并辅以一段可独立运行的最小示例，帮助读者在真实项目中快速定位控件，甚至自定义扩展。是 UI5 在 shell 启动阶段为每个已加载应用分配的前缀，用来与库、复用组件生成的 ID 区分开来，保证全局唯一。使用，后者是 UI5 官方推荐的 View 与 Component 分隔符，可防止不同 View ID 在压缩后发生冲突 (或直接省略，这也解释了为何相同视图在不同导航路径下 ID 不一致的现象。

启动 Launchpad 磁贴首次打开应用从应用 A 导航到应用 BFloorplan 内容根据路由参数重新检索大量实体指南强调：如果操作只遮盖局部控件，仍然应使用；若需要展示明确进度条，则应改用。

启动 Launchpad 磁贴首次打开应用从应用 A 导航到应用 BFloorplan 内容根据路由参数重新检索大量实体指南强调：如果操作只遮盖局部控件，仍然应使用 Busy Indicator；若需要展示明确进度条，则应改用 Progress Indicator。​。

始终使用或箭头函数注册来自控制器的回调，确保this指向控制器实例。在onInit一次性完成绑定，避免在回调里再用.bind产生额外分配。不要把未绑定的方法直接交给，否则在导航后this将错误。若担心内存，可通过类字段箭头函数或手写闭包替代.bind，但需权衡可读性与一致性。Fiori Elements 官方指导：“为确保扩展代码与框架正确集成，只通过并使用已绑定回调” (

controller extension 的定位：它是 Fiori Elements 提供的官方注入点，用于在保持元数据驱动 UI 的一致体验的同时，让开发者写少量 JavaScript 代码弥补特殊业务需求 (manifest 片段的三要素键标识需要被扩展的标准视图。字段注册你的扩展控制器类。内嵌对象将扩展与具体 EntitySet 绑定，确保运行时能拿到正确的 OData 上下文。落地步骤：在下创建，继承并重写生命周期或 Routing 钩子 (随后为 Manifest 补全配置即可。

Controller Extension 就像一把精准手术刀：在 Fiori Elements 强大但相对封闭的生成式世界里，小心但灵活地开出一个窗口，让个性化 JavaScript 得以与标准模板同频协作。把握声明优先、API 驱动与生命周期分层三条原则，你就能在保持可升级性的同时，让应用焕发源于业务的独特光彩。

sap.fe.core.ExtensionAPI 把过去分散在 UI5 控件、模型与路由器里的能力整合到同一门面对象中，让 Fiori Elements 应用扩展具备“低代码、高安全、强兼容”的三大优势。掌握该 API，意味着在保持框架升级可持续的同时，也拥有足够弹性去实现企业独特的业务流程。期待你在下一个项目里，用它打造更简洁、更可靠的 SAP Fiori 体验。

在移动端列表和表格场景中，为了优化网络请求和渲染性能，UI5 引入了“按需加载”机制，使控件能够按批次向后端请求数据并逐步渲染。控件基于此机制提供了多项成长（growing）相关属性，其中定义了每次批量请求的条目数 (在 UI5 1.16 及更早版本，曾独立存在控件，后于 1.16.0 版本将成长功能直接整合到ListBase中，弃用了原有扩展控件 (growing：启用成长特性：每次向模型请求的数据条数：滚动触底自动加载：触发加载按钮文本 (

Application Modeler 让 Fiori Elements 的元数据世界真正“长出面孔”。Page Map 展现骨架，Page Editor 雕琢细节，两者合力，把过去在与注解文件之间来回切换的痛点转化为图形化拖拽。嵌入式预览让开发周期成倍压缩，社区插件生态也持续丰富。在未来，随着 TypeScript 与 UI5 自定义控件的深度集成，Application Modeler 将继续降低企业级 SAP UI 的学习门槛，助力更多团队快速上线高质量应用。

backend-proxy-middleware 是 SAP 提供的一个 Custom UI5 Server Middleware，用于在 UI5 开发服务器中代理后端请求 (能够在本地环境或 SAP Business Application Studio 中运行，并自动使用 Fiori Tools 中维护的后端凭据 (通过在ui5 serve或fiori run命令启动的服务器上挂载中间件，拦截并转发特定路径的 HTTP 请求 (提供灵活的配置选项，可以通过url或。

该中间件基于 http-proxy-middleware 库实现，分为 ui5 资源代理和 backend 代理两大模式，并可与 fiori run 或 ui5 serve 命令无缝集成，通过配置 ui5.path、ui5.url 以及 backend.path、backend.url 等参数，实现与目标系统的灵活对接和安全配置 (就后端系统代理而言，fiori-tools-proxy 内置 @sap-ux/backend-proxy-middleware，可将以指定前缀（如。

在企业级前端迭代越来越频繁的今天，开发者希望既能快速交付 MVP，又能在后续迭代里无痛插拔功能。ThoughtWorks 技术雷达长期倡导的思想，鼓励在核心代码里为未来变化预埋“可变点”。SAP UI5 社区多年来实践出两条主干：在 XML 视图里放置，在控制器里暴露。这两种机制让应用像乐高一样可插可拔，同时保持与 SAP 官方升级兼容。

Fiori CLI 基于 UI5 Tooling 构建，执行时会触发fiori run命令，进而调用ui5 serve启动本地服务器，同时加载多个自定义中间件（custom middlewares），例如用于本地预览和后端请求代理 (整个预览流程包含对代码变更的自动刷新、SAPUI5 版本切换以及静态资源服务等功能 (

在 SAP Fiori Tools 扩展集中，SAP 推出了多种中间件以简化开发流程，其中即为专注于本地预览的组件。它能够根据配置动态生成 Fiori 启动页，不再需要在项目中维护过时的测试文件，确保预览环境与实际生产环境高度一致。此外，SAP Fiori Tools 还包括诸如appreloadproxyneo-app等中间件，用于实现自动刷新、资源代理和旧版应用支持等功能 (