程序員區(qū)別于其他崗位的一個優(yōu)勢是，我們可以充分利用自己掌握的編程語言，將平日一些瑣碎的，重復的日常工作，通過代碼來實現(xiàn)自動化，從而省下更多的時間來投入到技術(shù)含量更高的工作中，提高工作效率。

本文介紹一個筆者在實際項目工作中 ABAP 這門編程語言實現(xiàn)的一個工作自動化的例子。

客戶端輪詢 vs Web Socket API

ABAP Channel 是 Netweaver 740 發(fā)布的一項新的基于事件驅(qū)動的前后臺通信技術(shù)，底層的實現(xiàn)基于 Web Socket 和 TCP Socket.

所謂 Web Socket，是一種在用戶的瀏覽器和服務器之間打開雙向交互通信會話的技術(shù)。 使用基于 Web Socket 的應用編程接口，我們可以向服務器發(fā)送消息并接收事件驅(qū)動的響應，而無需輪詢服務器以獲取回復。

做過 SAP CRM 呼叫中心(Interaction Center)的 CRM 顧問們，一定對這個產(chǎn)品的輪詢機制有深刻的印象。因為當時技術(shù)的局限，每當 ABAP 后臺有事件發(fā)生時，沒有辦法通知到前臺 WebClient UI 界面。前臺為了能夠顯示最新的數(shù)據(jù)，只得以一個固定的時間間隔，周期性地主動向 ABAP 后臺發(fā)起輪詢(poll)。

用 Chrome 開發(fā)者工具觀測，能容易地觀察到這個輪詢行為：下圖顯示 CRM 呼叫中心每隔 1 秒鐘向后臺發(fā)起一個 HTTP 請求進行輪詢。

2014 年，Netweaver 740 發(fā)布了底層基于 Web Socket 協(xié)議的 ABAP Channel 技術(shù)，因此 CRM 呼叫中心也順勢采用了該技術(shù)替換了之前笨拙而低效的輪詢解決方案。

ABAP 從業(yè)者做項目時經(jīng)常需要使用各種跟蹤和性能監(jiān)控工具，最典型的有 ST05 和 SAT. 筆者確實認為這些工具對 ABAP 開發(fā)者非常有用。

然而目前在 Netweaver 里所有的這些工具都有一個局限：開發(fā)人員必須要手工打開工具的跟蹤模式，在該模式下運行應用。運行結(jié)束之后，或手動關掉跟蹤模式，或者由工具自動關閉。也就是說，這些工具都無法在應用處于運行狀態(tài)時，實時地提供開發(fā)者需要的信息。

我之前在德國參加了原 CRM One Order 框架遷移到 S/4HANA 的重構(gòu)和原型開發(fā)工作。

原型開發(fā)完成后就得做測試了。我得在新的 S4CRM UI 上進行一系列和以前老 CRM 一樣的操作，然后觀察傳入 API 的輸入?yún)?shù)和 API 返回的輸出參數(shù)是否正確。

起初我采用的方式是在 API 里設置斷點，然后在 ABAP 調(diào)試器里檢查。很快我發(fā)現(xiàn)這樣效率很低：CRM 開發(fā)顧問都知道，像 CRM_ORDER_MAINTAIN/READ 這種 API, 輸入輸出參數(shù)個數(shù)特別多，在 ABAP 調(diào)試器里得選中一個雙擊進去看，看完了得點回退再雙擊看另一個。如果要把 API 所有的參數(shù)全部檢查完，總共要點一百多次鼠標。

筆者最受不了的就是這種重復的體力活。有沒有辦法可以讓 Netweaver 也能像 SAP 云平臺的 CloudFoundry 編程環(huán)境那樣，一個 cf logs app name 命令之后，正在運行的應用，其運行時產(chǎn)生的日志就嘩嘩嘩地打印在瀏覽器上呢？有！使用 ABAP Channel.

于是我動手開發(fā)了一個工具。看下這個工具怎么用：一個 BSP 應用，在瀏覽器里訪問：

然后直接切換到 One Order 應用，像往常一樣進行操作。比如新建一個服務訂單，維護下面幾個字段：

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-VxPADURG-1647864842811)(https://upload-images.jianshu.io/upload_images/2085791-7308cdcd1fa77389.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

再切換回我做的工具，One Order API 的輸入和輸出參數(shù)內(nèi)容已經(jīng)實時地顯示在瀏覽器里了，再不用去調(diào)試器里進行繁瑣的點擊操作了。

因為是通過瀏覽器顯示，所以我還可以直接用 CTRL+F 根據(jù)關鍵字搜索，而這在 SAPGUI 里是沒法做到的。

下面是這個工具的詳細開發(fā)步驟。

事務碼 SAPC, 創(chuàng)建一個新的 APC(ABAP Push Channel) 應用ZORDER_LOG_APC，連接類型要選擇成 WebSocket。

點擊按鈕 Generate Class and Service 自動生成處理類和 ICF 節(jié)點。

事務碼 SAMC, 創(chuàng)建一個新的 AMC(ABAP Message Channel)應用，取名為ZORDERLOG。

將第一步 APC 應用自動生成的 ABAP 類的名稱維護到 Authorization Program 下面。這一步的目的是指定在 ABAP Channel 場景中，通過 WebSocket 進行數(shù)據(jù)收發(fā)的ABAP 處理類名稱。將 Channel ID/order_log 抄下來。

從上圖中得知我指定了 ABAP 類 CL_CRM_ORDER_LOGGER 用來將應用程序調(diào)用One Order API 產(chǎn)生的日志發(fā)送到 Web Socket 上去，因此這一步需要對這個類進行編程了。

在靜態(tài)構(gòu)造函數(shù)里，將第二步創(chuàng)建的 AMC ID 和 channel ID 傳入生產(chǎn)者的構(gòu)造器里。確實，ABAP Channel 的場景就是一個典型的生產(chǎn)者/消費者模式，ABAP 后臺生產(chǎn)的消息，通過 Web Socket 發(fā)送給瀏覽器由后者消費。

消息的發(fā)送通過下面這個 SEND 方法完成。

重定義第一步 APC 應用自動生成的處理類的 ON_START 方法：

在這個方法里將第一步創(chuàng)建的APC應用和第二步創(chuàng)建的AMC應用做綁定。

給 API CRM_ORDER_MAINTAIN 創(chuàng)建一個增強，把我的CL_CRM_ORDER_LOGGER 注入進去。這樣每次該 API 被調(diào)用時，都會自動進行日志記錄并通過 Web Socket 發(fā)送給瀏覽器。

以上五步就是 ABAP Channel 生產(chǎn)者的實現(xiàn)。下面是消費者，即運行于瀏覽器里的 Web應用的開發(fā)。

創(chuàng)建一個 BSP 應用，在 index.htm 里維護下面的代碼：

第 17 行聲明了進行前后臺通信的 Web Socket url：

這樣 Web Socket 消費者的開發(fā)也做完了。

總結(jié)

本文首先介紹了傳統(tǒng)呼叫中心中瀏覽器采取輪詢方式從服務器抓取響應的低效解決方案，從而引出 Web Socket 技術(shù)的應用場景。接著介紹了傳統(tǒng) ABAP 性能分析工具需要顯式開啟和關閉 trace 模式的痛點，提出了一種新型的基于 Web Socket 技術(shù)的分析工具，能大幅提高程序員的日常工作效率。

總結(jié)

以上是生活随笔為你收集整理的使用 ABAP 开发的一个基于 Web Socket 的小工具，能提高程序员日常工作效率的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。