TIOBE 2022年3月的编程语言排行榜显示:
https://www.tiobe.com/tiobe-index/
C 语言和 C++ 分别名列第二和第四位:

而 ABAP 编程语言名列第 42 位:

为什么这篇文章要把 C 语言和 ABAP 放在一起讲,而不是别的编程语言比如 Java 和ABAP 呢?因为 ABAP 语言底层是基于 C/C++ 实现的,包括其关键字(比如最简单的关键字 WRITE 的 C++ 实现有 2 千多行)和虚拟机(ABAP Runtime).
SAP 内部的一群计算机科学家们发明了 ABAP 这门在企业管理软件影响极其深远的编程语言,由它实现的各种 SAP 应用帮助了全球超过 180 个国家和地区的客户们更好地运行其业务。
通过 Google 我们能搜索到一些关于这些 SAP 计算机科学家们的介绍,比如这个链接。

比如像下图这种用 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 编译后生成的汇编代码:

下面我们来聊聊 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 有:


由此看出,每一个标准的 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/C++ 与 ABAP 有着不同的语法和各自的应用场景,然而 ABAP Kernel 和 ABAP 运行时都是基于 C/C++ 实现,因此使用 ABAP 编写的程序随处可见 C/C++ 的影子,比如 ABAP 里的 Field Symbol 和 Reference,同 C 语言里的指针用法高度相似。本文从 C 语言一个 Hello World 程序的编译过程出发,分享了 ABAP 编程语言一些基于 C/C++ 实现的技术细节。感谢阅读。
网友评论