测试
全部博文（931）
分类： 架构设计与优化
2019-10-17 12:17:43
相信通过Jerry的前一篇文章 30分钟用Restful ABAP Programming模型开发一个支持增删改查的Fiori应用，想必大家对Restful ABAP Programming模型已经有了一个最基本的了解吧？
简单回忆一下，我们在前一篇文章里，在SAP云平台ABAP编程环境里创建了一个Z表，然后基于这张自定义数据库表创建了CDS view，基于该view创建Service Definition，把view暴露成服务，然后通过Behavior Definition实现对Z表的增删改查。
第一篇文章有朋友留言，询问通过RAP模型生成的Fiori应用如何部署到云上。这位朋友忘记了Jerry从始至终都是在SAP云平台ABAP环境上操作的啊，所以这个生成的Fiori应用也直接在云上可用了。
双击Service Binding里的TravelProcessor或者右键菜单里选择Open Fiori Elements App Preview, 就可以访问Fiori应用。
稍稍有点经验的顾问朋友们都明白，一个模型只有增删改查的功能是不能满足客户实际需求的。在SAP Cloud for Customer里，开发顾问可以在Cloud Application Studio里创建beforeSave和afterModify这些脚本文件并实现业务逻辑，Jerry也曾经介绍过，它们相当于S/4HANA BOPF框架里创建的determination.
除了上述在运行时特定的时间点才能触发(beforeSave，afterModify)的逻辑外，Action机制则提供了自由度更高的业务逻辑编写机制。体现在UI上，Action逻辑一般通过UI按钮触发。
Validation比较容易理解——自定义的数据校验逻辑。
本文按照顺序介绍Action和Validation.
为了介绍在Restful ABAP Programming模型下如何开发Action，Jerry需要在第一篇文章创建的SFLIGHT表增添一个表示航班预订状态的字段，并开发一个Action，当其被调用时，修改这个状态。
(1）在数据库表里增添一个OVERALL_STATUS字段：
当然在对应的CDS view上也要通过@UI相关的注解把这个字段配置到UI上。通过注解lineItem和identification分别把view的这个字段显示在搜索结果的table控件和航班信息明细页面的字段上。通过label指定UI上显示的标签，通过注解的dataAction把这个状态字段绑定到一个名为acceptTravel的Action上。
重新激活CDS view后，我们就能在工具栏上看到CDS view里通过label维护的标签文本为Accept Travel了：
因为缺乏实现，此时点击无效果。
(2) 在Behavior Definition的声明部分，添加如下三行代码：
上面的代码除了定义一个Action外，还声明了两个Validation，在特定字段发生变化并保存时触发校验逻辑，字段名称维护在大括号内。
剩下的就是ABAP编程实现了。在Behavior Definition的ABAP实现类里，声明下面这些ABAP类方法，来实现Behavior Definition里的定义。
首先看Action的实现，位于ABAP方法SET_STATUS_COMPLETED里：
将输入参数travel_id指定的航班预订记录的状态字段置为A - Accepted.
现在我选中ID为22这条记录，点击Accept Travel按钮：
点击之后，状态成功被置为A了：
再来加上对航班日期的校验：如果航班结束日期在起始日期之前，显然不合理，需要弹一条错误消息。
第87行到第91行把输入参数包含的航班信息读到内表lt_travel_result里，然后第95行把结束日期和起始日期做比较，如果后者早于前者，进入97行开始的IF分支，弹一个错误信息到UI.
错误信息仍然和传统的ABAP编程一样，通过ABAP Message类定义：
现在把结束日期维护成起始日期之前，保存的时候就看到了期望的错误消息：
至此，我们这个SFLIGHT模型除了增删改查之外，又增添了Action和Validation的功能。
这个系列的下一篇文章，Jerry会聊聊在SAP云平台ABAP编程环境里对基于Restful ABAP Programming模型应用的简单调试，敬请期待。
要获取更多Jerry的原创文章，请关注公众号"汪子熙":
