【附高併發全解析】為什麼SAP B1 跑超慢？原來是API 卡頓！

文／工程師 Kim

五分鐘帶企業成長

很多企業導入 SAP B1後，第一個痛點不是報表、也不是流程，而是「為什麼API會卡？SAP每一次呼叫都會經過完整的授權驗證、交易鎖定、資料一致性檢查。這些特性雖確保穩定，但也導致單一連線無法支撐大量同時請求。

為什麼SAP B1 跑超慢？要怎麼解決？詳解高併發（High Concurrency）

舉例來說，如果你開了一個 API，讓電商、倉庫與會計同時下訂單或查庫存，而這些請求都透過同一個 SAP Session 進行，那就像只有一條收銀台，顧客再多也得一個個排隊。這時候，「高併發架構」就登場了。

高併發（High Concurrency）是系統能同時處理多個請求，而不會互相等待或阻塞。簡單來說，單一 Company 物件是「一個窗口」；高併發架構是「多個窗口一起開放服務」。

在 SAP 的情境中，高併發（High Concurrency）有三個重要的功用：

SAP Business One 的 API 核心是 DI API（Data Interface API），它透過 COM 元件（Component Object Model）方式與 SAP Client 溝通。

也就是說，一個授權（License）對應一個連線通道。如果 API 都搶著用同一個授權登入，就會互相等待、鎖死，導致效能瓶頸。當應用程式透過 Company 物件連線到 SAP 時：

高併發在 SAP 的世界裡，實際上是「多授權 + 多 Company + 多執行緒」的組合。

常見實作步驟如下：

建立授權池（License Pool）
- 預先建立多個 Company 物件，分別以不同授權登入（如 B1User1、B1User2、B1User3…）。
建立 Thread Pool（執行緒池）
- 每個授權對應一個 STA Thread，確保 COM 元件不跨執行緒存取。
- API 請求進來時，動態分配到空閒的 Company。
控制併發數與排程
- 使用任務佇列（Queue）或 Dictionary 追蹤每個連線狀態。
- 若全滿則排隊，避免超過 SAP Server 處理極限。
回收與監控
- 定期檢查連線健康狀況。

應用場景	傳統單連線	高併發架構
電商訂單匯入每日庫存同步財務對帳報表產生	一次只能處理1筆訂單需分批執行、時間長等前一筆完成報表延遲數分鐘	同時處理10筆以上訂單可並行查詢多倉庫平行處理不同帳號可即時回傳部分結果

結果：同樣的 SAP Server，高併發架構處理效率可提升數倍。

以 SAP Business One 為例，授權類型主要有：

授權種類	用途	備註
Professional License	完整功能（會計、採購、銷售、庫存）	一般建議給系統整合用戶使用
Limited License (Financial / Logistics / CRM)	單模組授權	適合只需查詢或寫入特定模組的 API
Indirect Access / Integration User	專為系統整合（API）設計	不需人員登入，專門給 WebAPI 使用

💡 一般企業若要建立高併發 API（10～20 同時連線），可考慮購買 5～10 個Integration License，搭配連線池機制，就能支撐每日上千筆交易。

SAP 的 COM 元件在設計上是「一對一連線模型」，主要有以下三個特徵：

因此，要達到高併發，就必須執行這三件事，才能真正做到 SAP 的「多線程交易」：

SAP 高併發架構的核心不在硬體多強大，而是「多授權 + 多執行緒 + 智慧排程」。理解 COM 元件的一對一限制後，就能用程式思維突破 SAP 的封閉瓶頸，讓企業在保持穩定性的同時，真正達到數位整合與高速運算。

擴充彈性高

只要新增授權與 Company 實例，即可水平擴充，不需重構架構。

【加入 Jetwell 會員】你將獲得最新的產業洞見、趨勢預測及專家建議，我們有市場領先的專業 ERP／CRM 顧問，每月精彩好文直送你的信箱。