全部博文（932）
分类： 架构设计与优化
2020-02-04 21:03:54
今天是2020年2月1日鼠年大年初八，这是Jerry鼠年的第8篇文章，也是汪子熙公众号总共第207篇原创文章。
Jerry的前一篇文章 揭开SAP Fiori编程模型规范里注解的神秘面纱 - @ObjectModel.readOnly工作原理解析，给大家分享了@ObjectModel.readOnly这个注解对应的Fiori UI和ABAP后台的工作原理。
今天我们继续研究另一个注解@OData.publish.
在SAP官网的ABAP Programming Model for SAP Fiori的帮助文档里，在OData Annotations目录下有对这个注解的介绍：
一旦加上了这个注解的CDS view激活时，会自动生成一个OData服务。
这个OData服务是如何自动生成的？这就是本文所要分享的内容。
假设我们对加了这个注解的CDS view激活后自动生成的OData服务的明细一无所知，从何处开始入手进行研究呢？
我创建了一个名为zjerrytest20160311的view，然后加上这个注解，激活。根据我的经验，按照SAP惯例，自动生成的OData服务的名称应该也会包含0311这个字符串。
激活之后，我试着用0311作为关键字在OData服务的注册事务码/IWFND/MAINT_SERVICE里搜索，果然搜到了对应生成的OData服务：
在Jerry之前的文章 [ABAP CCDEF, CCIMP, CCMAC, CCAU, CMXXX这些东东是什么鬼](ABAP CCDEF, CCIMP, CCMAC, CCAU, CMXXX这些东东是什么鬼) 曾经提到ABAP Netweaver的注册表TADIR，按照0311进行查询，发现CDS view激活之后，除了OData服务本身，还自动生成了下列这些对象：
做个实验，当我把OData.publish的值设置为false，再次激活，发现类型为IWMO和IWSV的对象从注册表TADIR中消失了，这再次印证了二者是注解OData.publish设置为true之后激活CDS view生成的。
那么如何研究CDS view激活时，这两个对象的自动生成逻辑呢？
使用Jerry文章(SAP错误消息调试之七种武器：让所有的错误消息都能被定位) 里介绍的第六种武器，离别钩之ST05.
打开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这个工具来找到设置断点的代码位置，从而找到问题分析的突破口。
感谢阅读。
更多阅读
