作为一名长期从事SAP Fiori应用开发的工程师,我深刻理解企业在UI改造过程中面临的困境:业务部门希望获得更多自主调整界面的能力,而IT部门则担心这些改动会影响标准应用的升级维护。SAPUI5 flexibility提供的分层模型(Layering Concept)正是解决这一矛盾的利器。
这个模型的核心思想是将所有UI变更视为语义化的增量信息(semantic delta),并通过分层机制进行管理。就像建筑师在设计大楼时会考虑不同层级的结构需求一样,我们在进行Fiori应用改造时也需要建立清晰的层次思维。
在传统开发模式中,UI改造往往意味着直接修改源代码:调整XML视图、改写控制器逻辑、变更manifest.json配置。这种方式存在几个明显痛点:
提示:我曾参与的一个采购系统升级项目就遇到过这种情况 - 业务用户在测试环境做的个性化设置,在升级到新版本后全部丢失,导致用户强烈抵触升级。
SAPUI5 flexibility将UI变更划分为五个逻辑层,每层都有明确的职责和适用场景:
| 层级 | 名称 | 适用场景 | 典型变更内容 | 持久化位置 |
|---|---|---|---|---|
| USER | 用户层 | 个人偏好设置 | 列宽调整、个性化筛选 | 浏览器本地存储 |
| PUBLIC | 公共层 | 团队共享视图 | 共享查询条件、常用视图 | 后端系统数据库 |
| CUSTOMER | 客户层 | 组织级适配 | 字段标签本地化、必填规则 | 传输系统管理的存储库 |
| CUSTOMER_BASE | 客户基础层 | 开发者扩展 | 新增字段、自定义逻辑 | 开发系统版本库 |
| VENDOR | 供应商层 | SAP标准交付 | 标准Fiori应用 | SAP标准包 |
这种分层设计的关键优势在于:
要使分层变更在应用升级后仍然有效,每个UI元素都需要一个稳定的标识符。这就是Stable ID的作用:
xml复制<!-- 在XML视图中声明stableId -->
<Input
stableId="PurchaseOrderItemNote"
value="{/Note}"
placeholder="输入采购备注"/>
Stable ID的命名规范建议:
所有UI变更都以JSON格式存储,以下是一个典型的变更文件:
json复制{
"changes": [{
"selector": {
"id": "PurchaseOrderItemNote",
"type": "sap.m.Input"
},
"content": {
"visible": false
},
"layer": "CUSTOMER",
"texts": {
"value": "采购备注(必填)"
}
}],
"support": {
"generator": "SAPUI5 Flexibility",
"version": "1.78"
}
}
关键字段说明:
selector:通过Stable ID定位要修改的元素content:具体的修改内容layer:指定变更所属层级texts:文本修改专用字段(支持多语言)运行时,系统会按照以下顺序应用变更:
这种叠加机制类似于CSS样式的层叠规则,高层级变更会覆盖低层级设置。
某制造企业需要对其采购申请Fiori应用进行以下改造:
CUSTOMER_BASE层(开发者扩展):
json复制{
"changes": [{
"selector": {
"id": "CostCenterField",
"type": "sap.m.Input"
},
"content": {
"required": true
},
"layer": "CUSTOMER_BASE"
}]
}
CUSTOMER层(组织适配):
json复制{
"changes": [{
"selector": {
"id": "ApproverField",
"type": "sap.m.Input"
},
"content": {
"visible": "{= ${Amount} > 50000 }"
},
"layer": "CUSTOMER"
}]
}
USER层(个人设置):
json复制{
"changes": [{
"selector": {
"id": "VendorQuickSelect",
"type": "sap.m.ComboBox"
},
"content": {
"selectedKeys": ["100001", "100005"]
},
"layer": "USER"
}]
}
当SAP发布新版本时,我们验证以下场景:
注意:我曾见过一个项目因为开发团队随意修改Stable ID,导致之前积累的所有用户个性化设置全部失效。
问题1:变更没有生效
问题2:升级后部分变更失效
问题3:不同层级变更冲突
分层模型不仅适用于UI调整,还可以用于:
在实际项目中,我们还将这个模式扩展到了非SAPUI5应用的管理中,通过类似的分层思维解决了企业应用生命周期管理的诸多难题。