跳轉到

ADR 0065 — 集中自動化庫 darbnogiauto1 + 排程專屬派發器 DARB_LOG_SYS_SKD_EXEC

  • 日期：2026-06-28
  • 狀態：Accepted
  • 決策者：使用者
  • 相關：ADR 0009、ADR 0015、ADR 0018、AI 查詢派發器（DARB_LOG_SYS_AI_EXEC / log_sys_ai）

Context

排程/自動化相關的預存程序原本散在公司庫 darbnogicsa1，由 log 庫 darbnogilog1 的共用 派發器 DARB_LOG_SYS_EXEC（路由全系統 ~400 支 proc、寫共用 log_sys 稽核表）依 proc_param.databaseid（'C'→csa、'L'→log 庫本身）轉發執行。

使用者希望把排程/自動化程式集中管理，並且將來所有自動排程程序都放同一個地方：

  • 自動化的程式（procs）集中一處。
  • 自動化自己產出的資料表（mailqueue、安全庫存 history…未來新增的）也集中放、不再寫回公司庫。
  • 查詢自動化資料時要走跟現有 log 派發器一樣的機制，而非在程式裡硬寫跨庫三段式名稱。
  • 公司來源資料（invent / invstk / 行事曆 view…）仍留公司庫。

關鍵限制：8 個排程物件中，5 支會讀寫公司庫專屬的表/view（twork_vw_calendarevent、 twork_skd_eventitem、invent/invstk/_prgpar/_date/vwseek_* 等），無法乾淨地與公司庫分離。 但同一 SQL 執行個體內，新庫的 proc 可用三段式 darbnogicsa1.dbo.* 讀寫公司庫（AI 派發器已證實 WITH EXECUTE AS + 跨庫到 csa 可運作）。

Decision

建立集中自動化庫 darbnogiauto1，並比照既有 AI 查詢派發器手法新增排程/自動化專屬派發器。

  1. 新庫 darbnogiauto1 放：
  2. 自動化 proc：TWORK_SKD_GET_PENDING_NOTIFY/_AUTOEXEC、TWORK_SKD_MAILQUEUE_DEQUEUE/_UPDATE、TWORK_AUTO_SAFETYSTOCK。
  3. 自動化自有資料表：twork_skd_mailqueue、twork_auto_safetystockhistory。
  4. 通用查詢 proc DARB_GETDATA4（佈一份到新庫，供結果檢視走同一派發器讀本庫表）。
  5. 專屬派發器 DARB_LOG_SYS_SKD_EXEC（建在 darbnogilog1）：複製 DARB_LOG_SYS_EXEC，差異僅
  6. 寫自己的稽核表 log_sys_skd（不污染 log_sys）；
  7. 目標一律導向 darbnogiauto1（把 DB_NAME() 的 log 換 auto），仍讀 proc_param 取 param_qty/paramoutput 決定 EXEC 參數個數。
  8. View 層讀公司資料：新庫的 proc 本體引用本地同名 view/表（不含庫名、與 csa 原版一致、可跨客戶共用）； 跨庫集中在 view 層——每個公司來源物件在新庫包一支同名 view 去抓 darbnogicsa1.dbo.*。 公司庫沒有的物件就在新庫自建：vwseek_* 用 csa 基底表（purchm/purch/wkpaper…）組出、_date 視公司庫有無 （有→view 抓 csa；無→自建日曆表並填值）。自動化自有表（mailqueue/history）用本庫 dbo.。
  9. 查詢比照 log 機制：結果檢視 EventResultViewModel 依事件 參數 JSON 的 Dispatcher 旗標選派發器 （SKD→走 DARB_LOG_SYS_SKD_EXEC + 新庫 DARB_GETDATA4 讀本庫 history；否則走主派發器→csa）。
  10. C# 接上（比照 AI pattern）：Procedure.DARB_LOG_SYS_SKD_EXEC、IDatabaseConnection.Log_Sys_Skd_Exec
  11. Sql 實作 + 4 個 fake/mock；SchedulerJob 4 處改走 SKD；AutopilotMethod_LogSysExec 加 Dispatcher opt-in（SKD 時走 Log_Sys_Skd_Exec，不影響其他通用 exec）。
  12. 不動原庫：darbnogicsa1 原 8 支 proc 與其 twork_auto_safetystockhistory 原表、proc_param、 DARB_LOG_SYS_EXEC 全部保留（主派發器 'C' 路由仍可跑原件，作為 fallback）。
  13. UI 共用 2 支留 csa：TWORK_SKD_GETEVENT、TWORK_SKD_UPDATE_EVENT_STATUS（行事曆 UI 與排程器 共用）不搬、CalendarBll 不改派發器，避免把行事曆 UI 綁死新庫、波及其他客戶。

未來新增自動 proc 的標準作法

  1. 在 darbXXauto1 建 proc：proc 本體引用本地同名 view（公司來源物件先在本庫包 view 抓 csa）、 自身產出的表建在本庫 dbo.。proc 本體因此不含庫名、各客戶共用。
  2. 經 DARB_LOG_SYS_SKD_EXEC 執行（C# 走 Log_Sys_Skd_Exec；AutoPilot 事件設 Dispatcher=SKD）。
  3. 需要結果檢視時，事件 參數 設 Dispatcher=SKD，結果表 填本庫表名即可。

各客戶部署（NOGI / CY …）

  • NOGI：sql/deploy-darbnogiauto1.sql。已驗證端對端（NOTIFY/AUTOEXEC/安全庫存/結果檢視全 OK）。
  • CY（朝陽）：sql/deploy-darbcyauto1.sql（view 層改抓 darbcycsa1；_date 自建表、vwseek_* 用 csa 基底表組）。 CY 公司庫原本 schema 落後（從未完整裝排程），已用 sql/fix-darbcycsa1-scheduler-schema.sql 補齊：
  • darbcycsa1.dbo.twork_skd_eventitem 補 2 個真正新欄：執行開始時間/執行guid（CY 無對應舊名；型別對齊 NOGI）。
  • 改基底欄名對齊共用 TsERP Source 契約：通知→是否通知、停用→是否停用（CY 舊名落後；共用 Twork_skd_vw_eventitemSource 本就用 是否通知/是否停用，改名即對齊、資料保留）。
  • 連帶更新所有引用舊欄名的 CY 物件（否則連鎖壞）：twork_skd_vw_eventitem/_v（輸出欄改新名）、 TWORK_WKFLOW_EVENTITEM（CY 專屬 SQL-Agent 排程）、TWORK_MOLD_CHECK、TWORK_SKD_NOTIFYEVENT（已棄用順手對齊）。
  • darbcycsa1.dbo.twork_vw_calendarevent 重建：修掉壞掉的 IsApproved→a.已審核、暴露 b.是否通知/b.是否停用 等排程欄。
  • 補完重跑 deploy-darbcyauto1.sql，守護區塊自動補建 twork_vw_calendarevent view 與 TWORK_AUTO_SAFETYSTOCK。
  • CY 已端對端驗證（模擬環境）：NOTIFY/AUTOEXEC=OK、安全庫存 history 寫 105 筆、log_sys_skd 全 OK，與 NOGI 同等。
  • （部署腳本對這兩個物件仍保留 COL_LENGTH/TRY-CATCH 守護，故未修 schema 的客戶重跑不會中斷。）

Consequences

  • 自動化的執行與稽核（log_sys_skd）與主流程隔離；新增自動程式有統一落點。
  • 共用派發器 DARB_LOG_SYS_EXEC / log_sys / proc_param 完全不動 → 對既有 ~400 支 proc 零風險。
  • 跨庫依賴：新庫 proc 依賴 darbnogicsa1 存在且同執行個體；派發器 EXECUTE AS 身分（login foxcsa） 需在 darbnogiauto1 有 user（部署腳本已建 foxautoexec）。darbnogilog1 既為 TRUSTWORTHY + owner sa， 跨庫鏈 log→auto→csa 成立。
  • 多客戶：本案只做 NOGI。其他客戶需各自 darbXXauto1 變體（proc 內前綴改該客戶 csa 庫名）＋在該客戶 log 庫佈 DARB_LOG_SYS_SKD_EXEC 與 log_sys_skd。CalendarBll/UI 共用 2 支留 csa 的決策確保未佈署新庫 的客戶行事曆 UI 不受影響。
  • mailqueue 的入列端 SP（未來把信寫進佇列者）也須改寫到 darbnogiauto1.dbo.twork_skd_mailqueue。

Migration

  • 部署：sql/deploy-darbnogiauto1.sql（冪等，sqlcmd -f 65001 或 SSMS）。建庫、建 2 表、建 DARB_GETDATA4、 建 5 支 proc、建 DARB_LOG_SYS_SKD_EXEC + log_sys_skd、建 user foxautoexec（FOR LOGIN foxcsa）。
  • C# 隨版發布即生效（純新增 wrapper + 切換呼叫點，無破壞性介面變更，但 IDatabaseConnection 新增方法， 自訂實作者需補 Log_Sys_Skd_Exec）。
  • 安全庫存事件：把 參數 設 Dispatcher=SKD + Procedure=TWORK_AUTO_SAFETYSTOCK 才會落新庫。
  • 原 csa 物件保留 30 天後可視情況清除（非必要）。

Alternatives Considered

  • 改共用派發器加 databaseid='A' 路由：要動 DARB_LOG_SYS_EXEC（~400 支 proc 的路由器）+ 翻 proc_param，blast radius 大、且會讓主派發器與新路由耦合。否決。
  • 硬寫三段式、不佈 DARB_GETDATA4 到新庫：結果檢視得在 結果表 塞三段式名，與「查詢比照 log 機制」 的目標相違，且每個讀取點都要特判。否決。
  • 連公司來源表一起搬到新庫：等於把行事曆/庫存資料搬離公司庫，動到 ERP 主功能與大量綁定，工程過大。否決。
  • 只搬自足的 mailqueue 三件：無法涵蓋使用者點名的 TWORK_AUTO_SAFETYSTOCK。否決。