今天的故事要从 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
- 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 云平台. 迁移后所有博客的阅读量都清零了, 因此现在这篇博客看到的阅读量只有四万多, 而不是十万)
然而 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 上, 这里仅阐述要点.
https://GitHub.com/i042416/KnowlegeRepository/blob/master/ABAP/amc/CL_CRM_ORDER_LOGGER.abap
在静态构造函数里, 将第二步创建的 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:
这样消费者的开发也做完了.
来源: https://yq.aliyun.com/articles/644739