动手使用ABAP Channel开发一些小工具,提升日常工作效率-阿里云开发者社区

开发者社区> 汪子熙> 正文
登录阅读全文

动手使用ABAP Channel开发一些小工具,提升日常工作效率

简介: 今天的故事要从ABAP小游戏说起。 中国的ABAP从业者们手头或多或少都搜集了一些ABAP小游戏,比如下面这些。 消灭星星: 扫雷: 来自我的朋友刘梦,公众号"SAP干货铺"里的俄罗斯方块: 用ABAP画图: 以及用今天要谈到的ABAP Channel技术开发的乒乓球游戏,还能支持双打,囧 我心里一直有个念头,以严谨刻板著称的德国开发人员,看到这些流行于中国ABAP生态圈的小游戏,会有什么反应? 去年我在SAP德国总部做标准开发,经常参加一些会议。

今天的故事要从ABAP小游戏说起。

中国的ABAP从业者们手头或多或少都搜集了一些ABAP小游戏,比如下面这些。

消灭星星:

0e50b6bf35adfc6e751765d3c13573d615c22393

扫雷:

c22984c852f8344cc5ad3e334b64947c3e87b396

来自我的朋友刘梦,公众号"SAP干货铺"里的俄罗斯方块:

c565487bcc25c6c20ed61445effd624bf004e334

用ABAP画图:

41d7305847b16447b8bc1e1eaef4429f82a88de0

以及用今天要谈到的ABAP Channel技术开发的乒乓球游戏,还能支持双打,囧

5d380d5225ef1f3b4fbbeadb93ee3597fd742f52

我心里一直有个念头,以严谨刻板著称的德国开发人员,看到这些流行于中国ABAP生态圈的小游戏,会有什么反应?

去年我在SAP德国总部做标准开发,经常参加一些会议。一次会议上,我和其他几位CRM德国同事在会议室里一直等待一位S/4HANA同事的到来。大家也许会问,德国人素来以守时著称,为什么工作会议还会迟到?

那是因为SAP德国总部面积非常大,一共有20多栋楼。下图是SAP德国总部在Walldorf修建的第一栋大楼,拍摄于深秋季节。我们习惯称为Building 1,当时我就在里面工作。

4413f866056aab6c86fc55291f19ef8b42237cc0

大楼侧面看起来是这样的,拍摄于初夏:

cdbc4dcf75821dec059941940e1b58a268859ff6

这20多栋大楼分散在园区各个角落:

61d88fcb7820530032be08671695b5bbcccc943f

faad63f59365a928a49ce95ee1a4f4f3ccfc624b

fa22329f3194b0a88e305f8cef1a09a8d7212017

d0a5135449487a64594938f8d1326cfd41410a01


当时参加会议的S/4HANA同事在Building 3工作,刚开完上一个会,以Jerry的步行速度,走到Building 1的会议室需要5分钟时间。

在等待同事的时候,Jerry就把自己的电脑连接上了投影仪,然后给其他在场的几位德国同事一个一个秀这些小游戏。当我的同事Carsten,SAP CRM的首席架构师,看到ABAP编写的扫雷游戏时,不禁哈哈大笑,说道这是他在windows 98系统下玩的最多的一个游戏。

终于S/4HANA的同事到达了会议室,此时投影仪上正进行着用ABAP Channel编写的乒乓球游戏。这位德国同事盯着看了一会儿,幽默地说了一句:"Am I in the wrong room?"

下面是正文。




ABAP Channel是Netweaver 740发布的一项新的基于事件驱动的前后台通信技术,底层的实现基于WebSocket和TCPSocket。

做过SAP CRM呼叫中心(Interaction Center)的CRM顾问们,一定对这个产品的轮询机制有深刻的印象。因为当时技术的局限,每当ABAP后台有事件发生时,没有办法通知到前台WebClient UI界面。前台为了能够显示最新的数据,只得以一个固定的时间间隔,周期性地主动向ABAP后台发起轮询(poll)。

用Chrome开发者工具观测,能容易地观察到这个轮询行为:下图显示CRM呼叫中心每隔1秒钟向后台发起一个HTTP请求进行轮询。

bc81fd7aafe46a99407f4e0e5310c065cb93f86f

2014年,Netweaver 740发布了底层基于Web Socket协议的ABAP Channel技术,因此CRM 呼叫中心也顺势采用了该技术替换了之前笨拙而低效的轮询解决方案。

详细信息参考CRM呼叫中心产品经理Henning的博客:

Replace polling in CRM Interaction Center by ABAP Push Channel

https://blogs.sap.com/2014/04/30/replace-polling-in-crm-interaction-center-by-abap-push-channel/

很多SAP成都研究院做过CRM开发的同事都和Henning打过交道,这是一位在CRM领域业务知识极其精深,同时非常和蔼的德国人。

在SAP社区网站上已经有很多SAP从业者发表了各种关于ABAP Channel的博客,包括SAP自身也开发了很多例子,这些例子程序跟随Netweaver一起发布。

Jerry不再重复这些例子,感兴趣的朋友请参考这篇文章:

ABAP Channels Examples

https://blogs.sap.com/2016/06/09/abap-channels-examples/

今天我要分享的是Jerry如何使用ABAP Channel提升日常工作分析问题效率的一个具体例子。

ABAP从业者做项目时经常需要使用各种跟踪和性能监控工具,最典型的有ST05和SAT。Jerry确实认为这些工具对ABAP开发者非常有用,Jerry在SAP社区上唯一的一篇阅读量超过十万的博客就是这篇讲ST05和SAT另类用途的文章:

Six kinds of debugging tips to find the source code where the message is raised

https://blogs.sap.com/2013/11/15/six-kinds-of-debugging-tips-to-find-the-source-code-where-the-message-is-raised/

(2016年9月SAP社区改版了,迁移到了SAP云平台。迁移后所有博客的阅读量都清零了,因此现在这篇博客看到的阅读量只有四万多,而不是十万)

3a1bd190b9a7601c08dc538dfa5dc7324ddfe7a9

然而Jerry认为目前在Netweaver里所有的这些工具都有一个局限:开发人员必须要手工打开工具的跟踪模式,在该模式下运行应用。运行结束之后,或手动关掉跟踪模式,或者由工具自动关闭。也就是说,这些工具都无法在应用处于运行状态时,实时地提供开发者需要的信息。

我去年在德国参加了原CRM One Order框架迁移到S/4HANA的重构和原型开发工作。具体细节可以看我这篇公众号文章:Hello World, S/4HANA for Customer Management 1.0

原型开发完成后就得做测试了。我得在新的S4CRM UI上进行一系列和以前老CRM一样的操作,然后观察传入API的输入参数和API返回的输出参数是否正确。

起初我采用的方式是在API里设置断点,然后在ABAP调试器里检查。很快我发现这样效率很低:CRM开发顾问都知道,像CRM_ORDER_MAINTAIN/READ这种API, 输入输出参数个数特别多,在ABAP 调试器里得选中一个双击进去看,看完了得点回退再双击看另一个。如果要把API所有的参数全部检查完,总共要点一百多次鼠标。

8ccc40702d5f41a1ca9a8ba9c549b6bc0dc2768c

Jerry最受不了的就是这种重复的体力活。有没有办法可以让Netweaver也能像SAP云平台的CloudFoundry编程环境那样,一个

cf logs <app name>命令之后,正在运行的应用,其运行时产生的日志就哗哗哗地打印在浏览器上呢?有!使用ABAP Channel。

于是我动手开发了一个工具。看下这个工具怎么用:一个BSP应用,在浏览器里访问:

250b1ceae622664973f13380734d46739bd62d6e

然后直接切换到One Order应用,像往常一样进行操作。比如新建一个服务订单,维护下面几个字段:

b4409d734a4290c75e10b13caedfb65c2a6c9790

912dba9c2eb2d9d064a1aa7996bb9c55bb68d532

再切换回我做的工具,One Order API的输入和输出参数内容已经实时地显示在浏览器里了,再不用去调试器里进行繁琐的点击操作了。

d4413d8b8ded5f7ed39a315e52c2722cf10f7393

因为是通过浏览器显示,所以我还可以直接用CTRL+F根据关键字搜索,而这在SAPGUI里是没法做到的。后来我也把这个工具推荐给了Carsten。

下面是这个工具的详细开发步骤。

1. 事务码SAPC, 创建一个新的APC(ABAP Push Channel)应用ZORDER_LOG_APC,连接类型要选择成WebSocket。

点击按钮“Generate Class and Service” 自动生成处理类和ICF节点。

9b8717e6c754d0b281c407ca5d269237c9c76bd6

2. 事务码SAMC, 创建一个新的AMC(ABAP Message Channel)应用,取名为ZORDERLOG。

将第一步APC应用自动生成的ABAP类的名称维护到Authorization Program下面。这一步的目的是指定在ABAP Channel场景中,通过WebSocket进行数据收发的ABAP处理类名称。将Channel ID /order_log抄下来。

b146b7f753c8c50bb40aae6249611338fdfdf8e1

3. 从上图中得知我指定了ABAP类CL_CRM_ORDER_LOGGER用来将应用程序调用One Order API产生的日志发送到Web Socket上去,因此这一步需要对这个类进行编程了。完整代码在我的github上,这里仅阐述要点。

https://github.com/i042416/KnowlegeRepository/blob/master/ABAP/amc/CL_CRM_ORDER_LOGGER.abap

在静态构造函数里,将第二步创建的AMC ID和channel ID传入生产者的构造器里。确实,ABAP Channel的场景就是一个典型的生产者/消费者模式,ABAP后台生产的消息,通过Web Socket发送给浏览器由后者消费。

39ea8db48dabb746248fc276476147fe14cc44cf

消息的发送通过下面这个SEND方法完成。

d467d6ff33947fa9efd1245f6c39174b8cbababe

4. 重定义第一步APC应用自动生成的处理类的ON_START方法:

e6b87a88f3488de18958d6c66698abcb2e3e0e0d

在这个方法里将第一步创建的APC应用和第二步创建的AMC应用做绑定。

38178bdd20d8f8ea5a4787897008deddcf17b3bd

5. 给API CRM_ORDER_MAINTAIN创建一个增强,把我的CL_CRM_ORDER_LOGGER注入进去。这样每次该API被调用时,都会自动进行日志记录并通过Web Socket发送给浏览器。

7c9443a588621ba4ea838dc63a8a57d33cf8569c

fce0fa6a44d400feed07f6c7eb7e4a8e57bb35a2

以上五步就是ABAP Channel生产者的实现。下面是消费者,即运行于浏览器里的Web应用的开发。

创建一个BSP应用,在index.htm里维护下面的代码:

6f7fee5a17e7c1db84a0caddf699c78bc3de3e26

第17行声明了进行前后台通信的Web Socket url:

b8bd77acab9947da59b9c98f9f5bec3a2b21f0fe

这样消费者的开发也做完了。

大家在实际工作中,遇到繁琐耗时的体力活的时候,也可以多想想,能不能用工具来减少工作量,提高工作效率。感谢阅读。


本文作者:Wang Jerry
本文来自云栖社区合作伙伴“汪子熙”,了解相关信息可以关注“汪子熙

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

官网链接