笔者之前的文章如何使用 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 编程环境中进行开发的必备技巧，即代码的单步调试。