程序员区别于其他岗位的一个优势是，我们可以充分利用自己掌握的编程语言，将平日一些琐碎的，重复的日常工作，通过代码来实现自动化，从而省下更多的时间来投入到技术含量更高的工作中，提高工作效率。
本文介绍一个笔者在实际项目工作中 ABAP 这门编程语言实现的一个工作自动化的例子。
客户端轮询 vs Web Socket API
ABAP Channel 是 Netweaver 740 发布的一项新的基于事件驱动的前后台通信技术，底层的实现基于 Web Socket 和 TCP Socket.
所谓 Web Socket，是一种在用户的浏览器和服务器之间打开双向交互通信会话的技术。 使用基于 Web Socket 的应用编程接口，我们可以向服务器发送消息并接收事件驱动的响应，而无需轮询服务器以获取回复。
做过 SAP CRM 呼叫中心(Interaction Center)的 CRM 顾问们，一定对这个产品的轮询机制有深刻的印象。因为当时技术的局限，每当 ABAP 后台有事件发生时，没有办法通知到前台 WebClient UI 界面。前台为了能够显示最新的数据，只得以一个固定的时间间隔，周期性地主动向 ABAP 后台发起轮询(poll)。
用 Chrome 开发者工具观测，能容易地观察到这个轮询行为：下图显示 CRM 呼叫中心每隔 1 秒钟向后台发起一个 HTTP 请求进行轮询。
2014 年，Netweaver 740 发布了底层基于 Web Socket 协议的 ABAP Channel 技术，因此 CRM 呼叫中心也顺势采用了该技术替换了之前笨拙而低效的轮询解决方案。
ABAP 从业者做项目时经常需要使用各种跟踪和性能监控工具，最典型的有 ST05 和 SAT. 笔者确实认为这些工具对 ABAP 开发者非常有用。
然而目前在 Netweaver 里所有的这些工具都有一个局限：开发人员必须要手工打开工具的跟踪模式，在该模式下运行应用。运行结束之后，或手动关掉跟踪模式，或者由工具自动关闭。也就是说，这些工具都无法在应用处于运行状态时，实时地提供开发者需要的信息。
我之前在德国参加了原 CRM One Order 框架迁移到 S/4HANA 的重构和原型开发工作。
原型开发完成后就得做测试了。我得在新的 S4CRM UI 上进行一系列和以前老 CRM 一样的操作，然后观察传入 API 的输入参数和 API 返回的输出参数是否正确。
起初我采用的方式是在 API 里设置断点，然后在 ABAP 调试器里检查。很快我发现这样效率很低：CRM 开发顾问都知道，像 CRM_ORDER_MAINTAIN/READ 这种 API, 输入输出参数个数特别多，在 ABAP 调试器里得选中一个双击进去看，看完了得点回退再双击看另一个。如果要把 API 所有的参数全部检查完，总共要点一百多次鼠标。
笔者最受不了的就是这种重复的体力活。有没有办法可以让 Netweaver 也能像 SAP 云平台的 CloudFoundry 编程环境那样，一个 cf logs app name 命令之后，正在运行的应用，其运行时产生的日志就哗哗哗地打印在浏览器上呢？有！使用 ABAP Channel.
于是我动手开发了一个工具。看下这个工具怎么用：一个 BSP 应用，在浏览器里访问：
然后直接切换到 One Order 应用，像往常一样进行操作。比如新建一个服务订单，维护下面几个字段：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VxPADURG-1647864842811)(https://upload-images.jianshu...)]
再切换回我做的工具，One Order API 的输入和输出参数内容已经实时地显示在浏览器里了，再不用去调试器里进行繁琐的点击操作了。
因为是通过浏览器显示，所以我还可以直接用 CTRL+F 根据关键字搜索，而这在 SAPGUI 里是没法做到的。
下面是这个工具的详细开发步骤。
- 事务码 SAPC, 创建一个新的 APC(ABAP Push Channel) 应用ZORDER_LOG_APC，连接类型要选择成 WebSocket。
点击按钮 Generate Class and Service 自动生成处理类和 ICF 节点。
- 事务码 SAMC, 创建一个新的 AMC(ABAP Message Channel)应用，取名为ZORDERLOG。
将第一步 APC 应用自动生成的 ABAP 类的名称维护到 Authorization Program 下面。这一步的目的是指定在 ABAP Channel 场景中，通过 WebSocket 进行数据收发的ABAP 处理类名称。将 Channel ID/order_log 抄下来。
- 从上图中得知我指定了 ABAP 类 CL_CRM_ORDER_LOGGER 用来将应用程序调用One Order API 产生的日志发送到 Web Socket 上去，因此这一步需要对这个类进行编程了。
在静态构造函数里，将第二步创建的 AMC ID 和 channel ID 传入生产者的构造器里。确实，ABAP Channel 的场景就是一个典型的生产者/消费者模式，ABAP 后台生产的消息，通过 Web Socket 发送给浏览器由后者消费。
消息的发送通过下面这个 SEND 方法完成。
- 重定义第一步 APC 应用自动生成的处理类的 ON_START 方法：
在这个方法里将第一步创建的APC应用和第二步创建的AMC应用做绑定。
- 给 API CRM_ORDER_MAINTAIN 创建一个增强，把我的CL_CRM_ORDER_LOGGER 注入进去。这样每次该 API 被调用时，都会自动进行日志记录并通过 Web Socket 发送给浏览器。
以上五步就是 ABAP Channel 生产者的实现。下面是消费者，即运行于浏览器里的 Web应用的开发。
创建一个 BSP 应用，在 index.htm 里维护下面的代码：
第 17 行声明了进行前后台通信的 Web Socket url：
这样 Web Socket 消费者的开发也做完了。
总结
本文首先介绍了传统呼叫中心中浏览器采取轮询方式从服务器抓取响应的低效解决方案，从而引出 Web Socket 技术的应用场景。接着介绍了传统 ABAP 性能分析工具需要显式开启和关闭 trace 模式的痛点，提出了一种新型的基于 Web Socket 技术的分析工具，能大幅提高程序员的日常工作效率。