怎么理解C語言和ABAP

本篇內容介紹了“怎么理解C語言和ABAP”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

比如像下圖這種用kernel module修飾的sc_km_check_feature_2, 以及每一個ABAP關鍵字，其C語言的實現代碼在SAP內部的Netweaver系統可以查看到，但是在客戶系統上，則是以二進制目標文件的形式存儲，無法查看源代碼。

本文的目的是希望通過C語言和ABAP編譯過程的一些介紹，加深ABAP顧問們對這門語言的理解。

用C語言寫個Hello World程序，另存為study.c:

用命令行gcc ./study.c --verbose進行編譯，參數verbose可供我們查看編譯明細。上述命令行在我的Ubuntu系統上產生一串長長的輸出：

我們可以一步步分析。首先用參數 -E查看預處理生成的目標文件study.i:

gcc -E study.c -o study.i

可以看到源代碼文件只有78字節，編譯預處理后生成的輸出文件有17116字節。

為什么膨脹了這么多？原因是因為我源代碼文件的第一行，#include<stdio.h>被預處理器替換成了stdio.h的實際內容，而stdio.h里如果又存在#include其他文件的聲明，這個替換過程會遞歸執行。因此直到study.i的末尾部分，我們才能看到在study.c里書寫的源代碼部分。

源代碼文件study.c里的第一行語句 #include<stdio.h>, 請大家記住，后面講ABAP還會提到。

用命令行gcc -S可以查看study.c編譯后生成的匯編代碼：

看到這些pushq, popq, %rbp，Jerry不由得想起本科匯編程序設計專業課上，我和寢室其他兄弟坐在教室最后一排看體壇周報的時光。

工作十多年后，Jerry不得不承認，當時本科開設的計算機專業課，像數據結構，操作系統，計算機組成原理，編譯原理，匯編程序設計，計算機圖形學這些都是有用的，工作后，公司不可能再給你時間去學習這些基礎理論知識了。

雖然匯編程序設計這門課Jerry當初沒有好好學，但至少教材我是妥善保存了的，以防哪天公司的工作安排需要讓我把十多年前在學校學的東西重新又撿起來。

下面我們來聊聊ABAP。

SAP note 1230076 ”Generation of ABAP loads: Tips for the analysis” 介紹了一個工具程序：RSDEPEND。這個note提到，一個即便看起來最簡單的ABAP Hello World報表，其實也依賴于許多標準的Repository對象，這些依賴我們假定稱其為A,B,C。假設A,B,C其中有任何一個有改動產生，比如A是一個include程序，里面使用到了一個DDIC結構，在某個時刻，系統導入了一個傳輸請求(Transport Request), 里面包含了針對這個DDIC結構的更改，那么此時這個最簡單的Hello World報表的load就成為了obsolete狀態。在重新執行該報表之前，ABAP Runtime(中文譯成ABAP運行時)會自動做一個load invalidation操作，生成一個最新版本的load。

什么是ABAP load？看ABAP help里的官方定義：

“In the ABAP environment, a load describes a binary representation of a repository object which is optimized for fast access, in the memory or on the database.”

翻譯成中文：ABAP load是Repository對象的二進制表現形式，針對ABAP環境的快速訪問而做過特別優化，可以存儲在數據庫表中或者加載于內存里。

我們用一個實際的例子來理解ABAP報表激活和運行時發生的事情。

創建一張非常簡單的透明表ZLOADTEST：

寫一個簡單的報表，命名為ZTESTLOAD。報表的源代碼以壓縮的格式存儲在表REPOSRC的DATA字段里。

測試報表的源代碼很簡單，把表里的數據全部讀取出來：

激活這個簡單的報表(是的，在ABAP世界里，我們習慣說激活，而不是編譯）。激活后生成的ABAP load存儲在表REPOLOAD的字段LDATA和QDATA里。

這兩個字段存儲的內容就是前面ABAP help提到的ABAP load在數據庫表中的存儲形式。

菜單Goto->Navigate to->Switch to Classic Debugger:

Goto->System Areas->Internal Information:

在System Area區域輸入CONT，就能在下圖的NAME列看到ABAP load里包含的指令。當然同開源的JVM不同，JVM字節碼指令集在網上能夠查到，而這些ABAP load的指令是SAP internal的，因此不能在這里做解釋。

然后執行前面提到的工具報表RSDEPEND, 輸入參數program name = ZTESTLOAD, 得到結果，其中測試報表的ABAP Load時間戳為07:21:02, 這個報表依賴的標準Include有：

• <REPINI>

• <SYSINI>

• <SYSSEL>

• DB__SSEL

由此看出，每一個標準的ABAP報表都自動包含了這些include。如果開發人員顯式地再包含其中任意一個，會遇到語法錯誤: Module %_PF_STATUS is already defined as a OUTPUT module.

大家覺得這個<REPINI>是不是很像前文C語言部分提到的#include<stdio.h>？

下面我們再做幾輪測試。

測試1

修改透明表的描述信息，然后重新激活透明表。

執行RSDEPEND, 可以看到只有透明表的Last Changed字段發生了變化，ABAP Time Stamp和Screen Time Stamp都不變，這是我們期望的結果，因為我們只是修改了透明表的描述信息，并未修改結構。

再次執行測試報表ZTESTLOAD, 用RSDEPEND檢測，發現測試報表的ABAP Load時間戳沒有發生變化，這說明：即使依賴的透明表的描述信息發生變化，使用了該透明表的ABAP報表不需要重新編譯，因為透明表描述信息不需要在報表執行期使用。

測試2

給透明表增加新的一列，再次激活。

此時通過RSDEPEND發現，透明表的三個時間戳全部發生了變化，如下圖藍色矩形框所示。然而測試報表ABAP Load本身的時間戳仍然未變，這也是合理的，因為我們給透明表里增加了新的列后，還未執行測試報表。

再次執行ZTESTLOAD后，這次發現它的ABAP Load已經被自動invalidate了，時間戳從07:21:02變成了07:36:02。

這也解釋了一個現象：有的朋友們觀察到，當系統剛升完級后，或者有一批新的傳輸請求導入到系統后，第一次使用SAP應用時，系統響應速度很慢。原因其實通過前文的兩個測試已經說明了：系統在花費時間去做相關ABAP Load invalidation。在應用依賴的這些Load invalidation沒有結束之前，系統無法響應用戶請求。

為了避免用戶在第一次使用應用時長時間等待，可以使用事務碼SGEN預先進行Load invalidation。

“怎么理解C語言和ABAP”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！