动手使用ABAP Channel开发一些小工具，提高平常工做效率

今天的故事要从ABAP小游戏提及。

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

消灭星星：

扫雷：

来自个人朋友刘梦，公众号"SAP干货铺"里的俄罗斯方块：

用ABAP画图：

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

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

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

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

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

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

当时参加会议的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请求进行轮询。

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

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

Replace polling in CRM Interaction Center by ABAP Push Channel

不少SAP成都研究院作过CRM开发的同事都和Henning打过交道，这是一位在CRM领域业务知识极其精深，同时很是和善的德国人。

在SAP社区网站上已经有不少SAP从业者发表了各类关于ABAP Channel的博客，包括SAP自身也开发了不少例子，这些例子程序跟随Netweaver一块儿发布。

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

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

(2016年9月SAP社区改版了，迁移到了SAP云平台。迁移后全部博客的阅读量都清零了，所以如今这篇博客看到的阅读量只有四万多，而不是十万）

然而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全部的参数所有检查完，总共要点一百屡次鼠标。

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

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

因而我动手开发了一个工具。看下这个工具怎么用：一个BSP应用，在浏览器里访问：

而后直接切换到One Order应用，像往常同样进行操做。好比新建一个服务订单，维护下面几个字段：

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

由于是经过浏览器显示，因此我还能够直接用CTRL+F根据关键字搜索，而这在SAPGUI里是无法作到的。后来我也把这个工具推荐给了Carsten。

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

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

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

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

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

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

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

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

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

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

5. 给API CRM_ORDER_MAINTAIN建立一个加强，把个人CL_CRM_ORDER_LOGGER注入进去。这样每次该API被调用时，都会自动进行日志记录并经过Web Socket发送给浏览器。

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

建立一个BSP应用，在index.htm里维护下面的代码：

第17行声明了进行先后台通讯的Web Socket url：

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

你们在实际工做中，遇到繁琐耗时的体力活的时候，也能够多想一想，能不能用工具来减小工做量，提升工做效率。感谢阅读。

更多阅读

• 聊聊C语言和ABAP
• Jerry的ABAP, Java和JavaScript乱炖
• Jerry的ABAP原创技术文章合集
• ABAP开发人员将来应该学些什么
• Jerry 2017年的五一小长假：8种经典排序算法的ABAP实现
• SAP成都研究院35岁以上的开发人员都去哪儿了?
• 一个SAP开发人员的双截棍之路

要获取更多Jerry的原创文章，请关注公众号"汪子熙":