動手使用ABAP Channel開發一些小工具，提升日常工作效率
今天的故事要從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釋出的一項新的基於事件驅動的前後臺通訊技術，底層的實現基於Socket/">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的重構和原型開發工作。具體細節可以看我這篇公眾號文章： ofollow,noindex">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裡維護下面的程式碼：
Line"/>
第17行聲明瞭進行前後臺通訊的Web Socket url：
這樣消費者的開發也做完了。
大家在實際工作中，遇到繁瑣耗時的體力活的時候，也可以多想想，能不能用工具來減少工作量，提高工作效率。感謝閱讀。
本文作者：Wang Jerry