SAP Fiori 注解，是 ABAP Programming Model for SAP Fiori 的重要概念之一。

ABAP Programming Model for SAP Fiori 适用于 SAP NetWeaver AS for ABAP 7.51 innovation package, SP00 或者更高的版本。对底层数据库没有要求，推荐使用 SAP HANA.

开发人员需要具备如下的 PFCG role：

• SAP_BC_DWB_ABAPDEVELOPER

• SAP_BC_DWB_WBDISPLAY

• /IWFND/RT_DEVELOPER (用于 SAP Gateway service 开发).

架构如下：

作为 SAP 客户，在某些情况下，可能希望扩展 SAP 或 SAP 合作伙伴交付的 On-Premise 应用程序的用户界面(UI)。

字段可扩展性(Fiori Extensibility)意味着客户希望在给定的业务应用程序上下文中提供额外的字段，该上下文由实际使用的 UI 表示。这些字段是 SAP 交付时应用程序没有预见到的。在这种情况下，可以选择使用 ABAP 平台的可扩展基础设施，以便向原始应用程序添加自定义字段。这个基础设施首先需要确保将新的数据元素添加到持久性(数据库表)和之间所有涉及的层(ABAP Dictionary、CDS、SAP Gateway 服务)。基础设施还需要再次向应用程序 UI 的服务元数据公开，以供其他消费者使用。

可以在不同的场景中使用此基础设施:

• Key User Extensibility：只对可配置的扩展感兴趣，因为它们是在业务高级用户(关键用户)适配上下文中使用的。

• 自定义代码可扩展性——希望通过实现自己的扩展，通过自定义代码这种编程方式，最大限度地利用该基础设施的字段可扩展性。

关键用户可扩展性允许关键用户创建自定义字段，如果 SAP 应用程序启用了可扩展性。关键用户具有业务透视图，不需要关心技术细节。因此，关键用户最终能够创建和更改自定义字段及其属性(名称、标签、类型或屏幕上的位置)。

如果 SAP 应用程序启用了可扩展性，优先选择使用关键用户工具来创建自定义字段，即使作为开发人员也是如此，因为关键用户工具隐藏了 SAP 应用程序的技术细节。另一方面，SAP 建议在以下情况下使用扩展视图直接创建自定义字段:

• SAP 应用程序还没有启用可扩展性

• 关键用户工具的功能不够充分。例如，希望在自定义字段中进行计算。

我们必须记住，自定义代码可扩展性需要整个开发周期通过代码添加来实现扩展。反过来，这就需要对最初以 CDS 视图的形式交付并作为 OData 服务发布以供进一步使用的数据模型进行扩展。

SAP官网的 ABAP Programming Model for Fiori 帮助文档里，定义了很多注解(Annotation):

对于这些注解，我们可以从其字面含义和 SAP 帮助文档去掌握其用法和功能。

以 @ObjectModel.readOnly 为例，施加了这个注解的 CDS view 字段，在对应的 Fiori UI 上以只读的方式渲染：

并且也不能通过编程的方式进行修改。

大家在使用这些注解的时候，有没有想过，它们是怎么工作的？

以 @ObjectModel.readOnly 为例，现在就请跟着笔者一起，去探索它的前后台实现原理。

在 Chrome 开发者工具的 UI5 面板里，找到 Posting Date 这个控件对应的属性，发现字段 editable 属性值为 false，这就是其在 UI 不能编辑的原因。

既然后台模型是 CDS view，那么前台 UI 显然基于 Fiori Elements. 我想知道 Posting Date 这个控件的 editable 属性是在什么时候被设置成 false 的。

在 SmartField.setEditable 函数里设置断点，重新打开 Fiori UI，点击 Edit 进入编辑模型，断点触发，从调用栈能看出，有代码调用 SmartField.setEditable 时，传入的参数为 false.

那么这个 false 如何计算出来的？顺着当前的调用栈往外层查找，发现一个重要的函数：AnnotationHelper.canUpdateProperty.

从函数名就能猜测出，这个函数负责计算一个控件的属性是否允许更新(Update)，工作的上下文就是注解(Annotation).

这个方法实现体的语义也很清楚，如果后台模型字段 sap:updatable 设置为 false，则 canUpdateProperty 函数调用返回 false，导致 SmartField.setEditable 以参数 false 去渲染 Fiori UI.

我们打开 OData 服务的 metadata，发现 posting date 字段对应的 sap:updatable 果然为 false.

至此 Fiori UI 的工作原理分析完毕。我们再来看后台。我的 CDS view 里只添加了 @ObjectModel.readOnly 为 true 的注解，而非 sap:updatable. 显然，这二者存在一定的关联关系。

第 839 行的 IF 判断，如果 OBJECTMODEL.READONLY 为 true，则 read_only 属性为 X.而 read_only 属性为 true，会导致 posting date 字段的属性集合内表里，新增一条 read_only 为 X 的记录：

最后，在 SADL 框架的属性检测逻辑中，一旦发现字段属性集合内表里存在 read_only 为 X 的属性，则将 lv_creatable 和 lv_updatable 置为 false.

而 SADL 框架计算出来的这两个值为 false 的布尔变量，最后就会将 sap:creatable 和 sap:updatable 设置为 false.

@ObjectModel.readOnly 属性的前后台工作原理的神秘面纱，至此就揭开了，然而它只是 SAP Fiori 编程模型众多注解的冰山一角。

总结

本文首先概述了 ABAP Programming Model for SAP Fiori 的定义，接着以这种编程模型里一个重要的注解 @ObjectModel.readOnly 为例，详细介绍了 CDS 注解与 ABAP 后台协同工作的技术细节。