共计 2800 个字符，预计需要花费 7 分钟才能阅读完成。
笔者前一篇文章 SAP Fiori 注解 @ObjectModel.readOnly 工作原理解析，介绍了 SAP Fiori 编程模型里 @ObjectModel.readOnly 注解的工作原理。SAP Fiori 注解，是 ABAP Programming Model for SAP Fiori 的重要概念之一。
所谓注解(annotation)，Java 和 JavaScript 开发人员肯定不会生疏。
相似的，CDS 注解容许 ABAP 开发人员，将 ABAP 和特定于组件的元数据增加到任何 CDS 实体的源代码中。
依据一致性和注解有效性的评估实现细节，SAP CDS view 的注解分为以下两类:
- ABAP 注解：由 ABAP 运行时环境评估。
- Component 注解：由相干的 SAP 框架进行评估。
开发人员能够在元数据扩大中应用注解，为 CDS 视图定义特定于客户的元数据，而无需批改 SAP 公布的规范 CDS 实体自身。应用元数据扩大时，能够笼罩数据定义中定义的特定正文值，或向实体增加额定的正文值。
注解能够增加在 CDS view 上或者 view field 上，上面是一个例子：
@AbapCatalog.sqlViewName: 'CUSTOMER'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@Metadata.allowExtensions: true
DEFINE VIEW cust_book_view_entity
AS SELECT FROM scustom
JOIN sbook
ON scustom.id = sbook.customid
{
@EndUserText.label: 'Customer ID'
scustom.id,
@EndUserText.label: 'Customer Name'
scustom.name,
@EndUserText.label: 'Customer Booking ID'
sbook.bookid
}本文持续探讨另一个 注解 @OData.publish 的工作原理。
在 SAP 官网的 ABAP Programming Model for SAP Fiori 的帮忙文档里，在 OData Annotations 目录下有对这个注解的介绍。
一旦加上了这个注解的 CDS view 激活时，会主动生成一个 OData 服务。
这个 OData 服务是如何主动生成的？这就是本文所要分享的内容。
SAP Fiori 编程模型反对一种新的 OData 服务的裸露形式，这种 OData 服务的模型定义，和运行时，基于 Service Adaptation Description Language 简称 SADL.
上面是一个例子：
@AbapCatalog.sqlViewName: 'SQL_VIEW_SAMPLE'
...
@OData.publish: true
define view CDS_VIEW_NAME as select from
...
}应用 SAP ABAP Development Tool，关上 CDS 视图源代码编辑页面，将 OData 注解增加到 CDS 视图之后，就能够触发整个 DDL 源的激活。ABAP 开发工具将激活申请委托给 SADL 框架。SADL 生成若干个 SAP Gateway 构件(Artifacts)，这些构件存储在应用服务器 AS ABAP 的后端，是 SAP Gateway hub 零碎中激活和运行 OData 服务所必须的。
以上是通过 CDS view 裸露 OData 服务的理论知识。
假如咱们对加了这个注解的 CDS view 激活后主动生成的 OData 服务的明细无所不知，从何处开始动手进行钻研呢？
我创立了一个名为 zjerrytest20160311 的 view，而后加上这个注解，激活。依据我的教训，依照 SAP 常规，主动生成的 OData 服务的名称应该也会蕴含 0311 这个字符串。
激活之后，我试着用 0311 作为关键字在 OData 服务的注册事务码 /IWFND/MAINT_SERVICE 里搜寻，果然搜到了对应生成的 OData 服务：
在笔者之前的文章 ABAP 编程语言中 Class(类) 的设计原理分析 已经提到 ABAP Netweaver 的注册表 TADIR，依照 0311 进行查问，发现 CDS view 激活之后，除了 OData 服务自身，还主动生成了下列这些对象：
- IWMO: SAP Gateway Business Suite Enablement 对应的模型
- IWSV: SAP Gateway Business Suite Enablement 对应的服务
- CLAS: OData 服务的实现类 ZCL_ZJERRYTEST20160311
做个试验，当我把 OData.publish 的值设置为 false，再次激活，发现类型为 IWMO 和 IWSV 的对象从注册表 TADIR 中隐没了，这再次印证了二者是注解 OData.publish 设置为 true 之后激活 CDS view 生成的。
那么如何钻研 CDS view 激活时，这两个对象的主动生成逻辑呢？
关上事物码 ST05，进入跟踪模式，激活 CDS view，在数据库跟踪后果里果然发现了将主动生成的对象名称插入到注册表 TADIR 的 OPEN SQL 语句。
在 ABAP 里，在插入数据库表的 OPEN SQL 语句之前，必然有待插入数据的生成逻辑。
点击 ST05 里蓝色的眼镜图标，主动跳转到 OPEN SQL 语句里。设置断点，激活 CDS view，断点触发：
从以后的调用栈往外追溯，发现在第 21 个调用栈帧，正是主动生成 OData 服务的中央：
CL_WB_DDLS_SECOBJ_HNDLR_SINGLE->IF_DDIC_WB_DDLS_SECOBJ_HANDLER~ON_ACTIVATION
这个办法首先依据 delta_state 判断出须要删除，新增或者更新的对象清单，别离存储在下图 12 到 14 行三个输入参数里。
举个例子，当我在一个曾经激活过后的 CDS view 源代码里增加 @OData.publish:true 的注解，而后激活，此时该注解对于的 EDIT_STATE 为 N(New), 而其余的注解因为没有任何变动，被标记为 U(Unchanged).
此处会依据 EDIT_STATE 的值，进入对应的分支。
EDIT_STATE 值为 N 的分支，则执行 OData 服务的创立，通过 CL_SADL_GTK_ODATA_SERVICE_GEN 实现，后缀 GEN 代表 Generation.
从调试器里能看出，名称为 ZJERRYTEST20160311 的 OData 服务通过 create_via_exposure 办法被创立。
残缺的调用栈：
本文其实也是另一个具体的例子，在不理解一段逻辑 (无论框架层面或者利用层面) 的状况下，如何应用 ST05 这个工具来找到设置断点的代码地位，从而找到问题剖析的突破口。
总结
本文从一个开发人员的视角，深刻介绍了 SAP Fiori 注解 @OData.publish 的工作原理。同时也展现了如何通过事物码 ST05，自行定位到 ABAP 框架主动生成 OData 服务资源的精确代码地位。