SAP ABAP调用HTTP接口：Token鉴权、缓存与自动重试

1. 先聊清楚这件事到底在解决什么问题10 月 24 日那天我在工位上收尾一个接口对接的需求同事在群里发了一句1024 节日快乐了鸭顺手给我丢过来一个需求单SAP 里要定时把物料主数据推给外部的一个业务中台对方只提供 HTTP 接口而且必须先拿 token 才能调业务方法。这其实是现在做 ABAP 集成最常见的一类活儿难度不算高但坑是真的多尤其是 token 这一层——拿不到、过期了、传错了、中文乱码了每一个都能让你在 SM59 和 SLG1 之间来回横跳半天。这篇就围绕SAP ABAP 调用 HTTP 接口并用 token 登录这个场景把我实际做下来的完整思路、代码、踩过的坑一次讲透。它解决的问题很具体SAP 内部数据要跟外部系统交互而外部系统用的是现在主流的 token 鉴权不是简单的用户名密码 Basic 认证。适合的读者是已经会一点 ABAP、能看懂 Function Module 和类方法但没怎么做过 HTTP 外部集成的同学如果你已经做过几轮 REST 接口对接这篇里的缓存和续签部分应该也能给你一点参考。先给一个小结论方便你建立整体印象整件事拆开只有四步——拿 token、存 token、带 token 调接口、token 快过期时换新的。听起来像废话但真正写起来80% 的调试时间会花在第一步和第三步的细节上。下面我按为什么这么设计到具体怎么敲代码的顺序展开每一段我都会解释清楚背后的取舍理由而不是只丢一段代码给你抄。需要提前说明的是本文涉及的接口地址、密钥都是示意值实际项目里请替换成你自己环境的配置并且绝对不要把真实的 client_secret 硬编码进代码——这一点后面会专门讲怎么规避。2. 技术路线选型为什么是 IF_HTTP_CLIENT 而不是别的在 SAP 里做外部 HTTP 调用其实不止一条路。我见过不少同事一上来就想着用 RFC 或者把对方的接口包装成 Web Service但很多时候对方只给一个 REST 风格的 HTTP 地址加一个 JSON body你根本没有选择余地。所以在动手之前我习惯先把可选路线过一遍确认自己选的是最省事的那条。2.1 常见的三条集成路线对比路线适用场景优点明显短板IF_HTTP_CLIENT原生 HTTP 客户端对方只提供 REST/HTTP 接口、JSON 交互灵活任何 HTTP 方法都能发头部随便改需要自己处理 JSON、错误码、token生成 Web Service 代理类SE80 企业服务对方提供标准 WSDL调用像本地方法参数强类型对方给不出 WSDL 就废了token 也不好塞RFC / 中间件转发老系统对接SAP 之间通信稳定、性能好外部系统基本不支持需要额外部署中间层我这次选的毫无疑问是第一条。理由是对方接口是标准的POST /oauth/token拿令牌、POST /api/v1/material推数据的 REST 风格返回体是 JSON没有 WSDL 可生成也没有中间件可用。而且 token 认证本质上就是往 HTTP header 里塞一个Authorization字段只有原生 HTTP 客户端能让我完全控制头部。这里有个反直觉的点值得说很多人以为CL_REST_HTTP_CLIENT是更现代的写法实际上它是给 REST 服务端开发用的辅助类做纯客户端调用时IF_HTTP_CLIENT配合CL_HTTP_CLIENTCREATE_BY_DESTINATION才是更通用、资料更多、出问题更好查的选择。我踩过一次用 REST 客户端类做外部调用的坑SSL 配置死活读不到 SM59 里的证书最后还是换回 IF_HTTP_CLIENT 才通的。2.2 token 模式到底比 Basic 认证强在哪顺带说一下为什么现在大家都用 token。Basic 认证是把用户名密码 Base64 一下塞进每个请求头等于你的密码在网络上反复出现任何一个环节被抓包就泄露了。token 模式则是先用凭证换一张有时效的通行证后续请求只带这张通行证。通行证过期就失效就算被截获攻击窗口也只有几分钟到几小时。对 ABAP 开发者来说这个设计带来的直接影响是你的程序必须有能力判断 token 是否还有效并且能在它失效前主动换新。如果你只是每次调用都重新申请一遍 token功能上没问题但对方接口通常有限流高频申请会被直接拒掉而且平白多了一倍的网络往返。这就是为什么后面一定要做缓存。2.3 两种 token 获取方式的差异常见的 token 获取方式主要有两种选错方向会让后面所有代码都要返工所以这里单独拎出来说client_credentials客户端凭证模式用固定的 client_id 和 client_secret 换 token不涉及具体用户。适合系统对系统的数据同步也就是我这次的场景。password 模式用某个真实用户的账号密码换 tokentoken 代表这个用户的权限。适合要按用户权限操作、需要记录操作人的场景。我这次用的是第一种因为物料推送是系统行为不该绑定任何一个员工账号——万一那个人离职账号被锁接口直接就挂了。这个判断在做需求评审的时候就要定下来不要等到联调时才发现对方只支持 password 模式而你没有可用的测试账号。3. 动手前必须搞定的环境和概念代码写得再漂亮SM59 目标配错一个勾选你也会得到各种莫名其妙的报错。这部分我把它单独拎出来是因为它真的值得花时间先弄明白。3.1 SM59 目标配置的关键几项在 SM59 里新建一个类型为G - HTTP 连接到外部服务器的目标比如叫ZAPI_MATERIAL。填写的时候有几个地方是新手最容易翻车的主机名和端口注意 HTTPS 默认 443不要把https://前缀写进主机名里主机名只填域名。路径前缀如果你的接口都有统一的/api/v1前缀可以填在这里代码里就只需要写后半段方便以后统一改。SSL 相关如果对方是 HTTPS必须在这里激活 SSL并且选择正确的证书列表。这一步不做你会在send的时候收到http_communication_failure而且错误信息非常含糊。我实测下来SSL 报错是最难查的一类因为 IF_HTTP_CLIENT 抛出的异常只有一句话看不出是证书问题还是网络问题。我的经验是先在 SM59 里用连接测试按钮测一次如果能通说明配置没问题问题一定在代码如果连接测试就失败那别改代码了先解决证书和网络。3.2 用字符串类型还是用 XSTRING 传数据ABAP 里 HTTP 报文有两个载体set_cdata处理字符串set_data处理二进制XSTRING。这次的接口是 JSON看起来应该用字符串但有个前提——你必须确认对方和你的系统都是 UTF-8。我们系统里有中文物料描述第一次联调的时候对方收到的全是问号。原因是我用set_cdata传了一个内部编码的字符串SAP 在发送时做了默认转换。后来改成先用CL_ABAP_CONV_OUT_CE把内容转成 UTF-8 的 XSTRING再用set_data发出去中文就正常了。这个细节在英文环境里永远暴露不出来但只要有中文就必修。3.3 token 放在哪里传token 的携带方式有好几种对方接口文档里一定会写清楚但如果你拿不到文档可以从常见实践里猜一猜携带位置典型写法出现频率请求头 Authorization BearerAuthorization: Bearer token最高主流 REST 接口请求头自定义字段X-Auth-Token: token常见于国内一些中台URL 查询参数?access_tokentoken少数老接口不推荐注意token 一定不要放在 URL 里传。URL 会被记进各种服务器访问日志、浏览器历史和监控系统等于把通行证打印出来贴在墙上。如果对方文档要求放 URL能沟通就沟通改成 header。4. 完整实操从拿 token 到推数据前面铺垫够了下面是真正落地的部分。我把整个流程拆成一个可复用的工具类大概两百来行能覆盖大部分场景。4.1 封装一个发送请求的核心方法所有 HTTP 交互都走同一个底层方法这样超时、错误处理、日志都只需要维护一份。下面是我实际用的简化版METHOD send_request. iv_method: GET / POST / PUT / DELETE iv_path : 相对路径如 /oauth/token iv_body : 请求体字符串可为空 it_headers: 附加请求头KV 结构 返回响应状态码和响应体 DATA: lo_client TYPE REF TO if_http_client, lv_url TYPE string. 通过 SM59 目标创建客户端证书和主机信息都从这里读 cl_http_clientcreate_by_destination( EXPORTING destination ZAPI_MATERIAL IMPORTING client lo_client EXCEPTIONS argument_not_found 1 destination_not_found 2 destination_no_authority 3 plugin_not_active 4 internal_error 5 OTHERS 6 ). IF sy-subrc 0. RAISE EXCEPTION TYPE zcx_api_error EXPORTING textid zcx_api_errorclient_create_failed. ENDIF. 设置超时单位秒不设的话默认等待可能长达几百秒 lo_client-propertytype_logon_popup lo_client-co_disabled. cl_http_utilityset_request_uri( request lo_client-request uri iv_path ). lo_client-request-set_method( iv_method ). lo_client-request-set_content_type( application/json; charsetutf-8 ). lo_client-request-set_header_field( name Accept value application/json ). 逐个塞入调用方传进来的头部 LOOP AT it_headers ASSIGNING FIELD-SYMBOL(ls_hdr). lo_client-request-set_header_field( name ls_hdr-name value ls_hdr-value ). ENDLOOP. 请求体统一转成 UTF-8 的 XSTRING避免中文乱码 IF iv_body IS NOT INITIAL. DATA(lv_xbody) cl_abap_conv_out_ceuccp( iv_body ). lo_client-request-set_data( lv_xbody ). ENDIF. lo_client-send( EXCEPTIONS http_communication_failure 1 http_invalid_state 2 http_processing_failed 3 OTHERS 4 ). IF sy-subrc 0. lo_client-get_last_error( IMPORTING message DATA(lv_err) ). RAISE EXCEPTION TYPE zcx_api_error EXPORTING textid zcx_api_errorsend_failed msg lv_err. ENDIF. lo_client-receive( EXCEPTIONS http_communication_failure 1 http_invalid_state 2 http_processing_failed 3 OTHERS 4 ). IF sy-subrc 0. lo_client-get_last_error( IMPORTING message lv_err ). RAISE EXCEPTION TYPE zcx_api_error EXPORTING textid zcx_api_errorreceive_failed msg lv_err. ENDIF. ev_status lo_client-response-get_status_code( ). ev_body lo_client-response-get_cdata( ). lo_client-close( ). ENDMETHOD.这段代码里有几个地方是刻意这么写的值得解释一下。第一create_by_destination而不是create。用目标名创建的好处是所有连接参数集中在 SM59改地址、换证书不用动代码而且传输到生产环境时 SM59 配置走的也是传输机制安全可控。第二propertytype_logon_popup设成 disabled。如果不设在某些配置下系统会弹出一个登录对话框问你要账号密码这个框在后台任务里会直接把程序卡死。定时任务场景下这个设置是必须的。第三cl_abap_conv_out_ceuccp负责把内部编码转成 UTF-8。这里要注意方向是输出转换别用错成输入的那个类。第四close( )一定要调。IF_HTTP_CLIENT 底层会占用连接资源不关的话在循环里会越积越多最后报http_invalid_state。我见过一个哥们儿在一个批量推送报表里忘了关闭推到第 40 条就报错查了两小时才找到原因。4.2 获取 token 并解析出来有了底层方法拿 token 就变成一个很短的函数METHOD get_token. 命中缓存直接返回避免重复申请 IF mt_token IS NOT INITIAL AND sy-datum mv_valid_date. ev_token mv_token. RETURN. ENDIF. 构造请求体凭证从配置表读取绝不硬编码 DATA(lv_body) |\{| |grant_type:client_credentials,| |client_id:{ mv_client_id },| |client_secret:{ mv_client_secret }| |\}|. DATA: lt_headers TYPE ztt_headers. APPEND VALUE #( name Content-Type value application/json ) TO lt_headers. send_request( EXPORTING iv_method POST iv_path /oauth/token iv_body lv_body it_headers lt_headers IMPORTING ev_status DATA(lv_status) ev_body DATA(lv_resp) ). IF lv_status 200. RAISE EXCEPTION TYPE zcx_api_error EXPORTING textid zcx_api_errortoken_failed msg |HTTP { lv_status } : { lv_resp }|. ENDIF. 用标准 JSON 工具反序列化 TYPES: BEGIN OF ty_token, access_token TYPE string, token_type TYPE string, expires_in TYPE i, END OF ty_token. DATA ls_token TYPE ty_token. /ui2/cl_jsondeserialize( EXPORTING json lv_resp pretty_name /ui2/cl_jsonpretty_mode-camel_case CHANGING data ls_token ). IF ls_token-access_token IS INITIAL. RAISE EXCEPTION TYPE zcx_api_error EXPORTING textid zcx_api_errortoken_empty. ENDIF. 写入缓存留出 60 秒的安全余量 mv_token ls_token-access_token. mv_valid_date sy-datum. mv_valid_time sy-uzeit ls_token-expires_in - 60. ev_token mv_token. ENDMETHOD.pretty_mode-camel_case这个参数是必须的因为对方的 JSON 用的是下划线命名access_token而 ABAP 的约定是下划线。如果不指定反序列化会匹配不上你会得到一堆空值然后对着正确的响应报文怀疑人生。关于缓存我这里用的是实例属性加上有效期简单但够用。它的局限是只在单次程序运行期间有效如果你的推送是分成好几个独立作业跑的每个作业还是会各申请一次 token。要跨会话共享就得把 token 存到数据库表里加上过期时间字段读的时候比较一下sy-datum和sy-uzeit。这个方案我一般只在对方限流特别严或者接口调用特别频繁时才会上因为它引入了一个新的维护点——表数据脏了会导致所有人都拿不到 token反而更难排查。4.3 带 token 调用业务接口真正推数据的时候只需要把拿到的 token 拼进 Authorization 头DATA(lv_token) get_token( ). DATA: lt_headers TYPE ztt_headers. APPEND VALUE #( name Authorization value |Bearer { lv_token }| ) TO lt_headers. 业务报文这里假设是物料主数据 DATA(lv_payload) /ui2/cl_jsonserialize( data ls_material pretty_name /ui2/cl_jsonpretty_mode-camel_case ). send_request( EXPORTING iv_method POST iv_path /api/v1/material iv_body lv_payload it_headers lt_headers IMPORTING ev_status DATA(lv_status) ev_body DATA(lv_resp) ).4.4 token 失效时的自动重试即使做了缓存还是有可能会撞上 token 在两次检查之间失效的情况比如对方提前作废了令牌。稳妥的做法是当业务接口返回 401 时强制清掉缓存并重新申请一次然后重试一次请求。注意只重试一次避免无限循环。IF lv_status 401. clear_token_cache( ). 清空缓存的 token lv_token get_token( ). 重新申请 更新头部后重试一次 MODIFY lt_headers FROM VALUE #( name Authorization value |Bearer { lv_token }| ) TRANSPORTING value WHERE name Authorization. send_request( ... ). 仅重试一次 ENDIF.这个模式几乎能兜住所有 token 类问题。我实际跑下来正常情况下一天也就多申请一两次 token对方限流完全不受影响。5. 踩过的坑和排查速查表这部分是我觉得最有价值的内容因为文档里通常不会写。5.1 常见报错对照表现象大概率原因处理方式send 抛 http_communication_failureSSL 证书、网络不通、主机名写错先在 SM59 做连接测试HTTP 401token 无效或已过期清缓存重取检查是否带对了头部HTTP 403权限不足或 token 拿错了 scope核对 client_id 对应的权限范围中文变问号编码转换缺失用 CL_ABAP_CONV_OUT_CE 转 UTF-8返回体是乱码 XSTRING用了 get_data 而不是 get_cdata确认编码后再转字符串循环几次后 http_invalid_state忘记 close( )每次请求后必须关闭后台作业卡死弹窗没禁用 logon_popup设置 propertytype_logon_popup disabled5.2 一些只有真做过才知道的细节关于超时。SAP 默认的 HTTP 等待时间非常长对方如果挂着不响应你的后台作业会一直等下去。虽然在这个高层接口里设置超时不太直观但至少要在 SM59 目标里调整超时时间这一项一般设 30 到 60 秒比较合理。批量推送时如果一条卡住整个链条都会延误这个值必须重视。关于 JSON 里的日期。/ui2/cl_json反序列化日期和时间时会做格式转换如果对方传的是2025-10-24T10:30:00这种带 T 的格式直接映射到 DATS/TIMS 字段会失败。稳妥做法是先用 string 接住再用自己的转换逻辑处理别指望自动转换。关于调试。看响应内容最直接的方式是在receive之后打个断点把lo_client-response-get_cdata( )加到监视器里看。如果你觉得每次都要改代码太麻烦可以写一个小的 Z 报表传入目标名和路径把响应原样打印出来联调阶段能省很多时间。关于日志。生产环境出问题时我当时手头的日志只有状态码完全看不出对方返回了什么。后来我在工具类里加了一处把请求路径、状态码、响应体前 500 个字符写进一张自定义日志表。这个动作在出故障时救命——有一次对方说没收到我们的数据我调出日志表一看明明是对方返回了 500责任一目了然。提示写日志时注意不要把 token 和 client_secret 记进去。我见过有人图方便把整个请求头打印出来等于把密钥写进了数据库审计过不了。6. 生产上线的几点加固建议6.1 凭证管理不要图省事client_secret 最忌讳直接写在代码里。代码会进版本库、会被传输、会被打印任何一个环节都可能泄露。我推荐的做法是建一张简单的配置表存放接口地址、client_id、client_secret通过 SM30 维护表本身设置成只有特定权限组才能查看。更好的做法是把 secret 存到安全存储里通过接口读取但对大多数项目来说配置表加权限控制已经够了。还有一点如果你们的系统有多个环境开发、测试、生产每个环境的 client_secret 通常是不一样的别偷懒用同一套否则测试环境的密钥泄露会直接影响生产。6.2 幂等和重复推送网络超时是最恶心的场景——你的请求发出去对方收到了但响应回来的路上断掉了你的程序认为失败于是重试对方就收到了两条重复数据。如果你的业务接口不是幂等的重试就可能造成重复过账。实操上的做法有几种一是在报文里带一个唯一请求号让对方按这个号去重二是发现超时后不要立刻重试而是先调用一个查询接口确认上次是否成功三是控制重试次数并且加上退避比如第一次等 2 秒、第二次等 8 秒。我一般优先用第一种前提是对方愿意配合。6.3 后台作业的分批策略如果是批量推送几千条物料不要放在一个作业里一路推到底。我习惯每 200 条提交一次、失败的分开记录这样即使中途网络抖动也只是丢一批而不是整个作业报错回滚。提交的时候注意用COMMIT WORK配合WAIT UP TO 1 SECONDS给对方接口留一点喘息避免被限流。7. 我个人的一些实际体会这个需求从接到到上线我前后花了大概三天其中写代码只用了半天剩下两天半全在调证书和验证 token 的各种边界情况。所以如果你也要做类似的活我的建议是把联调时间往多了估。第一别怕在 SM59 上多花时间。连接测试能通后面 90% 的诡异问题都跟你无关了。第二token 缓存和自动重试这两件事看着是优化实际上是刚需跳过它们你的程序在上线第一周就会出问题。第三日志和密钥隔离这种加分项在出故障的时候会变成必须项。最后分享一个小技巧联调阶段可以申请让对方提供一个测试用的长效 token专门用来验证业务逻辑不用每次都被 token 获取环节干扰。等业务跑通了再把获取 token 的逻辑接上。这样排查问题时能快速定位到底是鉴权层还是业务层出了问题比眉毛胡子一把抓高效得多。至于那个 1024 的梗——程序员的节日送自己一个能跑通的接口我觉得比什么礼物都实在。