ABAP 740從2013年發(fā)布至今已經過去很長的時間了，下面這張圖來自SAP社區(qū)博客：

ABAP News for Release 7.40 – What is ABAP 7.40?

圖中的ABAP 8.0, 即現(xiàn)在的SAP Cloud for Customer和Business By Design后臺使用的ABAP版本NGAP - Next Generation ABAP Platform，里面存在不少只在8.0版本可用的關鍵字和語言特性。

因為C4C和BYD的ABAP后臺，客戶和partners們是無法訪問的，所以咱們回到ABAP 740這個版本。從該版本開始，ABAP支持了很多新的關鍵字和語法特性，“看起來有點不像傳統(tǒng)的ABAP編程語言了”。

本文咱們就來看一個具體的例子：ABAP 740里的一個新關鍵字REDUCE. 這個關鍵字的作用和在大規(guī)模數(shù)據(jù)集并行計算領域里廣泛使用的"Map-Reduce"編程模型中的Reduce操作類似，可以按照字面意思理解為“歸約”。

下圖是Map Reduce框架的工作步驟，統(tǒng)計一個海量輸入數(shù)據(jù)集(比如大于1TB)中的單詞出現(xiàn)次數(shù)。作為ABAP開發(fā)人員，我們沒必要了解Map Reduce框架的每個執(zhí)行步驟，只需緊盯框架的輸入，以及執(zhí)行結果就行了。

回到Jerry接受的實際工作任務。德國同事讓Jerry在某個CRM測試系統(tǒng)上做個統(tǒng)計，列出在數(shù)據(jù)庫表CRM_JSTO里，OBTYP(Object Type)和STSMA(Status Schema)這兩列擁有相同值的內表行的個數(shù)。大家可以把"OBTYP和STSMA兩列具有相同值的內表行"類比成上圖中重復出現(xiàn)的單詞。

下圖是CRM_JSTO的部分行：

下圖是Jerry完成的任務: 測試系統(tǒng)上內表一共有55多萬行，其中有90279行，只維護了OBTYP為TGP，而沒有維護STSMA. 排名第二的是COH和CRMLEAD的組合，出現(xiàn)了78722次。

稍稍做過一些ABAP開發(fā)的朋友們，一定會立即寫出下面的代碼：

利用SELECT COUNT直接在數(shù)據(jù)庫層完成統(tǒng)計工作。這也是SAP推薦的做法，所謂Code pusudown準則，即能放到HANA數(shù)據(jù)庫層面進行的操作，就盡量放進去，以充分利用HANA強大的計算能力。在數(shù)據(jù)庫能夠完成計算邏輯的前提下，盡量避免把計算邏輯放到Netweaver ABAP應用層去做。

不過，我們也需要注意到這種方式的局限性。Jerry之前曾經引用過SAP CTO的名言：

• There is no future with ABAP alone
• There is no future in SAP without ABAP

未來的ABAP會走向開放，互聯(lián)的道路。回到這個需求本身，假設待檢索的輸入數(shù)據(jù)不是從ABAP數(shù)據(jù)庫表中來，而是來自HTTP請求，或者第三方系統(tǒng)發(fā)過來的IDOC，此時我們無法再使用OPEN SQL本身的SELECT COUNT操作，而只能在ABAP應用層解決這個問題。

所謂技多不壓身，Jerry這里介紹兩種用ABAP完成這個需求的方式。

第一種方式比較傳統(tǒng)，實現(xiàn)在方法get_result_traditional_way里：

ABAP的LOOP AT GROUP BY這個關鍵字組合簡直就像是為這個需求量身定做一般：給GROUP BY指定obtyp和stsma這兩列，然后LOOP AT會自動將輸入內表的行記錄根據(jù)這兩列的值進行分組，每組行記錄的個數(shù)通過關鍵字GROUP SIZE自動計算出來，每組各自的obtyp和stsma的值，以及組內行記錄的條目數(shù)，存儲在REFERENCE INTO指定的變量group_ref里。ABAP顧問需要做的事情，只是簡單地把這些結果存儲到輸出內表即可。

第二種辦法，就是本文標題所述，使用ABAP 740新的REDUCE關鍵字：

上面的代碼乍一看可能覺得有點晦澀，但仔細閱讀后發(fā)現(xiàn)這種方式本質上也采用了和方法一LOOP AT GROUP BY同樣的分組策略——根據(jù)obtyp和stsma分組，這些子組通過變量<group_key>標識，然后通過第10行的REDUCE關鍵字，通過累加的方式，手動計算這個組的條目數(shù)——把一個大的輸入集根據(jù)GROUP BY指定的條件歸約成一個個規(guī)模更小的子集，然后分別針對子集進行計算——這就是REDUCE關鍵字通過字面含義傳遞給ABAP開發(fā)人員的處理思想。

總結和比較一下這三種實現(xiàn)方式：當待統(tǒng)計的數(shù)據(jù)源為ABAP數(shù)據(jù)庫表時，一定優(yōu)先選用OPEN SQL的方式，使計算邏輯在數(shù)據(jù)庫層完成，以獲得最佳的性能。

當數(shù)據(jù)源并非ABAP數(shù)據(jù)庫表，而分組統(tǒng)計的需求為簡單的計數(shù)操作(COUNT)時, 優(yōu)先用LOOP AT … GROUP BY … GROUP SIZE，使得計數(shù)操作通過GROUP SIZE在ABAP kernel完成，以獲得較好的性能。

當數(shù)據(jù)源并非ABAP數(shù)據(jù)庫表，而分組統(tǒng)計的需求為自定義的邏輯時，用本文介紹的第三種REDUCE解法，將自定義統(tǒng)計邏輯寫在第11行的NEXT關鍵字后。

這三種解法的性能依次遞減，不過適用的場合和靈活程度依次遞增。

LOOP AT … GROUP BY … GROUP SIZE，在Jerry的服務器上處理55萬條記錄，用了0.3秒，而REDUCE則需花費0.8秒。

本文提到的所有ABAP代碼均可從我的SAP博客獲得：

A real case to use REDUCE to finish a task in daily work

感謝閱讀。
要獲取更多Jerry的原創(chuàng)文章，請關注公眾號"汪子熙":

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結

以上是生活随笔為你收集整理的利用ABAP 740的新关键字REDUCE完成一个实际工作任务的全部內容，希望文章能夠幫你解決所遇到的問題。

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