文章封面

从 SE37 到 HTTP 地址：一步步定位 SAP 自定义接口的测试入口

拿到一个 ABAP 函数名，以及 SE37 中保存好的测试数据，能不能直接写出它的 HTTP 测试地址？这次排查的关键，是沿着系统配置和活动源码，把业务函数与对外服务之间的调用关系逐段接起来。

本文将一次实际定位过程整理成可复用的方法。企业名称、系统标识、客户端、主机、端口、自定义对象和业务数据均已匿名化。文中的地址与对象名为替换后的示例，不能用于访问原环境；正文保留 6 张现场 SAP GUI 截图，敏感区域采用不透明色块遮挡；遮挡之外的截图内容保持原样。另附概念封面和调用链示意图。

一、先明确 SE37 给了我们哪些信息

起点是 SE37 的“测试数据目录”。这里保存了业务函数的测试参数，但测试目录本身没有提供 HTTP 服务入口。

在 SAP GUI 中核对当前系统与客户端，避免把开发环境的配置用于测试环境。
在 SE37 确认目标函数，本文记为 ZDEMO_CHECK。
打开单独测试和测试数据目录，选择编号为 1 的记录，查看实际参数。
记录业务类型、参数结构和需要验证的场景。

这里能确定的是“哪个业务函数、哪组测试参数”。要得到 HTTP 地址，还需要继续找到服务路径、处理器、路由编号、HTTP 方法，以及接收 JSON 的包装函数。

函数名称与 HTTP 路径之间没有可以直接套用的命名公式。

SE37 业务函数测试结果页，敏感信息已遮挡

图 1：原始 SE37 测试结果页，保留参数结构与页面布局。函数名、运行时间、消息标识及底部环境信息已遮挡；此图不代表 HTTP 调用结果。

二、从项目文档取得地址线索

这次定位先查阅了已有接口说明，寻找“测试环境 URL”“接口地址”“HTTP”等内容。文档中存在一个通用入口的历史调用示例，因此得到了三个线索：主机与端口、ICF 服务路径，以及名为 IFID 的路由参数。

历史示例对应的是另一项业务，不能把它的路由编号直接用于目标函数。正确做法是把它当作导航线索，再回 SAP 核对当前配置。

如果没有接口文档，可以从目标函数的调用位置、相关包装函数或已知处理器继续追踪。本文采用的是“已有文档给出通用入口，再由配置确认业务映射”的路径。

三、在 SICF 确认服务路径和激活状态

有了服务名称线索后，进入 SICF，筛选对应服务，展开服务树，并以显示方式查看属性。

本文将服务层级匿名化为：

default_host
  └─ sap
      └─ bc
          └─ rest
              └─ z_demo_api

这一阶段核对两件事：目标服务是否存在，以及服务是否处于激活状态。

default_host 是 SICF 中的虚拟主机节点，在本例中不写进 HTTP 路径。对应的示例路径为：

/sap/bc/rest/z_demo_api

SICF 服务属性，敏感信息已遮挡

图 2：SICF 服务属性原图。自定义服务名称及底部环境信息已遮挡，路径层级和激活状态保留。页面标题为“创建/更改服务”，本次定位仅查看，未修改或保存配置。

不要只看服务描述就认定找到了目标业务。同一个通用服务可能承接多个接口，具体执行哪项业务，还要看处理器怎样分发请求。

四、沿处理器找到真正的路由规则

在 SICF 服务属性的“处理器清单”中，找到已配置的 ABAP 类，本文记为 ZCL_DEMO_HTTP_HANDLER。

SICF 处理器清单，敏感信息已遮挡

图 3：SICF 处理器清单原图。保留处理器配置位置，服务名称、处理器类名及底部环境信息已遮挡；正文统一使用匿名示例类名。

随后使用 SE24 显示该类，定位 IF_HTTP_EXTENSION~HANDLE_REQUEST 方法，查看活动源码。此次排查发现，处理器同时读取接口编号和 HTTP 方法，再查询一张自定义路由表。

下面是匿名化、简化后的关键逻辑，用于解释查找过程，省略了声明、响应设置和异常处理，不能作为完整程序直接使用：

lv_ifid = server->request->get_form_field( name = 'IFID' ).
lv_method = server->request->get_header_field(
  name = '~request_method' ).

SELECT SINGLE * INTO ls_route
  FROM zdemo_api_route
  WHERE interface_id = lv_ifid
    AND http_method = lv_method.

这段代码解释了为什么“地址看起来正确”仍可能找不到接口：路由匹配条件包含 IFID 和 HTTP 方法，二者必须与配置一致。

处理器还检查启用标志。在满足条件后，它读取 HTTP 正文，将 JSON 字符串传给路由中配置的函数，再接收返回的 JSON 字符串。也就是说，这个项目使用了一个通用入口，由配置决定具体调用哪个包装函数。

这里的路由表、字段名和分发方式属于项目自定义设计，不是所有 SAP 接口都采用的固定机制。

五、查路由配置，确认编号、方法和包装函数

既然活动源码已经指出路由表，下一步就可以使用 SE16N 做只读查询。

输入源码中实际使用的自定义路由表。
根据目标业务或相关函数名缩小查询范围。
核对候选记录的业务说明，避免选中相似接口。
记录接口编号、HTTP 方法、函数名和启用状态。

匿名化后的示例记录如下，字段名称也经过了替换：

配置项	示例值	用来确定什么
INTERFACE_ID	DEMO001	URL 中 IFID 的取值
HTTP_METHOD	PUT	请求方法
FUNCNAME	ZDEMO_CHECK_JSON	接收 JSON 的包装函数
ACTIVE	X	路由启用标志
DESCRIPTION	示例业务校验	是否对应目标业务

自定义路由配置，敏感信息已遮挡

图 4：路由查询原图。表名、接口编号、外部系统、函数名称、业务说明及底部环境信息已遮挡，保留 PUT 方法、启用标志和表格对应关系；正文表格中的名称为替换示例。

这张记录把接口编号、方法和包装函数连在了一起。它也说明，HTTP 入口首先调用的是 ZDEMO_CHECK_JSON，还需要继续确认它与 ZDEMO_CHECK 的关系。

六、回到 SE37，确认 JSON 与业务参数的转换

在 SE37 以显示方式打开包装函数，查看活动源码。此次定位中，包装函数完成三个步骤：反序列化请求、调用业务函数、序列化业务结果。

IV_JSON：HTTP 请求正文
  ↓ JSON 反序列化
ABAP 输入结构
  ↓ 作为 IS_DATA 传入
ZDEMO_CHECK
  ↓ 返回 ES_OUTDATA
ABAP 输出结构
  ↓ JSON 序列化
EV_JSON：返回给处理器

JSON 包装函数源码，敏感信息已遮挡

图 5：包装函数活动源码原图。自定义函数与结构名称已遮挡，JSON 反序列化、业务调用参数及响应序列化逻辑保留。

请求正文应该如何组织，要依据反序列化目标结构及其嵌套关系判断，不能把 SE37 的形参名称直接当作 JSON 外层节点。

在这次排查的结构中，正文顶层对应 DATA，无需额外套一层 IS_DATA。这个结论来自具体结构和包装源码，换一个接口仍需重新核对。

同时要区分两个位置：URL 中的 IFID 用于处理器选路；正文中的接口标识字段属于业务数据。两者是否关联，由实现决定。不能因为保存的业务抬头字段为空，就把 URL 的路由编号也留空。

匿名接口调用链示意图

图：依据已核对调用关系重绘的匿名示意图，省略异常分支，不代表现场界面。

七、用 SMICM 核对当前监听服务

到这里，服务路径和业务路由已经有了依据，主机与端口仍需核对。此次定位使用 SMICM，进入“服务”显示页面，查看协议、主机、端口和活动状态，并与文档线索交叉确认。

SMICM 监听服务，主机与端口已遮挡

图 6：SMICM 服务列表原图。全部主机及端口值、底部环境信息已遮挡，保留协议、服务行和活动状态。正文 URL 中的主机与端口均为虚构示例。

需要关注的是与目标协议匹配的服务行，不能随意取列表第一行，也不能仅凭系统编号推算端口。

ICM 监听信息能说明应用服务器侧的服务情况。如果调用方经过 Web Dispatcher、反向代理或其他入口，调用方使用的主机、协议和端口还应与该入口配置核对，不能把内部监听地址直接当成对外地址。

八、把各项证据组装成测试入口

为了便于复查，可以把地址拆成几个部分，分别记录来源：

组成部分	核对来源
协议、主机和端口	SMICM；存在代理时同时核对代理入口
服务路径	SICF 服务树和服务属性
客户端参数	目标测试环境和服务登录配置
IFID	处理器源码及路由记录
HTTP 方法	处理器匹配规则及路由记录
请求正文结构	JSON 包装函数和 ABAP 输入结构

使用全文统一的虚构值，可以写出下面的请求入口示例。主机、端口、客户端、路径和编号均为匿名替换值，不代表可连接的测试系统：

PUT http://sap-test.example.com:8080/sap/bc/rest/z_demo_api?sap-client=100&IFID=DEMO001
Content-Type: application/json

这个结果并不是从函数名猜出来的。服务路径来自 SICF，分发条件来自处理器源码，编号与方法来自路由配置，业务对应关系来自包装函数，监听信息来自运行配置。

九、把“地址定位”与“调用验证”分开记录

完成配置追踪之后，仍要准确描述验证范围。

验证内容	能说明什么	仍不能说明什么
服务、源码和路由核对	找到了指向目标业务的配置链路	调用方网络、认证和 HTTP 请求已经成功
SE37 业务函数执行	某组输入在当时数据下的业务结果	JSON 转换、HTTP 状态和原始响应已经验证
实际 HTTP 调用	特定请求的传输和应用返回情况	所有业务场景均已通过

原始排查曾在取得授权后执行一次 SE37 测试，但没有通过 HTTP 重放请求。因此，准确表述应是“已定位测试入口，并取得 SE37 业务返回”，不能写成“HTTP 接口联调成功”。公开稿不包含原始业务参数、结果明细和运行时间。

后续如需联调，应在授权范围内记录实际请求方法、完整正文、HTTP 状态、原始响应以及业务返回标识。GUI 显示值与 HTTP 原始序列化结果也应分别留存，避免把物料号等字段的显示格式直接当作传输格式。

完成这套追踪后，每项结论都能回到具体配置页或活动源码：先确认业务函数，再找到服务和处理器，沿路由进入包装函数，最后核对监听入口。这样整理出来的测试地址，才能被其他人逐项复查。