怎么理解C語言和ABAP

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

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

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

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

用命令行g(shù)cc ./study.c --verbose進行編譯，參數(shù)verbose可供我們查看編譯明細。上述命令行在我的Ubuntu系統(tǒng)上產(chǎn)生一串長長的輸出：

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

gcc -E study.c -o study.i

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

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

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

用命令行g(shù)cc -S可以查看study.c編譯后生成的匯編代碼：

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

工作十多年后，Jerry不得不承認，當(dāng)時本科開設(shè)的計算機專業(yè)課，像數(shù)據(jù)結(jié)構(gòu)，操作系統(tǒng)，計算機組成原理，編譯原理，匯編程序設(shè)計，計算機圖形學(xué)這些都是有用的，工作后，公司不可能再給你時間去學(xué)習(xí)這些基礎(chǔ)理論知識了。

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

下面我們來聊聊ABAP。

SAP note 1230076 ”Generation of ABAP loads: Tips for the analysis” 介紹了一個工具程序：RSDEPEND。這個note提到，一個即便看起來最簡單的ABAP Hello World報表，其實也依賴于許多標準的Repository對象，這些依賴我們假定稱其為A,B,C。假設(shè)A,B,C其中有任何一個有改動產(chǎn)生，比如A是一個include程序，里面使用到了一個DDIC結(jié)構(gòu)，在某個時刻，系統(tǒng)導(dǎo)入了一個傳輸請求(Transport Request), 里面包含了針對這個DDIC結(jié)構(gòu)的更改，那么此時這個最簡單的Hello World報表的load就成為了obsolete狀態(tài)。在重新執(zhí)行該報表之前，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對象的二進制表現(xiàn)形式，針對ABAP環(huán)境的快速訪問而做過特別優(yōu)化，可以存儲在數(shù)據(jù)庫表中或者加載于內(nèi)存里。

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

創(chuàng)建一張非常簡單的透明表ZLOADTEST：

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

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

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

這兩個字段存儲的內(nèi)容就是前面ABAP help提到的ABAP load在數(shù)據(jù)庫表中的存儲形式。

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

Goto->System Areas->Internal Information:

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

然后執(zhí)行前面提到的工具報表RSDEPEND, 輸入?yún)?shù)program name = ZTESTLOAD, 得到結(jié)果，其中測試報表的ABAP Load時間戳為07:21:02, 這個報表依賴的標準Include有：

• <REPINI>

• <SYSINI>

• <SYSSEL>

• DB__SSEL

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

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

下面我們再做幾輪測試。

測試1

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

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

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

測試2

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

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

再次執(zhí)行ZTESTLOAD后，這次發(fā)現(xiàn)它的ABAP Load已經(jīng)被自動invalidate了，時間戳從07:21:02變成了07:36:02。

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

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

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