共计 3084 个字符，预计需要花费 8 分钟才能阅读完成。
笔者之前的文章如何应用 Restful ABAP Programming 编程模型开发一个反对增删改查的 Fiori 利用，曾经对 SAP Restful ABAP Programming 编程模型 (以下简称 RAP) 进行了一个最根本的介绍。
咱们简略回顾一下之前文章的内容：在 SAP 云平台 ABAP 编程环境里创立了一个 Z 表，而后基于这张自定义数据库表创立了 CDS view，基于该 view 创立 Service Definition，把 view 裸露成服务，而后通过 Behavior Definition 实现对 Z 表的增删改查。
双击 Service Binding 里的 TravelProcessor 或者右键菜单里抉择 Open Fiori Elements App Preview, 就能够拜访 Fiori 利用。
稍稍有点教训的 SAP 参谋敌人们都明确，一个模型只有增删改查的性能是不能满足客户理论需要的。在 SAP Cloud for Customer 里，开发参谋能够在 Cloud Application Studio 里创立 beforeSave 和 afterModify 这些脚本文件并实现业务逻辑，笔者也已经介绍过，它们相当于 S /4HANA BOPF 框架里创立的 determination.
除了上述在运行时特定的工夫点能力触发 (beforeSave，afterModify) 的逻辑外，Action 机制则提供了自由度更高的业务逻辑编写机制。体现在 UI 上，Action 逻辑个别通过 UI 按钮触发。
Validation 比拟容易了解——自定义的数据校验逻辑。
本文依照程序介绍 RAP 的 Action 和 Validation.
为了介绍在 Restful ABAP Programming 模型下如何开发 Action，咱们在前一篇文章创立的 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 (features: instance) acceptTravel result [1] $self;
validation validateCustomer on save {field customer_id;}
validation validateDates on save {field begin_date, end_date;下面的代码除了定义一个 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 的性能。
利用开发实现后，咱们就能够开始调试了。
我选中 ID 为 103 这条记录，点击 Accept Travel 按钮后，冀望通过该 Action 将其状态设置为 Accepted：
可怜的是，我没能看到冀望中的状态变动，而是上面这个所有 ABAP 编程人员都不违心看见的 ABAP 运行时谬误提醒界面。
不过，大家留神到了上图右下角的 Debug 超链接么？和 SAPGUI 一样，点击之后立刻就能关上调试器，可能察看产生这个运行时谬误的调用栈，引起谬误的具体代码地位和相干变量的值。
回到 ABAP Development Tool 里，咱们先点击 Show 超链接，就能够看到运行时谬误明细：Short Text 通知咱们，咱们点击 Accept 按钮后，相干的解决框架无意地抛出一个 CX_CSP_ACT_RESPONSE 的异样。抛出异样的地位是在程序 CL_CSP_ACT_CHECK_FEATS_ACTIONS 里，这暗示咱们，这个错可能和 Action 执行前的查看 (CHECK) 无关。
持续向下滑动鼠标，发现在框架代码内，因为从第 353 行内表 it_feature_result 里没有读出任何内容，因而 sy-subrc 不为 0，导致进入第 355 行的 RAISE SHORTDUMP 分支。
在 SAP Cloud Platform ABAP 环境下以后登录用户产生的所有运行时谬误，能够在 ABAP Development Tool 的 Feed Reader 视图下查看，这个性能相当于 SAP GUI 里的 ST22 事务码。
当初咱们对于这个运行时谬误的动态信息理解得差不多了，下一步在调试器里察看。
重新启动 Fiori 利用，再次点击 Accept 按钮，呈现运行时谬误后点击 Debug 超链接，ABAP 调试器自动弹出，引起运行时谬误的那一行代码被高亮，同时右边显示出调用栈。
把鼠标放在 it_feature_result 上，发现这个内表是空的，当然无奈从外面读出数据了。这个内表是以后 ABAP 类 CL_CSP_ACT_CHECK_FEATS_ACTIONS 的办法 handle_rejected_instances 的输出参数，须要搞清楚为啥这个输出参数为空。
从抛出运行时异样的栈帧往外看一帧，就晓得这个输出的内表是通过第 291 行的 execute_feature_controllers 生成的，这个办法会通过回调函数的形式，调用咱们在 Behavior Definition 实现的一个 get_features 办法里：
这里咱们就找到了引起这个运行时谬误的本源：因为之前笔者出于测试目标，正文了一段代码，导致 get_features 被框架回调时，没有返回框架冀望的数据：
当 Jerry 把这段须要的代码从新 enable 而后设置断点，点击 Accept 按钮，通过调用栈能够清晰看到框架的 execute_feature_controllers 是如何调用到咱们实现的 get_features 回调办法的。
总结
本文首先在一个反对增删改查四种根底操作的 RAP 利用上，削减了 Action 和 Validation 实现，二者都是云端 ABAP 编程环境里进行业务逻辑编写的重要伎俩。其次介绍了云端 ABAP 编程环境中进行开发的必备技巧，即代码的单步调试。
