程序员区别于其余岗位的一个劣势是，咱们能够充分利用本人把握的编程语言，将素日一些琐碎的，反复的日常工作，通过代码来实现自动化，从而省下更多的工夫来投入到技术含量更高的工作中，进步工作效率。
本文介绍一个笔者在理论我的项目工作中 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 技术的剖析工具，能大幅提高程序员的日常工作效率。