遇到的問題
SM04中看到有部分JCO調(diào)用的RFC的會話無法釋放，極端情況導(dǎo)致所有第三方系統(tǒng)基于RFC的方式，都無法訪問SAP。
解決方案
問題原因沒有定位到，其實(shí)也算不上解決
在確認(rèn)調(diào)用方代碼沒問題后，在SAP服務(wù)器端做了一些優(yōu)化
- SAP推薦升級Kernel，出于風(fēng)險沒有采納
- 對于特別耗性能的RFC系列接口
- 優(yōu)化處理邏輯
- 減少調(diào)用、甚至不調(diào)用
- 過期會話，自動刪除
自開發(fā)程序，定期執(zhí)行，記錄日志，在哪些接口上掛起了。 稍微一統(tǒng)計(jì)，就能識別哪個系統(tǒng)，哪些接口會導(dǎo)致問題。
RFC技術(shù)分析
正常的會話
可以通過參數(shù)設(shè)定多少時間后logout，比如rdisp/gui_auto_logout
RFC的會話
服務(wù)器端不會自動釋放
個人猜測，RFC技術(shù)是很多其他技術(shù)的基礎(chǔ)，比如ALE、iDoc，SAP在設(shè)計(jì)的時候就沒有考慮去中斷RFC的會話。只要調(diào)用端不主動釋放，會話會一直被保持。
這里不討論RFC調(diào)用時，分配了Work Process且一直在執(zhí)行中，最后因?yàn)檫_(dá)到Work Process最大允許時間而被迫釋放的場景。
JCO的會話管理
- 不使用連接池
調(diào)用完即釋放 - 使用連接池
調(diào)用完后，繼續(xù)放到連接池中。連接池中的另一個線程會定時檢查池中的連接，若連接達(dá)到指定的時間未被使用，由該線程執(zhí)行釋放。
1.這里討論的是stateless的JCO 3.0 訪問方式 。
2.經(jīng)常在SM04看到，連接池調(diào)用的會話保存一段時間后再消失，就很容理解。
掛起場景猜測
以下場景都是個人猜測
- 調(diào)用端突然中斷
比如網(wǎng)絡(luò)異常
RFC通常都是第三方服務(wù)器發(fā)起，請求SAP RFC接口，服務(wù)器之間網(wǎng)絡(luò)異常比較少。但是以前在搞ITS時頻繁遇到類似問題（ITS和RFC是兩個東西），手持設(shè)備直接訪問SAP ITS服務(wù)，倉庫之間切換AP，導(dǎo)致SM04中看到會話掛起，這個和ITS的版本也有關(guān)系。
- JCO 2.0中訪問沒有主動釋放
- JCO 3.0有狀態(tài)調(diào)用沒有主動close
- SAP服務(wù)器端異常
歸根到底因?yàn)镾AP Kernal在特定場景下，無法重置當(dāng)前會話狀態(tài)(比如標(biāo)識此RFC函數(shù)已經(jīng)調(diào)用結(jié)束)，導(dǎo)致調(diào)用端無法回收，SM04中看到就是長時間掛起。
- Kernal 問題，SAP自己產(chǎn)品的Bug
感覺這次遇到的問題類似這個場景，RFC中的代碼邏輯，無論CPU處理還是DB取值都比較麻煩，并且函數(shù)內(nèi)部有submit和call transaction之類的調(diào)用，可能特定條件觸發(fā)了會話管理異常，無法標(biāo)識調(diào)用結(jié)束？
- 內(nèi)部工作過程掛起
比如Dialog WP 等待 DB WP，DB WP因?yàn)閿?shù)據(jù)庫服務(wù)器問題，沒有響應(yīng)，導(dǎo)致Dialog WP也沒有響應(yīng)，表現(xiàn)為SM04中會話掛起
總結(jié)
- RFC會話服務(wù)器端不會主動去關(guān)閉
- 誰調(diào)用誰關(guān)閉
- 關(guān)閉的前提： 服務(wù)器端已標(biāo)識RFC執(zhí)行完畢
所以面對SM04無法釋放的會話，調(diào)用方和SAP服務(wù)器都可能背鍋。
