今天的故事要從ABAP小遊戲提及。git
中國的ABAP從業者們手頭或多或少都蒐集了一些ABAP小遊戲,好比下面這些。github
消滅星星:算法
掃雷:編程
來自個人朋友劉夢,公衆號"SAP乾貨鋪"裏的俄羅斯方塊:windows
用ABAP畫圖:瀏覽器
以及用今天要談到的ABAP Channel技術開發的乒乓球遊戲,還能支持雙打,囧。架構
我內心一直有個念頭,以嚴謹刻板著稱的德國開發人員,看到這些流行於中國ABAP生態圈的小遊戲,會有什麼反應?app
去年我在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
不少SAP成都研究院作過CRM開發的同事都和Henning打過交道,這是一位在CRM領域業務知識極其精深,同時很是和善的德國人。
在SAP社區網站上已經有不少SAP從業者發表了各類關於ABAP Channel的博客,包括SAP自身也開發了不少例子,這些例子程序跟隨Netweaver一塊兒發佈。
Jerry再也不重複這些例子,感興趣的朋友請參考這篇文章:
今天我要分享的是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
(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上,這裏僅闡述要點。
在靜態構造函數裏,將第二步建立的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:
這樣消費者的開發也作完了。
你們在實際工做中,遇到繁瑣耗時的體力活的時候,也能夠多想一想,能不能用工具來減小工做量,提升工做效率。感謝閱讀。
更多閱讀
要獲取更多Jerry的原創文章,請關注公衆號"汪子熙":