简介面向Linux环境下使用Python调用SAP RFC接口的开发者这份资源包提供nwrfcsdk特定版本nwrfc750P_5-70002752含C库、头文件、动态库及示例程序解决pyrfc安装前手动编译和配置SDK的问题。包内共27个文件以h/c源码文件、so动态库、cpp示例、txt说明及ini配置文件为主压缩包整体18.05MB可直接用于Linux环境下的SDK部署与Python连接调试。通过nwrfcsdk与pyrfc读者可掌握设置LD_LIBRARY_PATH和sapnwrfc.ini、调用RFC函数、读取表数据及触发业务逻辑的方法并理解SNC加密通信的注意事项。已有1384人学习下载适合企业级SAP集成、自动化运维及接口开发人员快速搭建开发环境。 做一个基于Linux的Python调用SAP RFC接口的工程很多人第一反应是“装个pyrfc不就行了”但真动手才发现pyrfc只是最上面那一层它底下压着一整套SAP NW RFC SDK的安装、环境变量、编译链接、权限配置的流程。这篇文章就围绕linux、python、pyrfc、SAP、nwrfc sdk这几个关键词把我完整跑通这套链路的经历、踩过的坑、以及生产环境里的实际配置写下来。无论你是在自己的电脑上实验还是在服务器上做数据集成按这个流程走基本能把从零到第一个RFC调用打通的时间压缩到半天以内。先说一下我为什么会走上这条路。项目背景是有一批SAP主数据和业务单据需要被外部系统定时读取服务器是CentOS技术栈以Python为主。最初试过直接用SAP提供的RFC SDK写C封装效果虽然直接但维护成本太高也评估过社区里的一些轻量封装库大多停留在Python 2时代作者更新不积极。最后落到了SAP官方维护的PyRFC方案上——它是用Cython对NW RFC SDK的C接口做绑定既能用Python开发又能吃到SDK底层的稳定性。折腾一轮下来把经验整理成下面这些内容。1. 为什么最终选定了“pyrfc nwrfc sdk”这条路1.1 需求背景与三条备选路线的对比接到的需求很朴素Linux服务器上跑一个Python服务定时从SAP里读取物料、BOM、销售订单的增量数据偶尔还要调BAPI创建或修改单据。这个场景下面我当时对比过三条路线直接用C语言写RFC调用封装SAP NW RFC SDK的原生接口。这条路灵活性最大但代价也很明显要自己处理内存分配、结构体映射、错误码转换一个小功能可能要写几百行C代码后续加接口还要重新编译工程成本太高。找社区第三方库比如某些自动生成的RFC绑定包。优点是上手快缺点是不少库只支持老版本OpenSAP或Python 2对RFC协议的新特性支持滞后生产环境不敢依赖这种“人气驱动”的维护节奏。使用SAP官方PyRFC配合NW RFC SDK。PyRFC把底层C接口做成了接近Python风格的调用方式上层代码简洁底层协议能力又完整。最终选第三条路不是因为它最华丽而是因为它在“省事”和“可靠”之间达到了平衡。SAP官方维护意味着后续SDK升级、新增功能绑定都不会断档这是一个生产系统选型时非常重要的考量。1.2 pyrfc和nwrfc sdk到底是什么关系很多新手第一次看到这套组合会很懵pyrfc里明明写了import为什么还要单独装一个SDK打个比方PyRFC像一个翻译而NW RFC SDK是电话线路。电话线路负责把声音传输到远方翻译负责把语言转成双方都能理解的内容。两者缺一不可。具体到代码层面PyRFC只负责Python对象和C数据结构的转换、调用约束、错误异常处理真正通过网络和SAP网关建立连接、执行RFC函数、传递数据包全部由SDK里的动态库比如libsapnwrfc.so完成。如果你只pip install了pyrfc没有正确安装SDKimport可以成功但一创建Connection就会报RFC_LIBRARY_NOT_FOUND。1.3 这套方案最适合什么场景从我这边的实际使用来看pyrfc nwrfc sdk最适合这些情况数据集成定时从SAP抽取物料主数据、库存、财务凭证同步到数据仓库或业务中台。自动化操作通过BAPI批量创建订单、修改状态、触发单据审批。报表输出把RFC函数返回的表数据直接转为DataFrame做分析。不适合的场景也有比如你想在ABAP端做复杂业务逻辑、和SAP GUI深度联动调试那还是老老实实去SE37/SE80里开发没必要绕到外部系统。2. 从下载nwrfcsdk到设置环境变量每一步都别急着跳2.1 SDK从哪下载、怎么解压NW RFC SDK不是PyPI上的包也不是随便找个镜像就能拿到的它需要登录SAP Software Download Center用SAP S-user账号下载。我这边环境是x86_64的Linux选择的就是“SAP NW RFC SDK 7.50 for Linux on x86_64”这个包。下载下来是一个tgz压缩包文件名类似nwrfc750P_x86_64_xxxxx.tgz。解压时我习惯把SDK放到独立的目录方便后续做版本管理mkdir -p /opt/nwrfcsdk tar -xzf nwrfc750P_x86_64_xxxxx.tgz -C /opt/nwrfcsdk解压后的目录结构大致是/opt/nwrfcsdk ├── include # RFC头文件编译时要用 ├── lib # libsapnwrfc.so及依赖库 ├── bin # 少量工具脚本 └── doc # 官方文档和示例重点是lib目录下的libsapnwrfc.sopyrfc运行时要加载的就是它。如果你是从rpm包安装SDK系统可能自动写入了ldconfig配置但tgz方式解压就得手动设置环境变量。2.2 环境变量配置SAPNWRFC_HOME和LD_LIBRARY_PATHSDK解压完要设置两个环境变量。SAPNWRFC_HOME是给编译环节用的告诉构建脚本去哪找头文件和库LD_LIBRARY_PATH是给运行时用的让系统能找到动态库。export SAPNWRFC_HOME/opt/nwrfcsdk export LD_LIBRARY_PATH/opt/nwrfcsdk/lib:$LD_LIBRARY_PATH这个配置建议写进系统级文件避免每次打开终端都手动source。我一般放在/etc/profile.d/sapnwrfc.sh里cat /etc/profile.d/sapnwrfc.sh EOF export SAPNWRFC_HOME/opt/nwrfcsdk export LD_LIBRARY_PATH/opt/nwrfcsdk/lib:$LD_LIBRARY_PATH EOF这里有个容易踩的细节LD_LIBRARY_PATH只在当前shell环境里有效如果你是通过systemd服务运行Python脚本需要在service文件里单独EnvironmentLD_LIBRARY_PATH...否则系统服务加载不到库。我最初在systemd里跑定时任务时就被这个坑过。2.3 用ldd检查SDK依赖是否完整SDK本身也有自己的依赖如果系统里缺了某个基础库后期调用时会报出各种奇怪的错误。最简单的方法是用ldd检查ldd /opt/nwrfcsdk/lib/libsapnwrfc.so正常情况下会输出一系列libc.so.6 /lib64/libc.so.6这样的映射如果哪一行出现“not found”说明系统缺少对应的运行库。我碰到过一台比较精简的容器镜像缺失了libgcc_s.so.1安装gcc运行时库之后才解决。位数一致性也很重要如果系统是64位必须下载64位的SDK。用file命令确认file /opt/nwrfcsdk/lib/libsapnwrfc.so输出里应该有64-bit如果显示32-bit后面加载时必然报错。3. 安装pyrfc为什么“pip install pyrfc”会失败3.1 版本分水岭2.x和3.x的安装差异很多教程还在说“pip install pyrfc”一条命令搞定那基本是pyrfc 2.x时代的故事。从pyrfc 3.0开始官方不再为所有平台提供预编译wheel源码包仍然发布在PyPI上但直接装的话会触发本地编译编译过程中又依赖SDK和Cython。如果环境里刚好没有这些你会看到一堆gcc报错。所以如果你用的是Python 3.6以上版本我建议直接走源码构建路线别和pip默认行为较劲。pyrfc 3.x对应的就是Python 3的现代版本我这边用Python 3.8/3.10都编译通过过。3.2 编译前需要准备哪些依赖为了保证编译过程顺利先把这些装上yum install -y gcc python3-devel # CentOS/RHEL # 或者 apt install -y gcc python3-dev # Debian/Ubuntupython3-devel/python3-dev这个包容易漏。pyrfc编译时要引用Python.h没有开发头文件会直接报fatal error。然后安装构建工具pip install cython setuptools wheelCython是必须的因为pyrfc本体就是用Cython写的。3.3 拉源码、设置SDK环境、安装确认SDK环境变量已经export好之后进入项目目录构建git clone https://github.com/SAP/PyRFC.git cd PyRFC python setup.py build python setup.py install如果刚才的环境变量没生效也可以显式指定export SAPNWRFC_HOME/opt/nwrfcsdk python setup.py build --sapnwrfc/opt/nwrfcsdk python setup.py install官方仓库里还提供了一个pyrfc-build脚本封装了构建逻辑想省事可以这样python pyrfc-build --sapnwrfc/opt/nwrfcsdk构建过程一般一两分钟结束。安装完成后验证是能否importfrom pyrfc import Connection print(Connection)如果这一步正常输出class pyrfc.cyrfc.Connection说明pyrfc本体已经OK。如果报ImportError: libsapnwrfc.so: cannot open shared object file那基本还是LD_LIBRARY_PATH的问题回到上一章检查。3.4 项目里的SDK路径固化做法每次开终端都要export环境变量太麻烦我更推荐把SDK的路径写死在项目的启动脚本里。比如项目根目录的run.sh#!/bin/bash export SAPNWRFC_HOME/opt/nwrfcsdk export LD_LIBRARY_PATH/opt/nwrfcsdk/lib:$LD_LIBRARY_PATH exec python3 main.py注意不要在Python内部用os.environ[LD_LIBRARY_PATH]...来补救因为动态库的加载时机在进程启动早期Python运行时已经加载完依赖了运行时改环境变量往往来不及。必须确保进程启动前LD_LIBRARY_PATH就正确。4. 第一个真实调用连接参数、RFC函数调用与返回解析4.1 连接参数拆解环境就绪后连接SAP就简单了。最基础的方式是直接指定应用服务器参数from pyrfc import Connection conn Connection( userRFC_USER, passwdyour_password, ashost192.168.100.10, sysnr00, client100, langEN ) print(连接状态:, conn.alive) conn.close()这里我把最常用的参数整理成了一张表方便你按需取值参数名含义典型值备注ashostSAP应用服务器IP或主机名192.168.100.10也可以填SAProuter地址sysnrSAP系统编号00 / 01两位字符串client客户端100 / 200三位字符串userRFC用户名RFC_USER必须来自SAP用户主记录passwd用户密码由SAP管理员设置注意密码中特殊字符转义lang登录语言EN / ZH语言包要和系统配置一致mshost消息服务器地址sapmshost使用负载均衡/消息服务器时填r3name系统IDPRD / QAS搭配消息服务器使用group服务器组PUBLIC负载均衡的分组名如果你的SAP环境启用了负载均衡也可以不指定具体应用服务器改用mshost r3name group的组合这样连接请求由消息服务器自动分发。两种方式对应标准SAP GUI连接选项里的“Application Server”和“Load Balancing”两种模式。4.2 第一个RFC_PING连通性测试用RFC_PING最稳什么都不用传result conn.call(RFC_PING) print(RFC_PING完成:, result)如果没报错说明连接、权限、路由三层全部正常。这个函数通常没有任何返回参数所以结果是空字典这是正常的。4.3 调用一个带结构输出的BAPI连通性验证过了再上一个业务函数。以读取用户信息为例result conn.call(BAPI_USER_GET_DETAIL, USERNAMEDEMO) print(result)pyrfc会把RFC的structure转成Python dict把table转成list[dict]。所以result里通常包含{ RETURN: [{TYPE: S, MESSAGE: ...}], ADDRESS: {FULLNAME: Demo User, EMAIL: demoexample.com}, COMPANY: {...}, LOGONDATA: {...} }这个嵌套结构在取数时非常直观。比如logon_data result[LOGONDATA] print(最后登录时间:, logon_data.get(LSTAMP)) print(密码状态:, logon_data.get(PWDSET))对于业务表参数的传入比如按条件查询某段物料通常是在函数参数里直接传list[dict]result conn.call( BAPI_MATERIAL_GETLIST, MAXROWS100, MATERIAL_RANGE[{SIGN: I, OPTION: BT, LOW: M100, HIGH: M200}] )注意表参数的每个元素必须带SIGN和OPTION字段这是SAP选择表的标准格式写错过一次报RFC_INVALID_PARAMETER排查小半天才意识到少配了条件字段。4.4 数据类型转换和编码问题SAP的DATE类型在RFC协议里本质是字符串格式固定为YYYYMMDD。比如2024年5月1日要传成20240501。如果你在Python侧直接传datetime.date对象pyrfc 3.x部分版本能自动转换但我不建议依赖这个行为统一转成字符串最保险。关于编码连接参数里langZH时返回的中文字符串Python侧是正常的str类型但整个调用链的Linux系统locale最好设置为支持UTF-8export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8否则某些极端情况下会出现UnicodeDecodeError尤其是在SAP返回的备注字段里带有特殊字符时。5. 实测中遇到最多的报错与排查思路这一章我会按“现象、排查链路、最终修复”的方式写目的是让你在遇到问题时能顺着思路自己定位而不是只能靠搜索引擎碰运气。5.1 RFC_LIBRARY_NOT_FOUND先查库再查环境变量现象conn Connection(...) # pyrfc.SAPError: RFC_LIBRARY_NOT_FOUND这是王炸级的常见错误。很多人的第一反应是pyrfc没装好其实问题大多出在SDK那边。我建议按下面的顺序排查。第一步确认SDK确实存在且路径正确ls -l /opt/nwrfcsdk/lib/libsapnwrfc.so第二步确认LD_LIBRARY_PATH已经包含SDK的lib目录echo $LD_LIBRARY_PATH第三步用ldd验证SDK本身能不能在系统里找到所有依赖ldd /opt/nwrfcsdk/lib/libsapnwrfc.so第四步如果前三步全正常怀疑是编译时用旧SDK缓存的残留重新编译一次pyrfccd PyRFC python setup.py clean --all python setup.py build python setup.py install我遇到过一次特别隐蔽的情况系统里同时装了多个版本的SDK/usr/lib和/opt/nwrfcsdk/lib各有一份旧库LD_LIBRARY_PATH的手动配置没盖过系统默认路径导致加载了另一个不完整的库。最终把不需要的旧SDK清理掉才彻底解决。5.2 RFC_FUNCTION_NOT_FOUND先问SAP侧现象result conn.call(Z_MY_CUSTOM_FN) # pyrfc.SAPError: RFC_FUNCTION_NOT_FOUND排查这个错误时重点先在SAP系统侧确认几点该函数是否在系统中存在SE37里敲一下函数名看能不能找到。该函数是否允许远程调用SE37里“属性”页签的“处理类型”必须勾选“远程启用的模块”也就是Remote-Enabled Module。普通函数不能直接从RFC调用。用户是否有权限执行该函数SAP权限对象S_RFC会控制用户能调用哪些函数组权限不够会报RFC_AUTHORIZATION_FAILURE但如果权限对象配置比较碎也可能表现为找不到函数。我这边有一个项目就是因为SAP侧启用了严格的RFC白名单用户虽然能登录SAP GUI但外部调用新函数时全被拦在RFC授权之外最后调用方报的就是FUNCTION_NOT_FOUND。这类问题从Python侧怎么调都白搭必须让BASIS配置S_RFC授权。5.3 RFC_INVALID_PARAMETER类型和结构别想当然现象result conn.call(BAPI_XXXX, MATERIALM100) # pyrfc.SAPError: RFC_INVALID_PARAMETER排查关键点是搞清楚SAP函数接口里每个参数到底是IMPORTING、CHANGING还是TABLE参数以及参数的嵌套结构。直接用SE37查看函数文档最简单。常见问题有该参数不是简单的字符串而是一个structure代码里却传了string。TABLE参数里的每一行包含多个字段但Python侧只给了一个dict且缺少部分字段。选择表参数少了SIGN/OPTION字段。参数类型是NUMC或DEC传了整数或浮点但pyrfc对某些DEC类型要求字符串。一个比较稳妥的做法是先用SE37找到函数看“导入/导出/表参数”页签里的字段描述照着字段名构造Python字典。不要凭猜测去写参数名SAP的参数名经常和业务直觉不一致。5.4 连接超时或SAP端连接数打满现象调用频率变高之后出现Connection reset by peer、RFC_SYSTEM_FAILURE或者反复Unable to get connection。排查思路分两层应用层是否反复创建新连接、用完没有close导致SAP端占用大量对话进程。检查代码里连接对象是否被正确关闭或者使用连接池复用。网络层是否有防火墙或中间设备限制了长时间空闲连接。如果每次调用间隔很长连接会被中间设备断开客户端不知道继续用旧连接就会失败。我这边常用“断线重试”机制兜底查询类接口失败后重新建立连接再试一次效果很明显。5.5 locale导致的编码报错现象中文返回乱码或直接抛UnicodeDecodeError但同样的代码在Windows上正常。排查重点看Linux的locale配置locale如果输出是LANGC或LANGPOSIX程序默认用ASCII处理字节流遇到中文就会炸。解决办法是安装中文字符集并设置环境变量。localedef -i zh_CN -f UTF-8 zh_CN.UTF-8 export LANGzh_CN.UTF-8如果系统里没法安装zh_CN退而求其次用en_US.UTF-8也能让Python正确处理UTF-8编码。6. 文档没写透的几个生产环境经验6.1 连接复用与连接池RFC连接在SAP侧会占用ABAP会话资源每次新建连接都涉及SAP登录、授权检查、工作进程分配开销不小。频繁创建销毁连接不仅慢还可能被SAP侧限流。生产环境一定要做连接复用。一个简单的做法是用queue做连接池from queue import Queue from pyrfc import Connection class SAPPool: def __init__(self, size5, **conn_params): self.params conn_params self.pool Queue(maxsizesize) for _ in range(size): self.pool.put(Connection(**self.params)) def acquire(self): return self.pool.get() def release(self, conn): self.pool.put(conn) pool SAPPool(size3, userRFC_USER, passwdpassword, ashost..., sysnr00, client100) conn pool.acquire() try: result conn.call(RFC_PING) finally: pool.release(conn)池大小按并发数评估一般3到5个就够。要注意连接池里的连接如果长期空闲被SAP端断开使用前建议先检查conn.alive或者捕获异常后重建连接。6.2 大结果集分批处理有些RFC函数返回的数据量很大比如一次读取几万条日志或明细。直接把整个表拉到内存不仅慢SAP侧也可能因为导出内存超限报错。处理方式是尽量使用函数自带的分页参数比如行数上限MAXROWS和游标。示例里可以设定每次取2000行循环拉取直到数据取完。result conn.call(BAPI_MATERIAL_GETLIST, MAXROWS2000, ...)如果函数本身不分页可以考虑在传入条件里用日期、物料号区间缩小范围多次调用再拼接。6.3 写操作接口的重试要格外小心查询类接口重试没问题但BAPI里做创建、修改、审批这类写操作时重试可能导致重复下单或重复记账。我这边写操作调用失败后不会自动重试而是把请求参数和错误信息写入log表交给人工或补偿流程处理。这个经验是实打实踩坑换来的之前某个同步程序在BAPI调用超时后自动重试结果SAP里产生了重复的销售订单后面手工对冲花了半天。6.4 容器化部署时别漏了SDK如果你把服务打包成Docker镜像SDK不会自动跟随Python镜像。Dockerfile里要显式把SDK拷贝进去并设置环境变量FROM python:3.10-slim COPY nwrfc /opt/nwrfcsdk ENV SAPNWRFC_HOME/opt/nwrfcsdk ENV LD_LIBRARY_PATH/opt/nwrfcsdk/lib:$LD_LIBRARY_PATH RUN pip install cython setuptools wheel \ git clone https://github.com/SAP/PyRFC.git /tmp/PyRFC \ cd /tmp/PyRFC python setup.py install COPY app /app WORKDIR /app CMD [python, main.py]注意基础镜像尽量选带完整glibc的不要用alpine的musl版本SDK的动态库对glibc有依赖alpine下会遇到莫名其妙的加载问题。我当时为了镜像大小把基础镜像从debian换到alpine结果ldd一片not found最后又换回slim系列才稳定。6.5 日志记录时的脱敏问题RFC调用的出入参里往往包含业务敏感信息比如客户名称、价格、用户口令等。生产环境的日志建议只记录调用函数名、传入的关键筛选条件、耗时、返回码不要直接打印整个请求和响应字典。如果确实需要调试加上开关控制默认关闭。6.6 最后一个小技巧先用RFC_PING做健康检查集成到监控系统时可以用RFC_PING做SAP连接健康检查比直接调用业务函数成本低得多也不会对SAP业务产生副作用。定时任务启动前先做一次健康检查如果失败给报警系统发一条消息能提前规避大批量任务同时失败的情况。整套做下来Linux Python pyrfc NW RFC SDK的链路虽然初始搭建有些门槛但一旦把SDK环境问题处理完后面写业务逻辑的效率非常高。尤其是不用碰C语言就能稳定调用SAP的RFC和BAPI对数据团队来说省了太多事。如果你也正在做类似的事建议先把SDK环境、环境变量、pyrfc编译这三件事理顺再开始写业务代码顺序反了会排查到怀疑人生。本文还有配套的精品资源点击获取
Linux下Python调用SAP RFC：pyrfc与NW RFC SDK完整实践指南
简介面向Linux环境下使用Python调用SAP RFC接口的开发者这份资源包提供nwrfcsdk特定版本nwrfc750P_5-70002752含C库、头文件、动态库及示例程序解决pyrfc安装前手动编译和配置SDK的问题。包内共27个文件以h/c源码文件、so动态库、cpp示例、txt说明及ini配置文件为主压缩包整体18.05MB可直接用于Linux环境下的SDK部署与Python连接调试。通过nwrfcsdk与pyrfc读者可掌握设置LD_LIBRARY_PATH和sapnwrfc.ini、调用RFC函数、读取表数据及触发业务逻辑的方法并理解SNC加密通信的注意事项。已有1384人学习下载适合企业级SAP集成、自动化运维及接口开发人员快速搭建开发环境。 做一个基于Linux的Python调用SAP RFC接口的工程很多人第一反应是“装个pyrfc不就行了”但真动手才发现pyrfc只是最上面那一层它底下压着一整套SAP NW RFC SDK的安装、环境变量、编译链接、权限配置的流程。这篇文章就围绕linux、python、pyrfc、SAP、nwrfc sdk这几个关键词把我完整跑通这套链路的经历、踩过的坑、以及生产环境里的实际配置写下来。无论你是在自己的电脑上实验还是在服务器上做数据集成按这个流程走基本能把从零到第一个RFC调用打通的时间压缩到半天以内。先说一下我为什么会走上这条路。项目背景是有一批SAP主数据和业务单据需要被外部系统定时读取服务器是CentOS技术栈以Python为主。最初试过直接用SAP提供的RFC SDK写C封装效果虽然直接但维护成本太高也评估过社区里的一些轻量封装库大多停留在Python 2时代作者更新不积极。最后落到了SAP官方维护的PyRFC方案上——它是用Cython对NW RFC SDK的C接口做绑定既能用Python开发又能吃到SDK底层的稳定性。折腾一轮下来把经验整理成下面这些内容。1. 为什么最终选定了“pyrfc nwrfc sdk”这条路1.1 需求背景与三条备选路线的对比接到的需求很朴素Linux服务器上跑一个Python服务定时从SAP里读取物料、BOM、销售订单的增量数据偶尔还要调BAPI创建或修改单据。这个场景下面我当时对比过三条路线直接用C语言写RFC调用封装SAP NW RFC SDK的原生接口。这条路灵活性最大但代价也很明显要自己处理内存分配、结构体映射、错误码转换一个小功能可能要写几百行C代码后续加接口还要重新编译工程成本太高。找社区第三方库比如某些自动生成的RFC绑定包。优点是上手快缺点是不少库只支持老版本OpenSAP或Python 2对RFC协议的新特性支持滞后生产环境不敢依赖这种“人气驱动”的维护节奏。使用SAP官方PyRFC配合NW RFC SDK。PyRFC把底层C接口做成了接近Python风格的调用方式上层代码简洁底层协议能力又完整。最终选第三条路不是因为它最华丽而是因为它在“省事”和“可靠”之间达到了平衡。SAP官方维护意味着后续SDK升级、新增功能绑定都不会断档这是一个生产系统选型时非常重要的考量。1.2 pyrfc和nwrfc sdk到底是什么关系很多新手第一次看到这套组合会很懵pyrfc里明明写了import为什么还要单独装一个SDK打个比方PyRFC像一个翻译而NW RFC SDK是电话线路。电话线路负责把声音传输到远方翻译负责把语言转成双方都能理解的内容。两者缺一不可。具体到代码层面PyRFC只负责Python对象和C数据结构的转换、调用约束、错误异常处理真正通过网络和SAP网关建立连接、执行RFC函数、传递数据包全部由SDK里的动态库比如libsapnwrfc.so完成。如果你只pip install了pyrfc没有正确安装SDKimport可以成功但一创建Connection就会报RFC_LIBRARY_NOT_FOUND。1.3 这套方案最适合什么场景从我这边的实际使用来看pyrfc nwrfc sdk最适合这些情况数据集成定时从SAP抽取物料主数据、库存、财务凭证同步到数据仓库或业务中台。自动化操作通过BAPI批量创建订单、修改状态、触发单据审批。报表输出把RFC函数返回的表数据直接转为DataFrame做分析。不适合的场景也有比如你想在ABAP端做复杂业务逻辑、和SAP GUI深度联动调试那还是老老实实去SE37/SE80里开发没必要绕到外部系统。2. 从下载nwrfcsdk到设置环境变量每一步都别急着跳2.1 SDK从哪下载、怎么解压NW RFC SDK不是PyPI上的包也不是随便找个镜像就能拿到的它需要登录SAP Software Download Center用SAP S-user账号下载。我这边环境是x86_64的Linux选择的就是“SAP NW RFC SDK 7.50 for Linux on x86_64”这个包。下载下来是一个tgz压缩包文件名类似nwrfc750P_x86_64_xxxxx.tgz。解压时我习惯把SDK放到独立的目录方便后续做版本管理mkdir -p /opt/nwrfcsdk tar -xzf nwrfc750P_x86_64_xxxxx.tgz -C /opt/nwrfcsdk解压后的目录结构大致是/opt/nwrfcsdk ├── include # RFC头文件编译时要用 ├── lib # libsapnwrfc.so及依赖库 ├── bin # 少量工具脚本 └── doc # 官方文档和示例重点是lib目录下的libsapnwrfc.sopyrfc运行时要加载的就是它。如果你是从rpm包安装SDK系统可能自动写入了ldconfig配置但tgz方式解压就得手动设置环境变量。2.2 环境变量配置SAPNWRFC_HOME和LD_LIBRARY_PATHSDK解压完要设置两个环境变量。SAPNWRFC_HOME是给编译环节用的告诉构建脚本去哪找头文件和库LD_LIBRARY_PATH是给运行时用的让系统能找到动态库。export SAPNWRFC_HOME/opt/nwrfcsdk export LD_LIBRARY_PATH/opt/nwrfcsdk/lib:$LD_LIBRARY_PATH这个配置建议写进系统级文件避免每次打开终端都手动source。我一般放在/etc/profile.d/sapnwrfc.sh里cat /etc/profile.d/sapnwrfc.sh EOF export SAPNWRFC_HOME/opt/nwrfcsdk export LD_LIBRARY_PATH/opt/nwrfcsdk/lib:$LD_LIBRARY_PATH EOF这里有个容易踩的细节LD_LIBRARY_PATH只在当前shell环境里有效如果你是通过systemd服务运行Python脚本需要在service文件里单独EnvironmentLD_LIBRARY_PATH...否则系统服务加载不到库。我最初在systemd里跑定时任务时就被这个坑过。2.3 用ldd检查SDK依赖是否完整SDK本身也有自己的依赖如果系统里缺了某个基础库后期调用时会报出各种奇怪的错误。最简单的方法是用ldd检查ldd /opt/nwrfcsdk/lib/libsapnwrfc.so正常情况下会输出一系列libc.so.6 /lib64/libc.so.6这样的映射如果哪一行出现“not found”说明系统缺少对应的运行库。我碰到过一台比较精简的容器镜像缺失了libgcc_s.so.1安装gcc运行时库之后才解决。位数一致性也很重要如果系统是64位必须下载64位的SDK。用file命令确认file /opt/nwrfcsdk/lib/libsapnwrfc.so输出里应该有64-bit如果显示32-bit后面加载时必然报错。3. 安装pyrfc为什么“pip install pyrfc”会失败3.1 版本分水岭2.x和3.x的安装差异很多教程还在说“pip install pyrfc”一条命令搞定那基本是pyrfc 2.x时代的故事。从pyrfc 3.0开始官方不再为所有平台提供预编译wheel源码包仍然发布在PyPI上但直接装的话会触发本地编译编译过程中又依赖SDK和Cython。如果环境里刚好没有这些你会看到一堆gcc报错。所以如果你用的是Python 3.6以上版本我建议直接走源码构建路线别和pip默认行为较劲。pyrfc 3.x对应的就是Python 3的现代版本我这边用Python 3.8/3.10都编译通过过。3.2 编译前需要准备哪些依赖为了保证编译过程顺利先把这些装上yum install -y gcc python3-devel # CentOS/RHEL # 或者 apt install -y gcc python3-dev # Debian/Ubuntupython3-devel/python3-dev这个包容易漏。pyrfc编译时要引用Python.h没有开发头文件会直接报fatal error。然后安装构建工具pip install cython setuptools wheelCython是必须的因为pyrfc本体就是用Cython写的。3.3 拉源码、设置SDK环境、安装确认SDK环境变量已经export好之后进入项目目录构建git clone https://github.com/SAP/PyRFC.git cd PyRFC python setup.py build python setup.py install如果刚才的环境变量没生效也可以显式指定export SAPNWRFC_HOME/opt/nwrfcsdk python setup.py build --sapnwrfc/opt/nwrfcsdk python setup.py install官方仓库里还提供了一个pyrfc-build脚本封装了构建逻辑想省事可以这样python pyrfc-build --sapnwrfc/opt/nwrfcsdk构建过程一般一两分钟结束。安装完成后验证是能否importfrom pyrfc import Connection print(Connection)如果这一步正常输出class pyrfc.cyrfc.Connection说明pyrfc本体已经OK。如果报ImportError: libsapnwrfc.so: cannot open shared object file那基本还是LD_LIBRARY_PATH的问题回到上一章检查。3.4 项目里的SDK路径固化做法每次开终端都要export环境变量太麻烦我更推荐把SDK的路径写死在项目的启动脚本里。比如项目根目录的run.sh#!/bin/bash export SAPNWRFC_HOME/opt/nwrfcsdk export LD_LIBRARY_PATH/opt/nwrfcsdk/lib:$LD_LIBRARY_PATH exec python3 main.py注意不要在Python内部用os.environ[LD_LIBRARY_PATH]...来补救因为动态库的加载时机在进程启动早期Python运行时已经加载完依赖了运行时改环境变量往往来不及。必须确保进程启动前LD_LIBRARY_PATH就正确。4. 第一个真实调用连接参数、RFC函数调用与返回解析4.1 连接参数拆解环境就绪后连接SAP就简单了。最基础的方式是直接指定应用服务器参数from pyrfc import Connection conn Connection( userRFC_USER, passwdyour_password, ashost192.168.100.10, sysnr00, client100, langEN ) print(连接状态:, conn.alive) conn.close()这里我把最常用的参数整理成了一张表方便你按需取值参数名含义典型值备注ashostSAP应用服务器IP或主机名192.168.100.10也可以填SAProuter地址sysnrSAP系统编号00 / 01两位字符串client客户端100 / 200三位字符串userRFC用户名RFC_USER必须来自SAP用户主记录passwd用户密码由SAP管理员设置注意密码中特殊字符转义lang登录语言EN / ZH语言包要和系统配置一致mshost消息服务器地址sapmshost使用负载均衡/消息服务器时填r3name系统IDPRD / QAS搭配消息服务器使用group服务器组PUBLIC负载均衡的分组名如果你的SAP环境启用了负载均衡也可以不指定具体应用服务器改用mshost r3name group的组合这样连接请求由消息服务器自动分发。两种方式对应标准SAP GUI连接选项里的“Application Server”和“Load Balancing”两种模式。4.2 第一个RFC_PING连通性测试用RFC_PING最稳什么都不用传result conn.call(RFC_PING) print(RFC_PING完成:, result)如果没报错说明连接、权限、路由三层全部正常。这个函数通常没有任何返回参数所以结果是空字典这是正常的。4.3 调用一个带结构输出的BAPI连通性验证过了再上一个业务函数。以读取用户信息为例result conn.call(BAPI_USER_GET_DETAIL, USERNAMEDEMO) print(result)pyrfc会把RFC的structure转成Python dict把table转成list[dict]。所以result里通常包含{ RETURN: [{TYPE: S, MESSAGE: ...}], ADDRESS: {FULLNAME: Demo User, EMAIL: demoexample.com}, COMPANY: {...}, LOGONDATA: {...} }这个嵌套结构在取数时非常直观。比如logon_data result[LOGONDATA] print(最后登录时间:, logon_data.get(LSTAMP)) print(密码状态:, logon_data.get(PWDSET))对于业务表参数的传入比如按条件查询某段物料通常是在函数参数里直接传list[dict]result conn.call( BAPI_MATERIAL_GETLIST, MAXROWS100, MATERIAL_RANGE[{SIGN: I, OPTION: BT, LOW: M100, HIGH: M200}] )注意表参数的每个元素必须带SIGN和OPTION字段这是SAP选择表的标准格式写错过一次报RFC_INVALID_PARAMETER排查小半天才意识到少配了条件字段。4.4 数据类型转换和编码问题SAP的DATE类型在RFC协议里本质是字符串格式固定为YYYYMMDD。比如2024年5月1日要传成20240501。如果你在Python侧直接传datetime.date对象pyrfc 3.x部分版本能自动转换但我不建议依赖这个行为统一转成字符串最保险。关于编码连接参数里langZH时返回的中文字符串Python侧是正常的str类型但整个调用链的Linux系统locale最好设置为支持UTF-8export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8否则某些极端情况下会出现UnicodeDecodeError尤其是在SAP返回的备注字段里带有特殊字符时。5. 实测中遇到最多的报错与排查思路这一章我会按“现象、排查链路、最终修复”的方式写目的是让你在遇到问题时能顺着思路自己定位而不是只能靠搜索引擎碰运气。5.1 RFC_LIBRARY_NOT_FOUND先查库再查环境变量现象conn Connection(...) # pyrfc.SAPError: RFC_LIBRARY_NOT_FOUND这是王炸级的常见错误。很多人的第一反应是pyrfc没装好其实问题大多出在SDK那边。我建议按下面的顺序排查。第一步确认SDK确实存在且路径正确ls -l /opt/nwrfcsdk/lib/libsapnwrfc.so第二步确认LD_LIBRARY_PATH已经包含SDK的lib目录echo $LD_LIBRARY_PATH第三步用ldd验证SDK本身能不能在系统里找到所有依赖ldd /opt/nwrfcsdk/lib/libsapnwrfc.so第四步如果前三步全正常怀疑是编译时用旧SDK缓存的残留重新编译一次pyrfccd PyRFC python setup.py clean --all python setup.py build python setup.py install我遇到过一次特别隐蔽的情况系统里同时装了多个版本的SDK/usr/lib和/opt/nwrfcsdk/lib各有一份旧库LD_LIBRARY_PATH的手动配置没盖过系统默认路径导致加载了另一个不完整的库。最终把不需要的旧SDK清理掉才彻底解决。5.2 RFC_FUNCTION_NOT_FOUND先问SAP侧现象result conn.call(Z_MY_CUSTOM_FN) # pyrfc.SAPError: RFC_FUNCTION_NOT_FOUND排查这个错误时重点先在SAP系统侧确认几点该函数是否在系统中存在SE37里敲一下函数名看能不能找到。该函数是否允许远程调用SE37里“属性”页签的“处理类型”必须勾选“远程启用的模块”也就是Remote-Enabled Module。普通函数不能直接从RFC调用。用户是否有权限执行该函数SAP权限对象S_RFC会控制用户能调用哪些函数组权限不够会报RFC_AUTHORIZATION_FAILURE但如果权限对象配置比较碎也可能表现为找不到函数。我这边有一个项目就是因为SAP侧启用了严格的RFC白名单用户虽然能登录SAP GUI但外部调用新函数时全被拦在RFC授权之外最后调用方报的就是FUNCTION_NOT_FOUND。这类问题从Python侧怎么调都白搭必须让BASIS配置S_RFC授权。5.3 RFC_INVALID_PARAMETER类型和结构别想当然现象result conn.call(BAPI_XXXX, MATERIALM100) # pyrfc.SAPError: RFC_INVALID_PARAMETER排查关键点是搞清楚SAP函数接口里每个参数到底是IMPORTING、CHANGING还是TABLE参数以及参数的嵌套结构。直接用SE37查看函数文档最简单。常见问题有该参数不是简单的字符串而是一个structure代码里却传了string。TABLE参数里的每一行包含多个字段但Python侧只给了一个dict且缺少部分字段。选择表参数少了SIGN/OPTION字段。参数类型是NUMC或DEC传了整数或浮点但pyrfc对某些DEC类型要求字符串。一个比较稳妥的做法是先用SE37找到函数看“导入/导出/表参数”页签里的字段描述照着字段名构造Python字典。不要凭猜测去写参数名SAP的参数名经常和业务直觉不一致。5.4 连接超时或SAP端连接数打满现象调用频率变高之后出现Connection reset by peer、RFC_SYSTEM_FAILURE或者反复Unable to get connection。排查思路分两层应用层是否反复创建新连接、用完没有close导致SAP端占用大量对话进程。检查代码里连接对象是否被正确关闭或者使用连接池复用。网络层是否有防火墙或中间设备限制了长时间空闲连接。如果每次调用间隔很长连接会被中间设备断开客户端不知道继续用旧连接就会失败。我这边常用“断线重试”机制兜底查询类接口失败后重新建立连接再试一次效果很明显。5.5 locale导致的编码报错现象中文返回乱码或直接抛UnicodeDecodeError但同样的代码在Windows上正常。排查重点看Linux的locale配置locale如果输出是LANGC或LANGPOSIX程序默认用ASCII处理字节流遇到中文就会炸。解决办法是安装中文字符集并设置环境变量。localedef -i zh_CN -f UTF-8 zh_CN.UTF-8 export LANGzh_CN.UTF-8如果系统里没法安装zh_CN退而求其次用en_US.UTF-8也能让Python正确处理UTF-8编码。6. 文档没写透的几个生产环境经验6.1 连接复用与连接池RFC连接在SAP侧会占用ABAP会话资源每次新建连接都涉及SAP登录、授权检查、工作进程分配开销不小。频繁创建销毁连接不仅慢还可能被SAP侧限流。生产环境一定要做连接复用。一个简单的做法是用queue做连接池from queue import Queue from pyrfc import Connection class SAPPool: def __init__(self, size5, **conn_params): self.params conn_params self.pool Queue(maxsizesize) for _ in range(size): self.pool.put(Connection(**self.params)) def acquire(self): return self.pool.get() def release(self, conn): self.pool.put(conn) pool SAPPool(size3, userRFC_USER, passwdpassword, ashost..., sysnr00, client100) conn pool.acquire() try: result conn.call(RFC_PING) finally: pool.release(conn)池大小按并发数评估一般3到5个就够。要注意连接池里的连接如果长期空闲被SAP端断开使用前建议先检查conn.alive或者捕获异常后重建连接。6.2 大结果集分批处理有些RFC函数返回的数据量很大比如一次读取几万条日志或明细。直接把整个表拉到内存不仅慢SAP侧也可能因为导出内存超限报错。处理方式是尽量使用函数自带的分页参数比如行数上限MAXROWS和游标。示例里可以设定每次取2000行循环拉取直到数据取完。result conn.call(BAPI_MATERIAL_GETLIST, MAXROWS2000, ...)如果函数本身不分页可以考虑在传入条件里用日期、物料号区间缩小范围多次调用再拼接。6.3 写操作接口的重试要格外小心查询类接口重试没问题但BAPI里做创建、修改、审批这类写操作时重试可能导致重复下单或重复记账。我这边写操作调用失败后不会自动重试而是把请求参数和错误信息写入log表交给人工或补偿流程处理。这个经验是实打实踩坑换来的之前某个同步程序在BAPI调用超时后自动重试结果SAP里产生了重复的销售订单后面手工对冲花了半天。6.4 容器化部署时别漏了SDK如果你把服务打包成Docker镜像SDK不会自动跟随Python镜像。Dockerfile里要显式把SDK拷贝进去并设置环境变量FROM python:3.10-slim COPY nwrfc /opt/nwrfcsdk ENV SAPNWRFC_HOME/opt/nwrfcsdk ENV LD_LIBRARY_PATH/opt/nwrfcsdk/lib:$LD_LIBRARY_PATH RUN pip install cython setuptools wheel \ git clone https://github.com/SAP/PyRFC.git /tmp/PyRFC \ cd /tmp/PyRFC python setup.py install COPY app /app WORKDIR /app CMD [python, main.py]注意基础镜像尽量选带完整glibc的不要用alpine的musl版本SDK的动态库对glibc有依赖alpine下会遇到莫名其妙的加载问题。我当时为了镜像大小把基础镜像从debian换到alpine结果ldd一片not found最后又换回slim系列才稳定。6.5 日志记录时的脱敏问题RFC调用的出入参里往往包含业务敏感信息比如客户名称、价格、用户口令等。生产环境的日志建议只记录调用函数名、传入的关键筛选条件、耗时、返回码不要直接打印整个请求和响应字典。如果确实需要调试加上开关控制默认关闭。6.6 最后一个小技巧先用RFC_PING做健康检查集成到监控系统时可以用RFC_PING做SAP连接健康检查比直接调用业务函数成本低得多也不会对SAP业务产生副作用。定时任务启动前先做一次健康检查如果失败给报警系统发一条消息能提前规避大批量任务同时失败的情况。整套做下来Linux Python pyrfc NW RFC SDK的链路虽然初始搭建有些门槛但一旦把SDK环境问题处理完后面写业务逻辑的效率非常高。尤其是不用碰C语言就能稳定调用SAP的RFC和BAPI对数据团队来说省了太多事。如果你也正在做类似的事建议先把SDK环境、环境变量、pyrfc编译这三件事理顺再开始写业务代码顺序反了会排查到怀疑人生。本文还有配套的精品资源点击获取
