簡介SAP NetWeaver RFC SDK 7.5.0 是 SAP 官方提供的遠(yuǎn)程函數(shù)調(diào)用RFC開發(fā)包是 SapNwRfc 的依賴組件面向企業(yè)級系統(tǒng)集成開發(fā)主要解決開發(fā)者在 Windows 與 Linux 雙平臺下構(gòu)建 SAP 連接程序時(shí)缺少頭文件、運(yùn)行庫及調(diào)用接口的問題適合 SAP 顧問、獨(dú)立開發(fā)者與運(yùn)維人員也適配具備 ERP 系統(tǒng)知識和 C/C 編程基礎(chǔ)的開發(fā)者。壓縮包為 rar 格式總計(jì)56個(gè)文件大小約25.48MB文件類型以頭文件、C/C 源碼、動態(tài)鏈接庫、靜態(tài)庫為核心還附帶配置文件、可執(zhí)行工具和調(diào)試文件覆蓋從開發(fā)引用到運(yùn)行調(diào)試的完整鏈路。已有 1576 人學(xué)習(xí)/下載。開發(fā)者拿到資源后可直接獲得官方 SDK 運(yùn)行組件和命令行工具快速完成本地環(huán)境部署避免手動搜索依賴包借助配置文件和命令行工具驗(yàn)證 RFC 連接、排查常見報(bào)錯(cuò)為后續(xù)功能二次開發(fā)提供可復(fù)用的基礎(chǔ)環(huán)境同時(shí)支持 Windows 與 Linux 系統(tǒng)能夠滿足跨平臺項(xiàng)目需求壓縮包內(nèi)文件排布清晰便于按操作系統(tǒng)查找所需組件。1. SAP NetWeaver RFC SDK 7.5.0 管哪類集成為什么接口崗先學(xué)它去年做一個(gè)倉儲系統(tǒng)對接時(shí)對方 SAP 側(cè)只肯放 RFC 接口我們用 WebService 來回傳發(fā)貨單單筆事務(wù)平均兩秒以上大批量傳輸直接超時(shí)。后來換成 SAP NetWeaver RFC SDK 7.5.0 的 Java 連接器同樣的數(shù)據(jù)量壓到了幾十毫秒級別問題一夜之間從“能不能跑完”變成“怎么調(diào)更快”。SAP NetWeaver RFC SDK 7.5.0 是 SAP 官方提供給外部程序調(diào)用 RFC 和 BAPI 的軟件開發(fā)包覆蓋 ECC、S/4HANA 這一代系統(tǒng)的常見集成場景適合做接口開發(fā)、數(shù)據(jù)同步、報(bào)表抽取的從業(yè)者。它不是最時(shí)髦的技術(shù)但確實(shí)是 SAP 對外集成里最穩(wěn)、最值得先吃透的一條老路。2. 選型與落庫JCo 3.x 還是 NW RFC Library搭好 7.5.0 的最小運(yùn)行環(huán)境2.1 語言決定選型版本決定兼容范圍拿到 7.5.0 的 SDK 包后第一件事不是寫代碼而是看清里面有兩套運(yùn)行時(shí)Java 側(cè)是 sapjco3JCo 3.x 系列C/C 側(cè)是 NW RFC Library7.50 系列。這兩套東西解決的是同一個(gè)協(xié)議問題但服務(wù)不同的語言生態(tài)。很多開發(fā)者在這第一步就犯選擇困難其實(shí)判斷標(biāo)準(zhǔn)只有一條你的調(diào)用程序用什么語言寫。如果后端是 Java 系Spring Boot、Java 中間件、數(shù)據(jù)平臺直接走 sapjco3如果要用 C 或通過其他語言封裝調(diào)用則必須裝 NW RFC Library。很多非 Java 語言的 SAP 連接庫底層依賴的就是這套原生 RFC 庫所以裝錯(cuò)版本會連帶出一堆“找不到符號”的怪問題。對比維度Java 版 sapjco3C/C 版 NW RFC Library主要文件sapjco3.jar sapjco3.dll/solibsapnwrfc.so/dll 頭文件典型場景Spring Boot 服務(wù)、Java 批處理、中間件C 服務(wù)、其他語言的底層封裝部署復(fù)雜度需要同時(shí)管理 jar 與原生庫需要配置動態(tài)庫搜索路徑線程模型destination 線程安全連接句柄需自行管理7.5.0 這套 SDK 在兼容性上覆蓋的是 NetWeaver 7.5 時(shí)代的系統(tǒng)對接 ECC 6.0 和常見版本的 S/4HANA 都是常規(guī)操作。真正要小心的是老到 R/3 4.x 那種古董系統(tǒng)RFC 協(xié)議版本差異會讓新版 SDK 直接報(bào)錯(cuò)遇到這種場景再考慮降級 SDK。新項(xiàng)目里絕大多數(shù)情況不必有這個(gè)顧慮按目標(biāo)系統(tǒng)的主流配置選 7.5.0 即可。2.2 安裝與落位jar、dll、so 三件套的路徑陷阱SDK 安裝沒有安裝向?qū)П举|(zhì)上是把三樣?xùn)|西放對位置。Java 版最少需要 sapjco3.jar 和對應(yīng)平臺的原生庫Windows 下是 sapjco3.dllLinux 下是 libsapjco3.so。jar 負(fù)責(zé) Java 代碼里的類定義原生庫負(fù)責(zé)真正走 RFC 協(xié)議兩者缺一個(gè)都會在運(yùn)行時(shí)炸開。我一般會在服務(wù)器上建一個(gè)固定目錄專門放 SAP SDK比如/opt/sap/rfcsdk然后把原生庫目錄寫進(jìn)系統(tǒng)路徑。Windows 上可以這樣設(shè)置環(huán)境變量set CLASSPATHD:\sap\rfcsdk\sapjco3.jar;%CLASSPATH% set PATHD:\sap\rfcsdk;%PATH%Linux 上則把 so 文件的目錄加進(jìn) LD_LIBRARY_PATHexport SAP_RFC_SDK/opt/sap/rfcsdk export LD_LIBRARY_PATH$SAP_RFC_SDK:$LD_LIBRARY_PATH export CLASSPATH$SAP_RFC_SDK/sapjco3.jar:$CLASSPATH這段命令的邏輯是CLASSPATH 讓 JVM 能找到 sapjco3.jar 中的類LD_LIBRARY_PATH 讓 JVM 在加載 native 方法時(shí)能找到 libsapjco3.so。兩個(gè)路徑缺一不可很多部署翻車都是因?yàn)橹慌淞?CLASSPATH忘了配動態(tài)庫路徑。如果項(xiàng)目里同時(shí)有多個(gè) Java 服務(wù)我更推薦把這些環(huán)境變量寫進(jìn)服務(wù)的啟動腳本而不是改全局配置否則升級 SDK 時(shí)會波及所有應(yīng)用。需要注意位數(shù)必須一致。64 位的 JVM 配 32 位的 sapjco3.dll 會直接加載失敗反過來也一樣。下載 SDK 時(shí)確認(rèn)平臺版本部署前先看一眼服務(wù)器 Java 位數(shù)這個(gè)習(xí)慣能省掉一晚上的排查時(shí)間。2.3 驗(yàn)證安裝一個(gè) 10 行的自檢類環(huán)境變量配完后不要急著寫業(yè)務(wù)代碼先用一個(gè)最小類驗(yàn)證三件套是否真的就位。我習(xí)慣在任意 Java 工程里放一個(gè)這樣的自檢入口public class RfcSdkCheck { public static void main(String[] args) { try { Class.forName(com.sap.conn.jco.JCoDestinationManager); System.out.println([1] sapjco3.jar loaded); System.loadLibrary(sapjco3); System.out.println([2] native library loaded); System.out.println([3] RFC SDK ready); } catch (ClassNotFoundException e) { System.err.println(sapjco3.jar 不在 CLASSPATH 中); } catch (UnsatisfiedLinkError e) { System.err.println(找不到 sapjco3 原生庫檢查 PATH/LD_LIBRARY_PATH); } } }這段代碼分三步驗(yàn)證Class.forName確認(rèn) jar 里的核心類可以被 JVM 找到System.loadLibrary(sapjco3)強(qiáng)制加載原生庫加載成功才說明動態(tài)庫路徑?jīng)]問題。要是第一步就掛基本是 CLASSPATH 寫錯(cuò)或 jar 沒放進(jìn)依賴要是第二步掛問題一定在 PATH 或 LD_LIBRARY_PATH不用懷疑代碼本身。這個(gè)自檢類我會留在工程里當(dāng)調(diào)試工具排查環(huán)境問題時(shí)先跑它比反復(fù)看報(bào)錯(cuò)堆?？斓枚?。3. 用 JCo 調(diào)通第一個(gè) RFC連接參數(shù)、函數(shù)接口與代碼示例3.1 destination 的七要素與兩種連接方式JCo 里一切連接配置都收斂到 destination也就是一個(gè)命名好的連接定義。最常用的直連方式需要七個(gè)要素應(yīng)用服務(wù)器地址ashost、系統(tǒng)編號sysnr、客戶端client、用戶名user、密碼passwd、語言lang以及可選的網(wǎng)關(guān)參數(shù)gwhost、gwserv。前六個(gè)是必填的網(wǎng)關(guān)參數(shù)通常在極少數(shù)特殊函數(shù)場景才會用到。參數(shù)配置有兩種寫法寫在jco.client前綴的屬性文件里或者在代碼里用 JCoDestinationManager 綁定。屬性文件的寫法是jco.client.ashost10.20.30.40 jco.client.sysnr00 jco.client.client800 jco.client.userRFC_USER jco.client.passwdsecret jco.client.langZH jco.client.gwserv/sapgw00這里jco.client前綴是 JCo 識別連接參數(shù)的固定規(guī)則前綴后的鍵名對應(yīng) RFC 客戶端的標(biāo)準(zhǔn)字段。sysnr 是 SAP 系統(tǒng)編號通常是兩位數(shù)字client 是三位數(shù)字的客戶端號lang 填 ZH 表示中文EN 表示英文。如果 SAP 側(cè)啟用了負(fù)載均衡則需要換成 msgserver消息服務(wù)器地址和 group服務(wù)器組而不是 ashost但直連方式在大多數(shù)接口項(xiàng)目中已經(jīng)夠用。我遇到過不少人把 host 直接寫在代碼里硬編碼換環(huán)境就要改代碼重新發(fā)布。更穩(wěn)的做法是把這些配置外置到配置文件通過環(huán)境變量區(qū)分測試和生產(chǎn)這樣同一個(gè) jar 包在不同環(huán)境都能跑。3.2 從 SE37 的函數(shù)接口到 JCo 參數(shù)映射SAP 側(cè)的 RFC 函數(shù)在事務(wù)碼 SE37 里能看到它的完整接口導(dǎo)入?yún)?shù)Import、導(dǎo)出參數(shù)Export、表參數(shù)Tables以及異常Exceptions。JCo 的映射方式很直接創(chuàng)建函數(shù)對象后用 getImportParameterList、getExportParameterList、getTableParameterList 分別拿參數(shù)列表再通過 setValue 和 getValue 讀寫具體字段。這里最容易踩的坑是不看接口定義憑感覺猜參數(shù)名。RFC 函數(shù)的參數(shù)名嚴(yán)格區(qū)分大小寫名字猜錯(cuò)一個(gè)字母運(yùn)行時(shí)拋出的異常會讓你排查半天。正確做法是先創(chuàng)建一個(gè)函數(shù)對象通過 JCo 的反射能力把參數(shù)結(jié)構(gòu)打出來看。一個(gè)小工具寫法JCoDestination dest JCoDestinationManager.getDestination(MY_DEST); JCoFunction fn dest.getRepository().getFunction(YOUR_RFC_NAME); if (fn null) { System.err.println(函數(shù)不存在檢查名稱和權(quán)限); return; } JCoParameterList imp fn.getImportParameterList(); JCoParameterList exp fn.getExportParameterList(); JCoTable table fn.getTableParameterList().getTable(T_ITEMS);代碼的邏輯是先拿到 destination再從 repository 里按名稱獲取函數(shù)元數(shù)據(jù)。如果返回 null說明 SAP 側(cè)沒有這個(gè)函數(shù)或者當(dāng)前用戶無權(quán)限查看而不是代碼寫錯(cuò)。拿到參數(shù)列表后可以用 getMetaData 遍歷字段名和類型先看清再填值。JCo 的 repository 會對函數(shù)元數(shù)據(jù)做緩存因此這里拿函數(shù)對象的開銷很低不需要擔(dān)心反復(fù)調(diào)用影響性能。3.3 最小可運(yùn)行示例調(diào)用 RFC_SYSTEM_INFO理論講再多不如一個(gè)能跑的函數(shù)。RFC_SYSTEM_INFO 是 SAP 標(biāo)準(zhǔn)函數(shù)幾乎所有系統(tǒng)都有用來測試連接最合適。下面是完整的最小示例它會連接 SAP 并讀出系統(tǒng)標(biāo)識和當(dāng)前用戶import com.sap.conn.jco.*; public class RfcPing { public static void main(String[] args) throws JCoException { JCoDestination dest JCoDestinationManager.getDestination(MY_DEST); JCoFunction fn dest.getRepository().getFunction(RFC_SYSTEM_INFO); if (fn null) { throw new RuntimeException(RFC_SYSTEM_INFO 未找到請用 SE37 確認(rèn)); } fn.execute(dest); String sysId fn.getExportParameterList().getString(RFCSYSID); String user fn.getExportParameterList().getString(RFCUSER); System.out.println(SAP System ID sysId); System.out.println(RFC User user); } }這段代碼做了四件事獲取連接、拿函數(shù)對象、執(zhí)行調(diào)用、讀取導(dǎo)出參數(shù)。fn.execute(dest)是阻塞調(diào)用執(zhí)行完成后結(jié)果會寫回函數(shù)對象的導(dǎo)出參數(shù)列表RFCSYSID是系統(tǒng)標(biāo)識RFCUSER是調(diào)用者賬號這兩個(gè)字段是 RFC_SYSTEM_INFO 的固定導(dǎo)出參數(shù)。如果這段代碼能打印出正確的系統(tǒng)標(biāo)識說明整條鏈路已經(jīng)從 Java 進(jìn)程打通到了 SAP 應(yīng)用服務(wù)器后續(xù)換成自己的業(yè)務(wù)函數(shù)只是換一下函數(shù)名和參數(shù)映射的事。4. 生產(chǎn)環(huán)境四組參數(shù)連接池、超時(shí)、日志與線程安全4.1 連接池與線程安全destination 可以復(fù)用function 不可以RFC 調(diào)用和 JDBC 一樣頻繁創(chuàng)建連接是大忌。JCo 的 destination 本身是線程安全的官方設(shè)計(jì)就是讓你在整個(gè)應(yīng)用生命周期內(nèi)復(fù)用同一個(gè) destination 實(shí)例。常見做法是啟動時(shí)初始化一次后續(xù)所有線程共享public class RfcClient { private static JCoDestination dest; public static synchronized JCoDestination getDestination() throws JCoException { if (dest null) { dest JCoDestinationManager.getDestination(MY_DEST); } return dest; } }這段代碼用雙重檢查鎖保證只初始化一次 destination。JCo 內(nèi)部會為每個(gè) destination 維護(hù)連接池多個(gè)線程并發(fā)調(diào)用時(shí)會自動分配空閑連接不需要自己在業(yè)務(wù)層做鎖。需要注意的反而是 JCoFunction它是有狀態(tài)的不能在多個(gè)線程之間共享同一個(gè)函數(shù)實(shí)例。每次調(diào)用前通過 repository 獲取新函數(shù)對象或者為每個(gè)線程維護(hù)自己的函數(shù)對象。生產(chǎn)環(huán)境里我看到過有人把 JCoFunction 放在靜態(tài)變量里共用并發(fā)一上來就出現(xiàn)參數(shù)串味排查了很久才發(fā)現(xiàn)是函數(shù)對象被多線程同時(shí)讀寫。記住這條邊界destination 復(fù)用function 不復(fù)用。4.2 超時(shí)、重試與并發(fā)限制連接 SAP 不像連 MySQL 那么簡單SAP 應(yīng)用服務(wù)器在高負(fù)載時(shí)可能長時(shí)間不響應(yīng)必須設(shè)置合理的超時(shí)參數(shù)。JCo 支持在配置文件里控制連接和讀取超時(shí)參數(shù)名單位建議值作用jco.client.conn_timeout毫秒30000建立 TCP 連接的超時(shí)上限jco.client.read_timeout毫秒300000等待 SAP 返回?cái)?shù)據(jù)的超時(shí)上限jco.client.max_clients整數(shù)10該 destination 的最大并發(fā)連接數(shù)jco.client.pool_capacity整數(shù)20連接池可容納的空閑連接數(shù)conn_timeout 設(shè)太短會在 SAP 重負(fù)載時(shí)誤報(bào)連接失敗設(shè)太長會讓故障感知變慢read_timeout 是根據(jù)最慢函數(shù)調(diào)用的耗時(shí)來定的批量數(shù)據(jù)導(dǎo)出類接口建議給到 5 分鐘以上。max_clients 和 pool_capacity 需要結(jié)合應(yīng)用并發(fā)量估算我不建議一上來就調(diào)到 50 以上先壓測再慢慢加。重試策略也要分場景連接建立階段失敗可以重試因?yàn)檎埱筮€沒到達(dá) SAP但函數(shù)執(zhí)行階段報(bào)錯(cuò)則要謹(jǐn)慎因?yàn)?SAP 側(cè)可能已經(jīng)部分執(zhí)行了業(yè)務(wù)邏輯。以 BAPI 為例有些 BAPI 內(nèi)部會提交數(shù)據(jù)重試可能導(dǎo)致重復(fù)過賬。我的習(xí)慣是只對連接異常做最多兩次重試業(yè)務(wù)執(zhí)行異常一律拋給上層人工處理。4.3 打開黑匣子trace 與日志JCo 最讓人頭疼的是出問題時(shí)異常信息太簡略很多時(shí)候只有一段含糊的“JCoException: (0) ERROR”。這時(shí)候需要把 JCo 的 trace 打開看底層的 RFC 協(xié)議交互。配置文件里加兩行jco.trace_level5 jco.trace_path/var/log/sapjcojco.trace_level 控制跟蹤級別數(shù)字越大輸出越詳細(xì)最高到 10jco.trace_path 指定 trace 文件輸出目錄。級別調(diào)到 5 左右能看到函數(shù)調(diào)用名、參數(shù)傳輸概況和錯(cuò)誤碼排錯(cuò)夠用調(diào)到 10 會記錄每個(gè)數(shù)據(jù)包的內(nèi)容文件增長非常快不建議長期開著。trace 文件的典型價(jià)值在于區(qū)分問題發(fā)生的位置如果 trace 里能看到請求包發(fā)出去了但響應(yīng)包異常問題在 SAP 側(cè)如果請求包都沒生成問題在參數(shù)映射或函數(shù)元數(shù)據(jù)上。我曾經(jīng)靠 trace 文件定位到一個(gè)詭異現(xiàn)象同一個(gè)函數(shù)在測試環(huán)境正常到生產(chǎn)環(huán)境就超時(shí)trace 顯示所有打包和解包動作都完成了最后排查發(fā)現(xiàn)是 SAP 側(cè)在導(dǎo)出大數(shù)據(jù)表時(shí)觸發(fā)了寫日志阻塞。沒有 trace 數(shù)據(jù)這類問題基本是無從下手的玄學(xué)。5. SAP NetWeaver RFC SDK 7.5.0 避坑指南5 個(gè)執(zhí)行期問題與排查路徑5.1 啟動即報(bào) UnsatisfiedLinkError原生庫沒被找到現(xiàn)象Java 進(jìn)程啟動時(shí)拋出java.lang.UnsatisfiedLinkError: no sapjco3 in java.library.path程序完全無法運(yùn)行。原因CLASSPATH 找到了 jar但 JVM 無法加載 sapjco3.dll 或 libsapjco3.so。常見于 Windows 下 dll 沒放進(jìn) PATHLinux 下忘了配 LD_LIBRARY_PATH或者 JVM 位數(shù)與 SDK 位數(shù)不一致。解決先跑第二章的自檢類確認(rèn)是哪一步加載失敗。位數(shù)不一致的去下載對應(yīng)位數(shù)的 SDK路徑?jīng)]配的檢查啟動腳本里是否有 export 語句以及啟動服務(wù)的用戶環(huán)境是否繼承了這些變量。特別提醒 Linux 上用 systemd 啟動服務(wù)時(shí)systemd 上下文不一定會讀取/etc/profile里的環(huán)境變量要在 service 文件里顯式寫 Environment 字段。5.2 中文字段變問號或被截?cái)喱F(xiàn)象從 SAP 讀到的中文內(nèi)容顯示為???或者到達(dá)一定長度后被截?cái)鄶?shù)字和英文正常。原因codepage 不一致。SAP 側(cè)一般有完整的 Unicode 配置但 RFC 會話的顯示語言和代碼頁需要顯式指定。語言沒設(shè)成 ZH 時(shí)中文會按錯(cuò)誤代碼頁解釋最常見的表現(xiàn)就是問號。截?cái)鄤t往往是字段定義長度不足或?qū)С鰠?shù)的類型不匹配。解決連接參數(shù)里設(shè)置jco.client.langZH同時(shí)確認(rèn) SAP 側(cè)函數(shù)接口里對應(yīng)字段是足夠的字符類型。讀數(shù)據(jù)時(shí)優(yōu)先用getString方法不要用getBytes再自己轉(zhuǎn)碼JCo 會自己做代碼頁轉(zhuǎn)換。如果轉(zhuǎn)完還是亂碼去 SE37 檢查該字段的 Data Element 是否允許中文有些字段本身定義就是拉丁字符集那是 SAP 側(cè)要改客戶端怎么處理都沒用。5.3 導(dǎo)出大表撐爆內(nèi)存表參數(shù)讀取方式不當(dāng)現(xiàn)象調(diào)用 BAPI 導(dǎo)出上萬行的表數(shù)據(jù)JVM 直接 OutOfMemoryError 或 GC 卡死。原因JCoTable 會把整個(gè)表數(shù)據(jù)加載到客戶端內(nèi)存行數(shù)巨大時(shí)內(nèi)存開銷超預(yù)期。而默認(rèn)的遍歷方式是循環(huán) next 直到末尾如果數(shù)據(jù)還在持續(xù)增長等于無限吃內(nèi)存。解決首先在 SAP 側(cè)看該函數(shù)是否支持分頁參數(shù)很多 BAPI 都帶分頁輸入?yún)?shù)一次只取幾百行循環(huán)多次取完。如果不支持分頁則在讀取時(shí)改用游標(biāo)式處理逐行消費(fèi)后用table.clear()釋放行數(shù)據(jù)而不是保留完整結(jié)果集。讀完后把 JCoTable 引用置空讓它盡早被 GC 回收。5.4 本地 IDEA 能跑部署到服務(wù)器就 NoClassDefFoundError現(xiàn)象代碼在本機(jī) IDEA 里運(yùn)行正常打包部署到 Linux 服務(wù)器后啟動報(bào)NoClassDefFoundError: com/sap/conn/jco/...。原因IDEA 運(yùn)行時(shí)自動把你的 SDK 目錄加進(jìn)了 CLASSPATH但 Maven 打包時(shí) sapjco3.jar 沒有作為依賴打進(jìn)去。JCo 的 jar 不一定會自動進(jìn)入 fat jar很多人只在 IDE 里配置了 Library沒有寫入 pom。解決確認(rèn) sapjco3.jar 是否以 system 依賴或外部 lib 方式引入了構(gòu)建。如果用的是 Spring Boot 的 fat jar需要額外配置把 jar 包含進(jìn)去如果刻意不打進(jìn)包里則要在服務(wù)器的啟動腳本里顯式寫 CLASSPATH。我的一般做法是讓 SDK 路徑統(tǒng)一jar 不打進(jìn)應(yīng)用包通過啟動腳本控制這樣升級 SDK 不需要重新發(fā)布應(yīng)用。5.5 調(diào)用報(bào) RFC_ERROR_SYSTEM_FAILURE函數(shù)存在性、權(quán)限和網(wǎng)關(guān)都要查現(xiàn)象執(zhí)行函數(shù)時(shí)拋出JCoException: (128) RFC_ERROR_SYSTEM_FAILURE異常信息里沒有更多細(xì)節(jié)。原因這是 SAP 側(cè)執(zhí)行階段報(bào)錯(cuò)的匯總碼常見誘因有三個(gè)函數(shù)名在目標(biāo)系統(tǒng)不存在、調(diào)用賬號沒有該函數(shù)的執(zhí)行權(quán)限S_RFC 授權(quán)對象、或者 SAP 側(cè)函數(shù)內(nèi)部發(fā)生了 unhandled exception。解決別在這種異常上瞎猜先做三連查。第一步用 RFC_PING 確認(rèn)連接本身正常第二步用代碼創(chuàng)建同名的 JCoFunction檢查是否返回 null返回 null 說明函數(shù)不存在或元數(shù)據(jù)無法獲取第三步去 SU01 查賬號角色里是否有 S_RFC 授權(quán)確認(rèn)目標(biāo)函數(shù)組已授權(quán)。如果前三點(diǎn)都正常去 ST05 開啟 SQL 追蹤看函數(shù)內(nèi)部訪問數(shù)據(jù)庫時(shí)是否報(bào)錯(cuò)。這套流程走下來絕大多數(shù) 128 錯(cuò)誤能在十分鐘內(nèi)定位到具體環(huán)節(jié)。6. 進(jìn)階技巧把元數(shù)據(jù)緩存與連接復(fù)用收進(jìn)獨(dú)立模塊跑通第一版 RFC 調(diào)用后別急著繼續(xù)堆業(yè)務(wù)代碼先做一個(gè)獨(dú)立的 RFC 網(wǎng)關(guān)模塊把三類容易出問題的地方統(tǒng)一收納。第一個(gè)是元數(shù)據(jù)緩存。JCo 的 repository 本身緩存函數(shù)元數(shù)據(jù)但如果你在代碼里頻繁調(diào)getRepository().getFunction要確認(rèn)每次拿的是緩存對象還是重新拉取。正確方式是模塊內(nèi)部維護(hù)ConcurrentHashMapString, JCoFunctionTemplate同一函數(shù)只向 repository 請求一次后續(xù)復(fù)制模板private static final MapString, JCoFunction CACHE new ConcurrentHashMap(); public static JCoFunction getFunction(String name) throws JCoException { return CACHE.computeIfAbsent(name, k - RfcClient.getDestination().getRepository().getFunction(k)); }注意這段代碼只緩存模板模板可用于復(fù)制新實(shí)例但不能直接并發(fā)執(zhí)行。第二個(gè)是連接復(fù)用。第三是超時(shí)參數(shù)集中管理建議每個(gè)函數(shù)對應(yīng)一個(gè)超時(shí)配置不要全用一個(gè)通用值——導(dǎo)出大表要長超時(shí)查詢類要短超時(shí)這樣單個(gè)函數(shù)異常不會拖垮整個(gè)應(yīng)用。模塊建好后給每個(gè)關(guān)鍵函數(shù)寫一個(gè)壓測入口。用線程池模擬并發(fā)調(diào)用從 1 并發(fā)逐步升到 10、20、50觀察兩個(gè)指標(biāo)應(yīng)用側(cè)的平均響應(yīng)時(shí)間以及 SAP 側(cè)事務(wù)碼 STAD 里的執(zhí)行時(shí)間。如果應(yīng)用側(cè)增大延遲但 SAP 側(cè)執(zhí)行時(shí)間不變說明瓶頸在應(yīng)用本身的連接池配置如果 SAP 側(cè)執(zhí)行時(shí)間也同步上漲說明 SAP 的對話進(jìn)程或數(shù)據(jù)庫負(fù)載才是瓶頸去調(diào)那邊的資源。我記得有一次把 JCo trace_level 調(diào)到 10 排查問題干完活忘了關(guān)結(jié)果那臺服務(wù)器三天后磁盤被 trace 日志寫滿整條集成鏈路連帶掛掉。從那以后我就把 trace 開關(guān)做成了配置中心的動態(tài)配置項(xiàng)排查時(shí)打開、排查完立即關(guān)閉再也不敢讓最高級別日志在生產(chǎn)環(huán)境過夜。這個(gè)習(xí)慣比任何參數(shù)調(diào)優(yōu)都值錢希望對你有用也希望你接手的下一個(gè) RFC 項(xiàng)目不再靠猜。本文還有配套的精品資源點(diǎn)擊獲取