关于sap:SAP-Restful-ABAP-Programming-编程模型的-Action-实现和云端调试介绍

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

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理