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

本文介紹一個筆者在實際項目工作中 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.io/upload_images/2085791-7308cdcd1fa77389.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

再切換回我做的工具，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 技術的分析工具，能大幅提高程序員的日常工作效率。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。