簡(jiǎn)介這是一份面向Java開(kāi)發(fā)者的SAP JCoSAP Java Connector集成組件包用于解決Java應(yīng)用程序與SAP系統(tǒng)之間的通信與遠(yuǎn)程函數(shù)調(diào)用問(wèn)題。壓縮包共5個(gè)文件大小僅3.06MB包含32位與64位兩個(gè)版本的sapjco3.dll動(dòng)態(tài)鏈接庫(kù)分別存放于X86與X64目錄適配不同操作系統(tǒng)架構(gòu)另有txt說(shuō)明文檔、htm幫助頁(yè)面以及一個(gè)DLL工具exe方便完成dll注冊(cè)、修復(fù)與配置。已有278人學(xué)習(xí)下載。借助該包開(kāi)發(fā)者可以快速定位所需位數(shù)的dll文件按文檔指引配置JCo環(huán)境變量與類(lèi)路徑并在Java代碼中建立SAP連接、調(diào)用BAPI或RFC函數(shù)模塊。對(duì)于正在搭建Java與SAP集成環(huán)境、或需要排查sapjco3.dll加載異常的人員這份資源能提供直接可用的文件與配套說(shuō)明減少?gòu)腟AP官方渠道獲取組件的等待時(shí)間。1. JCo 3 到底是什么Java 程序連目標(biāo)系統(tǒng)前先把它講透做過(guò)企業(yè)應(yīng)用集成的開(kāi)發(fā)者大概率都碰過(guò)這樣一個(gè)包一個(gè)壓縮文件里躺著兩個(gè)文件一個(gè)文件名后綴是 jar另一個(gè)是 dll 或 so。這個(gè)包就是 JCo 3也就是 Java Connector 3Java 語(yǔ)言連接目標(biāo)業(yè)務(wù)系統(tǒng)的官方中間件組件。很多剛接觸的開(kāi)發(fā)者把壓縮包一解壓就直接往 classpath 里丟 jar結(jié)果一運(yùn)行就報(bào) native library 加載失敗或者版本不匹配連第一步都邁不過(guò)去。這篇文章從環(huán)境搭建、連接代碼、參數(shù)配置到踩坑記錄完整拆解 JCo 3 的正確用法定位是讓你照著操作就能把連接跑起來(lái)并且知道失敗時(shí)該看哪里。這套組件適合誰(shuí)正在寫(xiě) Java 與目標(biāo)系統(tǒng)接口的開(kāi)發(fā)者維護(hù)老系統(tǒng)接口的程序員以及負(fù)責(zé) ETL 數(shù)據(jù)同步的數(shù)據(jù)工程師。它不是那種裝完就能自動(dòng)干活的框架而是需要你理解 native 加載機(jī)制、連接池配置和異常分類(lèi)的中間件。下面直接進(jìn)入正題。2. 搭建運(yùn)行環(huán)境版本選擇、目錄規(guī)劃與 dll/so 加載機(jī)制2.1 版本選型32 位還是 64 位先看 jvm.arch 再動(dòng)手不少開(kāi)發(fā)者翻車(chē)的第一個(gè)地方是位版本選錯(cuò)。注意JCo 3 的 jar 包內(nèi)嵌的是 native 層調(diào)用jar 本身不分位數(shù)但 dll/so 文件嚴(yán)格區(qū)分 32 位和 64 位。判斷標(biāo)準(zhǔn)很簡(jiǎn)單查看 JVM 的位數(shù)而不是操作系統(tǒng)的位數(shù)。很多 Windows 上裝了 64 位操作系統(tǒng)但 JDK 裝的是 32 位版本這時(shí)候就必須要 32 位的 dll。驗(yàn)證當(dāng)前 JVM 位數(shù)在命令行運(yùn)行java -version如果輸出里帶 64-Bit 字樣那就是 64 位 JVM如果沒(méi)帶需要進(jìn)一步確認(rèn)。更穩(wěn)妥的方法是在 Java 代碼里打印系統(tǒng)屬性public class JvmArchCheck { public static void main(String[] args) { // os.arch 返回的是 JVM 架構(gòu)而不是操作系統(tǒng)架構(gòu) String arch System.getProperty(os.arch); System.out.println(JVM arch arch); // 常見(jiàn)輸出amd6464位、x8632位 } }代碼邏輯說(shuō)明System.getProperty(os.arch)拿到的是當(dāng)前 JVM 運(yùn)行時(shí)的架構(gòu)標(biāo)識(shí)。amd64代表 64 位x86代表 32 位。這個(gè)屬性是 JVM 啟動(dòng)時(shí)確定的不管你操作系統(tǒng)是什么版本JVM 是什么位數(shù)它就返回什么。參數(shù)說(shuō)明os.arch是系統(tǒng)屬性不是環(huán)境變量不需要額外配置。如果你在容器里跑 Java 應(yīng)用同樣以容器內(nèi) JVM 位數(shù)為準(zhǔn)別拿宿主機(jī)配置來(lái)判斷。我一般會(huì)在拿到 JCo 3 安裝包后的第一件事就是先跑這段代碼把位數(shù)確認(rèn)了再?zèng)Q定用哪個(gè) dll。這一步走錯(cuò)后面所有配置都白搭。2.2 目錄規(guī)劃與加載原理java.library.path 是怎么找 dll 的dll/so 文件并不是放進(jìn)項(xiàng)目的 resources 目錄就能被加載的。Java 通過(guò)System.loadLibrary()加載 native 庫(kù)搜索路徑由java.library.path系統(tǒng)屬性決定默認(rèn)情況下它會(huì)搜索當(dāng)前目錄、PATH環(huán)境變量包含的目錄以及 Windows 的System32目錄。很多教程推薦把 dll 丟進(jìn)System32這確實(shí)能跑通但不推薦。原因有三第一污染系統(tǒng)目錄卸載不干凈第二多個(gè)項(xiàng)目需要不同版本 dll 時(shí)會(huì)沖突第三服務(wù)器環(huán)境通常沒(méi)有 System32 的寫(xiě)權(quán)限。我常用的目錄結(jié)構(gòu)是這樣的D:\app-integration\ |-- lib\ | |-- sapjco3.jar | |-- sapjco3.dll # Windows 64位 | |-- sapjco3.so # Linux 64位如果部署到服務(wù)器 |-- bin\ | |-- start.bat # 啟動(dòng)腳本 |-- logs\啟動(dòng)腳本里通過(guò)-Djava.library.path指定 dll 所在目錄而不是依賴(lài)系統(tǒng) PATHjava -Djava.library.pathD:\app-integration\lib -cp D:\app-integration\lib\sapjco3.jar;D:\app-integration\bin com.example.MyJcoClient參數(shù)說(shuō)明-Djava.library.path指定 native 庫(kù)搜索路徑多個(gè)路徑用分號(hào)分隔Windows或冒號(hào)分隔Linux。-cp指定 classpathjar 包路徑必須包含在內(nèi)。這種做法的好處是項(xiàng)目自帶 runtime 環(huán)境換機(jī)器部署時(shí)只需要把整個(gè)目錄拷過(guò)去改一下路徑就行。2.3 最小安裝清單與驗(yàn)證命令完整的最小運(yùn)行環(huán)境包含以下部分缺一不可組件說(shuō)明備注JDK8 或 11 均可64 位 JDK 配 64 位 dllsapjco3.jarJava 側(cè) API放入 classpathsapjco3.dll / .sonative 連接庫(kù)通過(guò) -Djava.library.path 指定目標(biāo)系統(tǒng)連接信息應(yīng)用服務(wù)器地址、客戶(hù)端、賬號(hào)用于 JCoDestination 配置安裝完成后用 JCo 自帶的方法驗(yàn)證 native 庫(kù)是否加載成功import com.sap.conn.jco.JCo; public class JCoVersionCheck { public static void main(String[] args) { try { // JCo.getVersion() 返回版本信息能正常執(zhí)行說(shuō)明 native 庫(kù)已成功加載 System.out.println(JCo version: JCo.getVersion()); } catch (UnsatisfiedLinkError e) { // 拋出這個(gè)異常說(shuō)明 dll/so 沒(méi)找到或者位數(shù)不匹配 System.err.println(Native library load failed: e.getMessage()); } } }代碼邏輯說(shuō)明JCo.getVersion()是靜態(tài)方法內(nèi)部會(huì)觸發(fā) native 庫(kù)的初始化。如果這一步能正常輸出版本號(hào)說(shuō)明 jar 和 dll 的配對(duì)沒(méi)問(wèn)題。UnsatisfiedLinkError是典型的 native 加載失敗異常出現(xiàn)這個(gè)錯(cuò)誤時(shí)優(yōu)先檢查位數(shù)匹配和java.library.path路徑。運(yùn)行結(jié)果預(yù)期是輸出類(lèi)似 3.x 的版本號(hào)。如果這里過(guò)了環(huán)境搭建就算成功了。3. 第一個(gè)連接程序從 ClassPath 配置到 RFC 調(diào)用3.1 編寫(xiě)最小連接代碼環(huán)境就緒后下一步是寫(xiě)一個(gè)能真正連接目標(biāo)系統(tǒng)的程序。JCo 3 的編程模型核心接口是JCoDestination它代表一個(gè)可復(fù)用的連接配置。最簡(jiǎn)陋的寫(xiě)法是硬編碼配置import com.sap.conn.jco.JCoDestination; import com.sap.conn.jco.JCoDestinationManager; import com.sap.conn.jco.JCoException; public class SimplePing { public static void main(String[] args) { try { // 通過(guò)連接配置名稱(chēng)獲取 JCoDestination 實(shí)例 // 這個(gè)名稱(chēng)必須在配置文件里存在否則拋 JCoException JCoDestination dest JCoDestinationManager.getDestination(DEV_SYSTEM); // ping 目標(biāo)系統(tǒng)驗(yàn)證連接是否可用 dest.ping(); System.out.println(Connection successful!); // 獲取連接屬性打印出來(lái)確認(rèn)連的是哪套環(huán)境 System.out.println(Host: dest.getProperties().getString(jco.client.ashost)); System.out.println(Client: dest.getProperties().getString(jco.client.client)); } catch (JCoException e) { // JCoException 包含錯(cuò)誤碼關(guān)鍵信息在 e.getGroup() 和 e.getKey() System.err.println(Connection failed, error code: e.getGroup()); System.err.println(Error key: e.getKey()); e.printStackTrace(); } } }代碼邏輯說(shuō)明JCoDestinationManager.getDestination()根據(jù)名稱(chēng)查找配置文件里定義的連接返回的JCoDestination是線(xiàn)程安全的可以復(fù)用到多個(gè)線(xiàn)程。dest.ping()向目標(biāo)系統(tǒng)發(fā)送一個(gè)輕量級(jí)探測(cè)包用來(lái)確認(rèn)網(wǎng)絡(luò)和登錄配置是否正常這是排查連接問(wèn)題最直接的手段。參數(shù)說(shuō)明DEV_SYSTEM是連接配置名來(lái)源于下面的屬性文件不是隨便起的名。getProperties()返回該連接的完整屬性集合調(diào)試時(shí)可以用它快速確認(rèn)當(dāng)前連接用的是哪臺(tái)服務(wù)器、哪個(gè)客戶(hù)端。3.2 連接參數(shù)詳解從屬性文件到連接池參數(shù)實(shí)際項(xiàng)目中不會(huì)把連接信息硬編碼在 Java 代碼里。JCo 3 的標(biāo)準(zhǔn)做法是用屬性文件文件名格式是[配置名].jcoDestination放在 classpath 下。例如上面代碼里的DEV_SYSTEM對(duì)應(yīng)創(chuàng)建一個(gè)文件名為DEV_SYSTEM.jcoDestination的文件# 目標(biāo)系統(tǒng)應(yīng)用服務(wù)器地址 jco.client.ashost192.168.1.20 # 系統(tǒng)編號(hào)用于計(jì)算連接端口 jco.client.sysnr00 # 網(wǎng)關(guān)服務(wù)端口一般不需要手動(dòng)指定 jco.client.gwserv # 客戶(hù)端編號(hào)三位數(shù)字 jco.client.client800 # 登錄賬號(hào) jco.client.userINTEGRATION_USER # 登錄密碼 jco.client.passwdSecret123 # 語(yǔ)言代碼ZH 或 EN jco.client.langZH # 連接池最大連接數(shù)超過(guò)這個(gè)數(shù)系統(tǒng)會(huì)排隊(duì)等待 jco.dest.pool_capacity10 # 單連接最大并發(fā)請(qǐng)求數(shù) jco.dest.peak_limit10 # 連接池回收時(shí)間單位毫秒 jco.dest.expiration_time300000 # 連接過(guò)期策略默認(rèn)是池內(nèi)連接按空閑時(shí)間回收 jco.dest.expiration_check_period60000參數(shù)說(shuō)明jco.client.ashost和jco.client.sysnr是必填項(xiàng)系統(tǒng)會(huì)根據(jù)sysnr自動(dòng)計(jì)算 RFC 端口號(hào)端口號(hào)公式為3xx00xx 是系統(tǒng)編號(hào)常見(jiàn)的是3300和3600。jco.client.client是三位數(shù)客戶(hù)端號(hào)登錄時(shí)必須匹配。jco.dest.pool_capacity和jco.dest.peak_limit分別控制連接池總量和單連接并發(fā)量這兩個(gè)參數(shù)對(duì)并發(fā)調(diào)用影響很大后面單獨(dú)講。屬性文件必須放在 classpath 路徑下如果放在 resources 目錄構(gòu)建時(shí)會(huì)自動(dòng)打包進(jìn) jar。也可以用-Djco.destinations.dev_systempath/to/file的方式外部指定但常規(guī)項(xiàng)目用 classpath 就夠了。3.3 調(diào)用 BAPI 與 RFC 函數(shù)的基本流程連接通了之后實(shí)際業(yè)務(wù)調(diào)用通常分兩步調(diào)用系統(tǒng)自帶函數(shù)做連通性測(cè)試再調(diào)用自定義 RFC 函數(shù)獲取業(yè)務(wù)數(shù)據(jù)。連通性測(cè)試常用系統(tǒng)函數(shù)RFC_PING和BAPI_USER_GET_DETAIL用法如下import com.sap.conn.jco.*; public class RfcCallExample { public static void main(String[] args) throws JCoException { JCoDestination dest JCoDestinationManager.getDestination(DEV_SYSTEM); // 第一步獲取目標(biāo)系統(tǒng)函數(shù)模板 JCoFunction function dest.getRepository().getFunction(BAPI_USER_GET_DETAIL); if (function null) { throw new RuntimeException(Function not found in remote system); } // 第二步設(shè)置導(dǎo)入?yún)?shù)用戶(hù)名是必輸項(xiàng) function.getImportParameterList().setValue(USERNAME, INTEGRATION_USER); // 第三步執(zhí)行調(diào)用內(nèi)部走 RFC 協(xié)議 function.execute(dest); // 第四步檢查返回結(jié)構(gòu) JCoStructure returnStruct function.getExportParameterList().getStructure(RETURN); String type returnStruct.getString(TYPE); if (E.equals(type) || A.equals(type)) { // E 代表錯(cuò)誤A 代表異常終止 System.err.println(Call failed: returnStruct.getString(MESSAGE)); } else { // 第五步讀取業(yè)務(wù)數(shù)據(jù) JCoFieldIterator it function.getExportParameterList().getFieldIterator(); while (it.hasNextField()) { JCoField field it.nextField(); System.out.println(field.getName() field.getValue()); } } } }代碼邏輯說(shuō)明調(diào)用 RFC 函數(shù)的流程是固定的四步從destination.getRepository()獲取函數(shù)元數(shù)據(jù)模板設(shè)置導(dǎo)入?yún)?shù)執(zhí)行execute(dest)然后從導(dǎo)出參數(shù)中取返回值。RETURN結(jié)構(gòu)是所有 BAPI 函數(shù)的統(tǒng)一返回格式TYPE字段值為S成功、E錯(cuò)誤、W警告、A異常終止。處理業(yè)務(wù)返回前必須先看TYPE不要盲目從參數(shù)里取數(shù)據(jù)這是經(jīng)驗(yàn)之談。參數(shù)說(shuō)明getImportParameterList().setValue(USERNAME, ...)設(shè)置函數(shù)導(dǎo)入?yún)?shù)getExportParameterList().getStructure(RETURN)獲取返回結(jié)構(gòu)體。如果函數(shù)參數(shù)名拼錯(cuò)JCo 會(huì)在運(yùn)行時(shí)拋JCoRuntimeException提示 field not found這是排查參數(shù)名問(wèn)題的關(guān)鍵線(xiàn)索。4. JCoDestination 進(jìn)階用法連接池、線(xiàn)程安全與異常分類(lèi)4.1 自定義連接工廠與連接池參數(shù)調(diào)優(yōu)JCo 3 默認(rèn)的連接池管理由框架自己控制但生產(chǎn)環(huán)境里我一般會(huì)做一個(gè)輕量封裝把連接配置外部化同時(shí)加上監(jiān)控。核心點(diǎn)是理解兩個(gè)關(guān)鍵參數(shù)pool_capacity和peak_limit。這兩個(gè)參數(shù)的關(guān)系容易混淆。pool_capacity是連接池里最多存放的空閑連接數(shù)peak_limit是單個(gè)物理連接上能同時(shí)執(zhí)行的并發(fā)請(qǐng)求數(shù)量。假設(shè)pool_capacity10、peak_limit10理論最大并發(fā)量是 100。但如果每個(gè)請(qǐng)求都很快毫秒級(jí)10 個(gè)物理連接足夠支撐幾十個(gè)線(xiàn)程并發(fā)如果請(qǐng)求里有慢事務(wù)秒級(jí)或分鐘級(jí)就要適當(dāng)調(diào)大peak_limit和pool_capacity。我一般會(huì)封裝一個(gè)簡(jiǎn)單的連接管理類(lèi)import com.sap.conn.jco.JCoDestination; import com.sap.conn.jco.JCoDestinationManager; import com.sap.conn.jco.JCoException; public class DestinationProvider { // 使用 volatile 確保多線(xiàn)程下可見(jiàn)性 private static volatile JCoDestination dest; private DestinationProvider() { } // 雙重檢查鎖單例模式避免重復(fù)創(chuàng)建 JCoDestination public static JCoDestination getDestination() throws JCoException { if (dest null) { synchronized (DestinationProvider.class) { if (dest null) { dest JCoDestinationManager.getDestination(DEV_SYSTEM); } } } return dest; } // 獲取當(dāng)前連接池狀態(tài)監(jiān)控用 public static String getPoolStatus() { // JCoDestinationManager.getDestination 返回的對(duì)象內(nèi)部包含連接池統(tǒng)計(jì) return dest.toString(); } }代碼邏輯說(shuō)明JCoDestination實(shí)例是線(xiàn)程安全的內(nèi)部有連接池管理不需要每次調(diào)用都重新創(chuàng)建。用單例模式包裝后全局共享一個(gè)JCoDestination就夠了。volatile加雙重檢查鎖是為了防止并發(fā)下重復(fù)初始化。參數(shù)說(shuō)明pool_capacity、peak_limit的合理值需要結(jié)合目標(biāo)系統(tǒng)的 RFC 網(wǎng)關(guān)線(xiàn)程上限來(lái)定。一般建議pool_capacity設(shè)置在 5 到 20 之間peak_limit設(shè)置在 5 到 30 之間。過(guò)大的連接池會(huì)占用目標(biāo)系統(tǒng)側(cè)的 RFC 線(xiàn)程資源反而拖慢整體性能。4.2 長(zhǎng)事務(wù)與事務(wù)邊界處理RFC 調(diào)用默認(rèn)是同步短事務(wù)模式每一個(gè)execute()調(diào)用獨(dú)立提交。但有些業(yè)務(wù)場(chǎng)景需要在一個(gè)事務(wù)里連續(xù)調(diào)用多個(gè)函數(shù)要么全部成功要么全部回滾。JCo 3 提供了事務(wù)支持但很多人沒(méi)用對(duì)。import com.sap.conn.jco.*; public class TransactionExample { public static void main(String[] args) { JCoDestination dest JCoDestinationManager.getDestination(DEV_SYSTEM); // 創(chuàng)建事務(wù)上下文所有函數(shù)調(diào)用會(huì)綁定到這個(gè)事務(wù)上 JCoContext.begin(dest); try { // 第一個(gè)調(diào)用 JCoFunction f1 dest.getRepository().getFunction(BAPI_GOODSMVT_CREATE); f1.getImportParameterList().setValue(DOCUMENTHEADER, createDocumentHeader()); f1.execute(dest); // 第二個(gè)調(diào)用 JCoFunction f2 dest.getRepository().getFunction(BAPI_TRANSACTION_COMMIT); f2.getImportParameterList().setValue(WAIT, X); f2.execute(dest); } catch (JCoException e) { // 出錯(cuò)時(shí)回滾事務(wù) JCoFunction rollback dest.getRepository().getFunction(BAPI_TRANSACTION_ROLLBACK); rollback.execute(dest); System.err.println(Transaction rolled back: e.getKey()); } finally { // 結(jié)束事務(wù)上下文釋放連接 JCoContext.end(dest); } } }代碼邏輯說(shuō)明JCoContext.begin(dest)開(kāi)啟一個(gè)事務(wù)上下文之后的函數(shù)調(diào)用都進(jìn)入同一個(gè) RFC 會(huì)話(huà)直到JCoContext.end(dest)結(jié)束。在這個(gè)上下文里的所有調(diào)用必須顯式提交或回滾常見(jiàn)做法是最后調(diào)BAPI_TRANSACTION_COMMIT提交出異常時(shí)調(diào)BAPI_TRANSACTION_ROLLBACK回滾。關(guān)鍵注意點(diǎn)事務(wù)上下文開(kāi)啟期間JCo 會(huì)獨(dú)占一個(gè)物理連接不會(huì)再?gòu)倪B接池分配其他連接給這個(gè)請(qǐng)求。也就是說(shuō)事務(wù)內(nèi)的所有調(diào)用用的是同一個(gè)后端會(huì)話(huà)這是保證事務(wù)一致性的前提。忘記調(diào)用JCoContext.end()會(huì)導(dǎo)致連接泄漏這是生產(chǎn)環(huán)境最常見(jiàn)的坑之一。4.3 異常分類(lèi)與處理策略JCo 3 的異常體系不算復(fù)雜但分類(lèi)邊界值得說(shuō)清楚異常類(lèi)觸發(fā)場(chǎng)景處理策略JCoException連接失敗、登錄失敗、函數(shù)不存在檢查網(wǎng)絡(luò)、賬號(hào)權(quán)限、函數(shù)名拼寫(xiě)AbapException目標(biāo)系統(tǒng)業(yè)務(wù)邏輯報(bào)錯(cuò)從RETURN結(jié)構(gòu)中取具體錯(cuò)誤消息JCoRuntimeException參數(shù)類(lèi)型錯(cuò)誤、字段不存在檢查代碼里的字段名是否拼寫(xiě)正確UnsatisfiedLinkErrordll 加載失敗、位數(shù)不匹配重新檢查環(huán)境配置處理異常時(shí)的統(tǒng)一原則區(qū)分系統(tǒng)異常和業(yè)務(wù)異常。JCoException是連接層問(wèn)題重試沒(méi)有意義應(yīng)該報(bào)警AbapException是業(yè)務(wù)層拒絕需要根據(jù)錯(cuò)誤消息調(diào)整參數(shù)或流程。try { function.execute(dest); } catch (AbapException e) { // AbapException 表示目標(biāo)系統(tǒng)主動(dòng)返回了錯(cuò)誤結(jié)構(gòu) JCoStructure keyData e.getKey(); System.err.println(Business error, type: keyData.getString(TYPE)); } catch (JCoException e) { // JCoException 表示連接或通信層出了問(wèn)題 if (e.getGroup() JCoException.GROUP_COMMUNICATION) { System.err.println(Network issue, retry later); } else if (e.getGroup() JCoException.GROUP_APPLICATION) { System.err.println(Application error, check auth); } }代碼邏輯說(shuō)明AbapException和JCoException是兩個(gè)獨(dú)立的異常層級(jí)前者對(duì)應(yīng)業(yè)務(wù)錯(cuò)誤后者對(duì)應(yīng)技術(shù)錯(cuò)誤。e.getKey()返回的是目標(biāo)系統(tǒng)返回的錯(cuò)誤詳情結(jié)構(gòu)體包含類(lèi)型、消息、消息號(hào)等信息。e.getGroup()提供更細(xì)粒度的錯(cuò)誤分組GROUP_COMMUNICATION表示通信故障GROUP_APPLICATION表示目標(biāo)系統(tǒng)側(cè)的應(yīng)用程序錯(cuò)誤。5. 避坑專(zhuān)題裝完連不上的五個(gè)典型踩坑記錄5.1 64 位 JDK 配 32 位 dll加載時(shí)報(bào)錯(cuò)現(xiàn)象程序啟動(dòng)時(shí)報(bào)UnsatisfiedLinkError: sapjco3.dll: Cant load AMD 64-bit .dll on a IA 32-bit platform或者反過(guò)來(lái)報(bào)Cant load IA 32-bit .dll on a AMD 64-bit platform。原因jar 包不分位數(shù)但 native 庫(kù)嚴(yán)格區(qū)分。安裝包里的 dll 是 32 位還是 64 位可以在文件屬性里查看或者看文件大小通常 64 位版本稍大。最常見(jiàn)的翻車(chē)場(chǎng)景是服務(wù)器是 64 位 Windows默認(rèn)以為要用 64 位 dll但項(xiàng)目里 JDK 實(shí)際是 32 位。解決先跑第 2 章里的JvmArchCheck確認(rèn) JVM 位數(shù)然后從安裝包里選擇匹配的 dll。如果項(xiàng)目用的是 32 位 JDK換 64 位 JDK 時(shí)還要檢查是否有第三方依賴(lài)同樣存在位數(shù)限制。5.2 classloader 重復(fù)加載導(dǎo)致 native library 沖突現(xiàn)象同一 JVM 里多個(gè) web 應(yīng)用都引用了 sapjco3.jar 和 dll啟動(dòng)第二個(gè)應(yīng)用時(shí)報(bào)java.lang.UnsatisfiedLinkError: native library already loaded in another classloader。原因Java 的 native 庫(kù)加載機(jī)制要求同一個(gè) JVM 進(jìn)程中一個(gè) native 庫(kù)只能被加載一次。web 容器里每個(gè) webapp 有自己的 classloader第一個(gè)應(yīng)用加載了 dll 之后第二個(gè)應(yīng)用再次加載就會(huì)報(bào)沖突。解決把 sapjco3.jar 放到 web 容器的公共 lib 目錄如 Tomcat 的lib/而不是放在每個(gè)應(yīng)用的WEB-INF/lib下。如果容器不支持公共 classloader就做一個(gè)單獨(dú)的獨(dú)立服務(wù)把 JCo 調(diào)用包成 HTTP 接口讓業(yè)務(wù)系統(tǒng)通過(guò)接口調(diào)用這樣能徹底規(guī)避 classloader 沖突。5.3 連接成功但中文亂碼現(xiàn)象調(diào)用BAPI_USER_GET_DETAIL時(shí)返回的用戶(hù)名稱(chēng)字段顯示為亂碼但英文內(nèi)容正常。原因jco.client.langZH設(shè)置了中文語(yǔ)言代碼但目標(biāo)系統(tǒng)的代碼頁(yè)codepage與 Java 側(cè)的字符編碼不一致。目標(biāo)系統(tǒng)一般用 UTF-8 封裝傳輸默認(rèn)代碼頁(yè)是 4103UTF-8或 1100Latin-1如果不匹配就會(huì)亂碼。解決確認(rèn)連接屬性里設(shè)置jco.client.langZH同時(shí)檢查目標(biāo)系統(tǒng)側(cè)的 profile 參數(shù)rdisp/codepage是否為 4103。如果是舊系統(tǒng)用的非 Unicode 代碼頁(yè)Java 側(cè)需要在讀取字符串后手動(dòng)做編碼轉(zhuǎn)換但這屬于最后手段優(yōu)先推動(dòng)目標(biāo)系統(tǒng)啟用 UTF-8。5.4 網(wǎng)關(guān)連接被拒PING 失敗現(xiàn)象dest.ping()拋出JCoException錯(cuò)誤組GROUP_COMMUNICATION錯(cuò)誤信息里能看到類(lèi)似connection refused的字樣。原因目標(biāo)系統(tǒng)的 RFC 網(wǎng)關(guān)沒(méi)有啟動(dòng)或者防火墻屏蔽了 RFC 端口。sysnr對(duì)應(yīng)的端口計(jì)算錯(cuò)了也會(huì)導(dǎo)致這個(gè)問(wèn)題例如sysnr00對(duì)應(yīng)端口是3300sysnr01是3301以此類(lèi)推。解決在命令行測(cè)試端口連通性用telnet或nc# 假設(shè)系統(tǒng)編號(hào) 00端口號(hào)為 3300 nc -zv 192.168.1.20 3300如果端口不通檢查目標(biāo)系統(tǒng)網(wǎng)關(guān)進(jìn)程是否啟動(dòng)、防火墻是否放行。nc -vz的z參數(shù)表示只掃描不發(fā)送數(shù)據(jù)v顯示詳細(xì)信息。如果端口通了但 ping 仍失敗就需要檢查目標(biāo)系統(tǒng)側(cè)的賬號(hào)鎖定狀態(tài)或權(quán)限參數(shù)。5.5 jar 包與 dll 版本混用現(xiàn)象程序能正常加載 native 庫(kù)但調(diào)用函數(shù)時(shí)拋JCoRuntimeException提示version mismatch或函數(shù)執(zhí)行失敗。原因某次升級(jí)時(shí)只替換了 jar 包沒(méi)同步替換 dll。JCo 3 的 jar 和 dll 是配套發(fā)布的兩者之間有版本匹配校驗(yàn)混用時(shí)會(huì)拋錯(cuò)。解決始終保持 jar 與 dll 從同一次發(fā)布中獲取。下載時(shí)選擇完整包不要從不同渠道拼接文件。如果項(xiàng)目里多個(gè)模塊引用了不同來(lái)源的 JCo 版本建議統(tǒng)一到同一個(gè)版本并檢查依賴(lài)樹(shù)里是否有傳遞依賴(lài)引入舊版本。6. 調(diào)優(yōu)與驗(yàn)證從能連上到穩(wěn)定不崩上線(xiàn)前必走的五步檢查連接跑通只是第一步生產(chǎn)環(huán)境要的是穩(wěn)定。我在每次上線(xiàn)前都會(huì)強(qiáng)制自己過(guò)一遍下面這五步這套流程幫我排掉過(guò)不少潛在問(wèn)題現(xiàn)在也分享出來(lái)。第一驗(yàn)證連接池參數(shù)與并發(fā)量的匹配關(guān)系。用JCoDestinationManager.getDestination()拿到連接后打印toString()確認(rèn)pool_capacity和peak_limit的實(shí)際生效值。再用壓測(cè)工具模擬并發(fā)請(qǐng)求觀察目標(biāo)系統(tǒng)側(cè)是否會(huì)報(bào) RFC 線(xiàn)程資源不足。如果并發(fā)超過(guò)預(yù)期先調(diào)連接池參數(shù)不要急著改代碼。第二開(kāi)啟 JCo 運(yùn)行時(shí)日志。按屬性配置的方式更簡(jiǎn)單加一個(gè)系統(tǒng)屬性jco.runtime.logDEBUG但注意啟動(dòng)后輸出量非常大只建議在排障時(shí)短時(shí)間開(kāi)啟。java -Djco.runtime.logDEBUG -Djava.library.pathD:\app-integration\lib -cp D:\app-integration\lib\sapjco3.jar;D:\app-integration\bin com.example.MyJcoClient-Djco.runtime.log是 JCo 框架自帶的日志開(kāi)關(guān)DEBUG級(jí)別會(huì)打印每個(gè) RFC 請(qǐng)求的發(fā)送與響應(yīng)內(nèi)容。生產(chǎn)環(huán)境不要開(kāi)調(diào)試時(shí)開(kāi)完立即關(guān)掉。第三檢查連接池是否有泄漏。重點(diǎn)排查事務(wù)代碼塊里有沒(méi)有遺漏JCoContext.end()。經(jīng)驗(yàn)值是觀察程序運(yùn)行一段時(shí)間后目標(biāo)系統(tǒng)的SMGW事務(wù)里 RFC 連接數(shù)是否持續(xù)增長(zhǎng)如果是說(shuō)明代碼里存在連接未釋放的問(wèn)題。第四驗(yàn)證異常分支的日志完整性。故意用一個(gè)不存在的函數(shù)名跑一次調(diào)用確認(rèn)日志里能記錄到JCoException且不會(huì)導(dǎo)致主線(xiàn)程崩潰。再故意用一個(gè)無(wú)權(quán)限的賬號(hào)跑一次登錄確認(rèn)日志里能看到GROUP_APPLICATION類(lèi)型的錯(cuò)誤。這兩條分支不驗(yàn)證生產(chǎn)環(huán)境第一次出問(wèn)題時(shí)現(xiàn)場(chǎng)日志往往不足以定位。第五觸發(fā)一次真實(shí)的連接中斷測(cè)試。在程序運(yùn)行期間手動(dòng)停掉目標(biāo)系統(tǒng)的網(wǎng)關(guān)進(jìn)程觀察 Java 程序側(cè)的表現(xiàn)連接池里的連接會(huì)不會(huì)自動(dòng)失效下一次調(diào)用會(huì)不會(huì)重新建立連接正常情況下目標(biāo)系統(tǒng)不可達(dá)時(shí)execute()會(huì)拋出JCoException代碼里要做捕獲和重試。沒(méi)有這個(gè)分支線(xiàn)上突然斷一次網(wǎng)整個(gè)服務(wù)就要重啟才能恢復(fù)。從那以后我每次切換環(huán)境或者升級(jí) JCo 版本都會(huì)強(qiáng)制走一遍這五步檢查寧可多花半小時(shí)驗(yàn)證也不愿上線(xiàn)后半夜被電話(huà)叫醒。這套流程不只是為了 JCo連接外部系統(tǒng)的中間件項(xiàng)目都值得這樣過(guò)一遍。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取