今天的故事要从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不再重复这些例子，感兴趣的朋友请参考这篇文章：
今天我要分享的是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
于是我动手开发了一个工具。看下这个工具怎么用：一个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：
这样消费者的开发也做完了。
大家在实际工作中，遇到繁琐耗时的体力活的时候，也可以多想想，能不能用工具来减少工作量，提高工作效率。感谢阅读。
更多阅读
要获取更多Jerry的原创文章，请关注公众号"汪子熙":
