Volume 4 · cu-central-api Deep Dive

Volume นี้เจาะลึก cu-central-api — service ที่โครงสร้างคล้าย vtrc-api แต่ขนาดเล็กกว่า และมีจุดเด่นเฉพาะตัวคือ LDAP/AD auth, multi-tenant sharding, และ HR data integration ที่ vtrc-api ไม่มี

ทำไมต้องมี Volume นี้

ตาม audit/02-architecture-map.md §2.3.3 cu-central-api ถูก label เป็น "Legacy CU Auth/HR Satellite" — แต่ label นั้นขาดรายละเอียดสำคัญ

6 MSSQL connections (ไม่ใช่ 2 ตามที่ audit บอก) กระจายไป 5 schemas + dead dbHRMI_test connection
Multi-tenant SourceDB sharding ที่ทุก association ต้อง scope ด้วย WHERE Employee.SourceDB = X.SourceDB — pattern ที่ไม่มีใน vtrc-api
LDAP/AD auth ผ่าน ldapjs 2-stage bind (service account + user bind) ที่ vtrc-api forward มา
External integrations 5 ตัวที่ cu-central-api เป็น service เดียวที่เรียก — SSO, Conicle SFTP, HIS heal-card, HRMI API, SMS gateway

ถ้า debug เรื่อง "ทำไม employee ของ org X login ไม่ได้" หรือ "ทำไมข้อมูล HR ของ shard Y หาย" ต้องเริ่มที่นี่ ไม่ใช่ที่ vtrc-api

บทบาทใน topology

┌─────────────┐     ┌─────────────┐
│ vtrc-web    │     │ vtrc-rc-    │
│ (React 16)  │     │ backoffice  │
└──────┬──────┘     └──────┬──────┘
       │                    │
       └─────────┬──────────┘
                 │ GraphQL (apiKey + JWT)
                 ▼
       ┌─────────────────────┐
       │     vtrc-api        │  Volume 3
       │  (Apollo + MariaDB) │
       └─────┬───────────────┘
             │
             │ END_POINT_CENTRALIZE (+ _AUTH)
             ▼
       ┌─────────────────────┐
       │  cu-central-api     │  Volume 4 ◀── บทนี้ (live bridge)
       │  (Apollo / MSSQL)   │
       └─────┬───────────────┘
             │
             ├──▶ MSSQL (6 connections, 5 schemas)
             ├──▶ LDAP / AD (Chula directory)
             ├──▶ Redis (session + cache) — key `sess:{userUid}_{sessionId}`
             ├──▶ SSO (with committed certs)
             ├──▶ Conicle SFTP
             ├──▶ HIS heal-card API
             ├──▶ HRMI HTTP API
             ├──▶ SMS gateway
             └──▶ SMTP

       ┌─────────────────────┐
       │  centralize-api     │  Volume 5 — NestJS REST (port 3000)
       │  (NestJS / MSSQL)   │  caller จาก vtrc-api ใน workspace นี้ยังไม่ยืนยัน
       └─────────────────────┘

cu-central-api ไม่ได้คุยกับ frontend โดยตรง — เป็น upstream live ของ vtrc-api ผ่าน END_POINT_CENTRALIZE / END_POINT_CENTRALIZE_AUTH (per workspace rule: "Both frontends talk to vtrc-api only")

ใครควรอ่านบทไหน

ถ้าเป็น	อ่านบท
Dev ที่ debug login ผ่าน AD	4.3, 4.4
Dev ที่แก้ HR data query	4.5, 4.6
DevOps ที่ดูแล deploy	4.2, 4.8
คนที่จะ modernize auth	4.3, 4.4, 4.9
คนที่ทำ SSO integration	4.7
คนที่เจอ "finanace" typo	4.1, 4.6

สไตล์ที่ใช้ใน Volume นี้

เหมือน Volume อื่น — น้ำเสียง senior engineer ที่ทำจริง, ภาษาไทย + ทับศัพท์ dev, ไม่ใช้ emoji/mermaid/callout boxes, ใช้ ASCII tree + table + code block แทน

ทุก claim ต้องมี file:line reference — cu-central-api/main-api/src/...

Severity legend เหมือน Volume 8/9

🔴 Critical = active risk ต้องแก้ทันที
🟡 High     = มี impact จริงแต่ต้องมีเงื่อนไข
🟢 Medium   = hygiene/debt ยังไม่อันตรายทันที

โครงสร้าง Volume

4.1  Repository map                  — โครงสร้าง src/ + typos + dead files
4.2  Bootstrap + 6 DB connections    — Apollo + Express, connector.js, syncModelToTable
4.3  Authentication + LDAP/AD flow   — REST /auth/signin, 2-stage bind, JWT signing
4.4  @auth directive + bypass        — ignoreAuth, accessLevel, hardcoded apiKeys
4.5  Multi-tenant SourceDB sharding  — scoped associations, ทำไม pattern นี้จำเป็น
4.6  TypeDefs + resolvers catalog    — 31 SDL + 29 resolvers, เน้น hrmi.js
4.7  External integrations           — SSO + Conicle + HIS + HRMI + SMS + SMTP
4.8  Security + debt                 — JWT_SECRET empty, axois, ldapjs, Node 12
4.9  Scorecard + comparison          — เทียบกับ vtrc-api + modernization target

สิ่งที่ Volume นี้ไม่ครอบคลุม

รายละเอียด secrets values ใน .env.develop-test — cover แล้วใน Volume 10.5 (cu-central-api .env.develop-test committed)
Generic LDAP/AD concepts — เน้นเฉพาะที่ implement ใน codebase
การ migrate ไป Go service — cover ใน Volume 15

อ่านต่อ → 4.1 Repository map

Volume 4 · cu-central-api Deep Dive ​

ทำไมต้องมี Volume นี้ ​

บทบาทใน topology ​

ใครควรอ่านบทไหน ​

สไตล์ที่ใช้ใน Volume นี้ ​

โครงสร้าง Volume ​

สิ่งที่ Volume นี้ไม่ครอบคลุม ​