一个15年ABAP老兵的建议：了解这些基础知识，对ABAP开发有百利而无一害

在笔者之前的文章里，曾经提到了 SAP社区上这样一篇博客：Proof of Concept: Deploying ABAP in Kubernetes

里面介绍了SAP Linux实验室的工程师们将ABAP应用服务器各组件进行容器化并部署到Kubernetes上的尝试。

本文简单回顾ABAP Netweaver应用服务器的主要组件。虽然即使不了解这些知识，也不影响ABAP开发人员完成日常工作，但是很多ABAP编程的最佳实践都和这些知识有着千丝万缕的联系，知其然知其所以然，能帮助大家写出更健壮更高效的ABAP应用。

什么是ABAP Netweaver应用服务器？

SAP Netweaver应用服务器是SAP ABAP应用开发和运行平台，ABAP开发人员在上面可以专注于具体业务逻辑的开发，凡涉及到更底层的基础设施相关任务，比如请求的负载均衡，进程的派生，同步和调度，内存管理，服务器多实例间缓存同步等等，统统交由Netweaver平台本身处理。如此一来，一个ABAP开发人员，即使不具备精深的计算机组成原理，操作系统，计算机网络等领域知识，也能胜任SAP应用的开发工作。

ABAP Netweaver应用服务器和SAP解决方案的关系？

随便点开一张查看：

SAP客户位于图中最上面的展现层(Presentation Layer)，通过SAP GUI这个客户端软件或者浏览器访问SAP系统；

部分ABAP开发人员觉得，我们既然能够直接在ABAP Netweaver里用OPEN SQL对数据库表进行读写操作，那么Netweaver应用服务器本身就包含了数据库层。这样理解其实不正确。我们在Netweaver SE38里编写的OPEN SQL代码，会通过Netweaver内部的数据库接口，转换成数据库提供商相关的原生SQL语句在数据库里执行，并且从最底层的数据库层，到应用层里的ABAP程序之间的数据传输，也是通过数据库接口完成的。

本文讨论的ABAP Netweaver服务器的组成部分，位于三层架构中的应用层。

ABAP Netweaver服务器实例

运行在物理机器上的ABAP应用服务器，按照其用途的不同，又可分为两种实例：应用服务器实例和ABAP SAP中央服务实例(ABAP SAP Central Services instances, 缩写为ASCS instances), 也就是下图两个灰色矩形框代表的实例。

下面是对这些组件的简要介绍。

Internet Communication Manager (ICM)

ICM是Netweaver服务器里一个单独的进程，由ABAP Dispatcher启动并监控，负责SAP系统和外部的网络通信。基于收到请求URL的解析，ICM会将请求分发给具体的handler进行处理。

• Thread Control：该线程负责接收外界请求，从ICM线程池中取出空闲的工作线程，将请求的上下文交给工作线程。
• 工作线程：负责请求的具体处理，包含一个I/O处理器，可以用来进行网络的输入和输出操作。对于不同协议类型的请求，Thread Control会调度包含了对应协议插件的工作线程。
• Watchdog：如果一个工作线程在任务处理时出现了等待某个响应直至超时的情况，Watchdog会将该工作线程释放，避免其无限期的等待，这样该工作线程可以服务于其他请求。而Watchdog会继续等待尚未到来的响应。其后如果响应到达，Watchdog会通知Thread control, 后者会继续调用新的工作线程来处理。
• Signal Handler：处理来自操作系统或者其他进程的信号。
• Connection Info: 这张表维护了每个连接的状态信息，包括内存管道等。
• Memory Pipes：内存管道是基于内存的通讯数据结构，用于将ICM接收到的外部请求包含的数据转交给工作线程。
• Internet Server Cache：服务器端的缓存，对于重复的请求可以加快响应速度。

ABAP Dispatcher和工作进程

二者的关系在下图体现得很清晰，ABAP应用服务器上运行着许多工作进程(Work Process)，这些进程类型各异，负责处理各种类型不同的请求。

事务码SM50里能看到当前应用服务器上的工作进程明细，比如下图显示用于处理用户普通事务请求的对话(Dialog)进程有30个，其中29个空闲；Update进程负责执行数据库的更新操作；Background进程处理后台作业，Spool负责打印任务。而ABAP里数据库更新的操作有V1和V2两种级别(平时大家用的默认都是V1级别），分别由下图的Update和Update Task2两种类型的工作进程完成。

Gateway

这里的Gateway和SAP Fiori里的Gateway系统是两码事，后者指代安装了SAP_GWFND这个Software Component的ABAP应用服务器，而我们现在即将讨论的Gateway，是ABAP应用服务器里的一个组件。

SAP系统之间，以及SAP系统与外部系统间通过基于TCP/IP的RFC(Remote Function Call，远程系统调用)进行通信，而Gateway作为RFC调用分发的入口，如下图所示：

值得一提的是，我们能够在SAP标准程序里看到CALL FUNCTION ‘XXX’ DESTINATION ‘NONE’的写法，这种写法使得函数XXX仍然在调用它的应用服务器实例内部执行，而非在其他服务器上远程执行。那么这种写法不是多此一举吗？

SAP官网对这种用法的解释：Destination “NONE” has the effect that the function module is started on the same application server as the calling program, however through the RFC interface and in its own RFC context.

也就是说，通过这种方式调用的函数，即便是和调用者同处一个应用服务器实例内，也会像远程调用执行时一样，到RFC接口即Gateway组件里去走一遭。

付出这种在额外协议栈上执行开销的代价，有什么收益？那得从ABAP Netweaver里不同类型的会话说起。我们每用SAP GUI登录一次系统，会在服务器上生成一个用户会话(User Session). 每个User Session里通过命令行输入/o可以生成新的ABAP会话，每个ABAP会话内的程序调用生成新的内部会话(Internal Session).

SAP Start Service

该服务运行在部署了SAP应用服务器实例的服务器上，实现载体是Windows的系统服务(sapstartsrv.exe)和Unix系统的Daemon进程(sapstartsrv).

Enqueue Server

数据库层面的锁由数据库管理，而ABAP应用程序级别的锁，比如锁一个订单，锁一个物料主数据，则通过应用程序提出锁申请，由Enqueue Server完成和管理锁。应用服务器实例上所有用户当前会话持有的锁，都维护在Enqueue服务器的锁信息管理表中，该表维护在Enqueue服务器的内存中，不会进行持久化，因此Enqueue服务器成为了ABAP系统的单点故障源之一：当Enqueue服务器由于各种原因运行时发生故障需要重启时，维护在内存中的锁信息表的数据会丢失。

因此为了确保Enqueue服务器的高可用性，通常将其放到单独的物理主机上部署，甚至引入遵循主从机制的多台Enqueue服务器，将Master Enqueue服务器上的锁信息管理表同步到其他Enqueue服务器上。

事务码SM12查看某个用户持有的应用锁：

SE11里打开任意一个锁对象，点击Lock Modules，进入自动生成的ABAP函数内部，就可以了解锁请求是如何从应用服务器发送到Enqueue服务器的。

SAP Message Server

上图我登录的AG3系统有多个应用服务器实例，我登录的实例编号为54，使用事务码SM53发现这个系统还有另外两个实例，编号为55和56.

忽视SAP系统可以由多个应用服务器实例组成这一点，有时候可能会遇到一些无法按照自己期望工作的场景.比如数据库性能测量工具ST05，如果在实例A上打开跟踪，而业务代码实际执行在实例B上，那么待分析性能的应用执行完毕后，在实例A上关闭跟踪后，当然看不到性能数据。这种情况下，最保险的做法就是，在激活跟踪时，选择“在所有实例上”打开跟踪开关。

总结

本文详细介绍了 ABAP 服务器的各大组成部分和其职责所在。了解这些底层系统知识，有助于 ABAP 开发人员写出更健壮的 ABAP 应用，同时工作过程中遇到相关问题，也能更加明确从哪些方向入手进行问题的分析和定位。