共计 2462 个字符，预计需要花费 7 分钟才能阅读完成。
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 后盾协同工作的技术细节。