https://yennj12.js.org/yennj12_blog_V4/tags/legacy/Recent content in Legacy on YennJ12 Engineering BlogHugo -- gohugo.ioen-usFri, 05 Jun 2026 15:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part37-legacy-integration-zh/Fri, 05 Jun 2026 15:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part37-legacy-integration-zh/Demo 時 Agent 很漂亮。 到客戶現場才發現：資料在 SAP（文件很爛）、Oracle（只有 DB 直連）、 還有一個每天凌晨 2 點才匯出的 CSV 檔案。 「連接組織」，是 FDE 和 AI 工程師最核心的差距之一。 面試情境 面試官：「客戶是一家有 30 年歷史的製造業。資料在三個地方：SAP ERP（有 REST API 但文件很爛）、Oracle 資料庫（只有 DB 直連）、一個每天從 mainframe 匯出的 CSV。他們希望 AI 能回答：庫存狀況、哪個供應商交期有問題。你怎麼設計這個整合層？」 一、問題本質：Legacy 整合的三種挑戰 Demo 的 Tool： def get_inventory(item_id: str) -> dict: return requests.get(f"https://api.example.com/inventory/{item_id}") 客戶現場的現實： SAP API： ├── 認證：OAuth + Client Certificate（文件在某個 Confluence 頁面，過期了） ├── Rate Limit：10 req/sec per user（AI 可能觸發 100 并發） ├── 回傳格式：200 欄位的 XML（Agent 只需要 5 個） └── 錯誤碼：自定義的 SAP 錯誤碼（不是標準 HTTP） Oracle DB： ├── 沒有 API，只能 JDBC/ODBC 直連 ├── 沒有任何文件，Schema 要靠 DBA 解釋 └── 有 SQL Injection 和 full table scan 的風險 Mainframe CSV： ├── 每天凌晨 2 點才有新資料（不是即時） ├── 格式偶爾會改變（沒有版本控制） └── 直接讀大 CSV 到 context = token 爆炸 這三個資料來源，需要三種不同的整合模式。 二、整合模式選型框架 選型決策矩陣： 資料來源特性 → 建議整合模式 ────────────────────────────────────────────────────────────── 有 API，但設計複雜 → API 橋接層 （認證複雜、格式冗餘、Rate Limit） ────────────────────────────────────────────────────────────── 只有 DB 直連，沒有 API → 資料庫查詢層（Stored Procedure） ────────────────────────────────────────────────────────────── 批次檔案（CSV、Excel） → 批次攝取 Pipeline（GCS → BigQuery） ────────────────────────────────────────────────────────────── 即時串流資料 → Pub/Sub → BigQuery → Agent Query ────────────────────────────────────────────────────────────── 三種模式的系統特性對比： 模式 延遲 資料新鮮度 設計複雜度 適用場景 ────────────────────────────────────────────────────────────── API 橋接層 低（ms） 即時 高 SAP 庫存查詢 ────────────────────────────────────────────────────────────── DB 查詢層 中（ms） 即時 中 Oracle 訂單狀態 ────────────────────────────────────────────────────────────── 批次攝取 Pipeline 秒-分 T+1（次日） 低 Mainframe 月報 ────────────────────────────────────────────────────────────── 製造業客戶的對應： SAP → API 橋接層 Oracle → DB 查詢層 Mainframe CSV → 批次攝取 Pipeline 三、模式一：API 橋接層設計 設計目標：隱藏 SAP API 的所有複雜性， 讓 Agent Tool 看到的是簡單、穩定的介面。 架構： ┌──────────────────────────────────────────────────────────────┐ │ ADK Agent │ │ def get_inventory(item_id, warehouse) → dict │ │ （Agent 只看到這個簡單函數） │ └──────────────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ SAP Adapter Service（你寫的橋接層） │ │ │ │ ├── 認證管理 │ │ │ Secret Manager 取 OAuth token + Client Certificate │ │ │ Token 自動更新（expiry 前 5 分鐘刷新） │ │ │ │ │ ├── Rate Limiting（Token Bucket，10 req/sec） │ │ │ 超過上限的請求排隊等待，設定 queue timeout = 5s │ │ │ │ │ ├── 格式轉換 │ │ │ 200 欄位 XML → 5 欄位 JSON │ │ │ {available_qty, unit, location, last_updated, status} │ │ │ │ │ ├── Response Cache（Redis，TTL 5 分鐘） │ │ │ 相同 item_id+warehouse 的查詢，5 分鐘內走 Cache │ │ │ │ │ └── 錯誤處理 │ │ HTTP 429 / SAP-specific 錯誤碼 → 統一轉換成 Retry 或 │ │ 結構化錯誤訊息（Agent 能理解的格式） │ └──────────────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ SAP REST API（原始系統） │ │ 認證複雜、格式冗餘、Rate Limit 10 req/sec │ └──────────────────────────────────────────────────────────────┘ Cache 的效益： 假設有 80% 的查詢是重複的相同 item_id： SAP API 實際呼叫量降低 80%，Rate Limit 問題基本消失。 對 SAP 系統的壓力大幅降低，減少影響生產系統的風險。 四、模式二：資料庫查詢層（Stored Procedure） 核心安全問題：Agent 不能直接生成 SQL 並執行。 風險分析： ❌ 直接讓 Agent 生成 SQL： Agent: SELECT * FROM orders WHERE supplier = '{user_input}' 攻擊者輸入：' OR 1=1; DROP TABLE orders; -- → SQL Injection，資料庫損毀 ❌ 直接 SELECT *： 對大型 Oracle 表的 full table scan 可能讓生產資料庫效能崩潰 ✅ 正確設計：Stored Procedure 層 架構： ADK Agent Tool def get_supplier_delivery(supplier_id, date_from, date_to) │ │ 呼叫預定義的 Stored Procedure ▼ Oracle DB EXEC sp_GetSupplierDelivery(?