รับข้อมูลจาก ERP เข้าระบบ NCS (SS/NPL) `ncs-erp-inbound` เป็น Flask API ตัวเล็กที่ทำหน้าที่เป็น "ตัวรับ" ไฟล์ flat-file จากระบบ ERP ของ BAM ผ่าน SFTP แล้วแปลง+ยิงเข้า REST API ของระบบ NCS สองตัว (`ncs-ss` และ `ncs-npl`) แทนการเชื่อมต่อฐานข้อมูลตรงๆ — เป็น integration layer แบบ file-based ที่ ERP วางไฟล์ output ไว้ที่ SFTP แล้วมี job มาดึงเข้าไปประมวลผลเป็นระยะ --- ## ภาพรวม ไฟล์จาก ERP เป็น flat-file รูปแบบ fixed pattern คั่นด้วย `|` (pipe-delimited) มีโครงสร้าง 3 ส่วนเสมอ: ``` H||| ← Header (1 บรรทัด) D||...ฟิลด์ข้อมูลตามชนิดของไฟล์... ← Detail (หลายบรรทัด) T|||... ← Footer (1 บรรทัด) ``` สคริปต์ในระบบนี้แบ่งเป็น 3 กลุ่มตาม prefix ชื่อไฟล์ (`erp-rc-*`, `erp-gl-*`, `erp-pr-*`) — แต่ละกลุ่มรับผิดชอบ "ประเภทข้อมูล" ต่างกันและยิงเข้า service ปลายทางคนละตัว --- ## Flow หลัก ``` ERP (BAM) วางไฟล์ .txt บน SFTP server (172.18.1.237:2222, key-based auth) │ โฟลเดอร์ปลายทางแบ่งเป็น PR/ RC/ GL/ APMAS/ ▼ เรียก GET /ncs/erp/inbound/ (เช่น ERP_RC_001, ERP_GL_003) │ ▼ app.py: process_single_script(script_code) │ - เช็ก script_code อยู่ใน script_mapping หรือไม่ │ - คุมด้วย Semaphore(3) — รันพร้อมกันได้สูงสุด 3 สคริปต์ │ - spawn thread แยก แล้วตอบ HTTP 202 กลับทันที (ไม่รอผลลัพธ์) ▼ subprocess: python3 erp--.py │ ├─ 1) download_files_from_sftp() — โหลดไฟล์ตาม prefix + วันที่วันนี้ (YYYYMMDD) ├─ 2) validate_file_data() — parse ทีละบรรทัด, เช็ก H/D/T ครบ, ฟิลด์บังคับ, ความยาว, SequenceNo ซ้ำ ├─ 3) แปลงเป็น JSON แล้ว POST/PATCH เข้า REST API (url_ss หรือ url_npl) เป็น batch ละ 100 records ├─ 4) สำเร็จ → move_file_in_sftp() ย้ายไฟล์ต้นทางไปโฟลเดอร์ DONE/ บน SFTP └─ 5) ลบไฟล์ที่ดาวน์โหลดมาชั่วคราวใน local tmp/ ไม่ว่าสำเร็จหรือไม่ ``` --- ## app.py — Job Dispatcher `app.py` ไม่ได้ประมวลผลข้อมูลเอง แต่ทำหน้าที่เป็น **dispatcher**: รับ HTTP request แล้วสั่งรันสคริปต์ที่ตรงกับ `script_code` เป็น subprocess แยก จุดสำคัญในการออกแบบ: | กลไก | รายละเอียด | |---|---| | `script_mapping` | dict คงที่ map `ERP_RC_001` ฯลฯ → ชื่อไฟล์ `.py` — เพิ่มสคริปต์ใหม่ต้องมาแก้ dict ตรงนี้ | | `script_semaphore = threading.Semaphore(3)` | จำกัดให้รันพร้อมกันได้สูงสุด 3 สคริปต์ กัน SFTP/DB โดนโหลดหนักเกิน | | `subprocess.run(..., timeout=300)` | แต่ละสคริปต์มี timeout 5 นาที ถ้าเกินจะถูก kill และตอบ error | | async response | `handle_single_script` spawn thread แล้วตอบ `202 Accepted` ทันที — endpoint จึงเป็น fire-and-forget ไม่รอผลจริง (ผลลัพธ์ต้องไปดูใน log endpoint แทน) | Endpoint ที่มีให้ใช้: - `GET /ncs/erp/inbound/` — สั่งรันสคริปต์ตามโค้ด (async, ตอบ 202) - `GET /ncs/erp/health` — health check - `GET /ncs/erp/viewer/logs` — list ไฟล์ log รายวันที่มี - `GET /ncs/erp/viewer/log/` — อ่านเนื้อ log ของวันนั้นแบบ plain text โครงสร้าง endpoint นี้ (ตอบ 202 ทันทีแล้วรันเบื้องหลัง) หมายความว่าการ trigger สคริปต์น่าจะมาจาก scheduler ภายนอก (cron/Jenkins) ที่ยิง HTTP call ตามเวลา ไม่ใช่ manual trigger เป็นหลัก --- ## กลุ่ม RC — Receipt/Clearing (→ ncs-npl) ไฟล์กลุ่มนี้ดาวน์โหลดจากโฟลเดอร์ SFTP `RC/` และยิงเข้า `ncs-npl` (`url_npl`) — ข้อมูลเกี่ยวกับการรับชำระหนี้/เคลียริ่งเช็ค เข้ากับ NPL (Non-Performing Loan) service | ไฟล์ | REST endpoint ปลายทาง | ข้อมูลหลักในแต่ละ Detail record | |---|---|---| | `erp-rc-001.py` | `POST/PATCH .../rc/rc001` | `ReceiveTxnId`, `ReceiveType`, `DebitBankNo/AccountNo`, `ChequeBankNo/No/Date`, `ReconcileDate`, `TransactionAmount`, `Status`, `ChequeReturnDescription` — สถานะเคลียริ่งเช็ครับชำระ | | `erp-rc-002.py` | `.../rc/rc002` | โครงสร้างฟิลด์เดียวกับ rc001 (variant ของสถานะ/ประเภทอื่น) | | `erp-rc-003.py` | `.../rc/rc003` | โครงสร้างฟิลด์เดียวกับ rc001 | | `erp-rc-004.py` | `.../rc/rc004` | `ReceiveTxnId`, `BillPaymentRef1-4` — อ้างอิง bill payment (มีฟิลด์น้อยกว่ากลุ่มอื่นในหมวดนี้) | ทั้ง 4 ไฟล์ใช้ `requests.patch()` ส่งเป็น batch ละ 100 record ตรงๆ (payload เป็น array ไม่ห่อ object) และ reject ทั้งไฟล์ทันทีถ้าพบ `SequenceNo` ซ้ำหรือฟิลด์บังคับขาด --- ## กลุ่ม GL — General Ledger Master Data (→ ncs-ss) ไฟล์กลุ่มนี้ดาวน์โหลดจากโฟลเดอร์ SFTP `GL/` และยิงเข้า `ncs-ss` (`url_ss`) ที่ endpoint ตระกูล `core/api/pargl/v1/...` — เป็นข้อมูล **master ผังบัญชี** (chart of accounts) ล้วนๆ ไม่ใช่ transaction | ไฟล์ | REST endpoint | Master data | |---|---|---| | `erp-gl-001.py` | `.../pargl/v1/coaport` | COA Port (`Port`, `NameEN/TH`, `MainPort20`) | | `erp-gl-002.py` | `.../pargl/v1/glcostcenter` | Cost Center (`CostCenter`, `MainCostCenter`) | | `erp-gl-003.py` | `.../pargl/v1/glchartofaccounts` | GL Account (`GLAccountNumber`, `GLType`, `MainGLAccount`, `BalanceRecon`, `CashAccount`) | | `erp-gl-004.py` | `.../pargl/v1/coabudget` | Budget Code (`BudgetCode`, `MainBudgetCode`) | | `erp-gl-005.py` | `.../pargl/v1/coaintercompany` | Intercompany Code | | `erp-gl-006.py` | `.../pargl/v1/coaoffset` | Offset Code | ทั้ง 6 ไฟล์มีรูปแบบเหมือนกันเป๊ะ (เป็น template เดียวกัน เปลี่ยนแค่ชื่อฟิลด์กับ endpoint): แต่ละ detail record มี `MaintenanceFlag` (`A`=Add, `U`=Update) และ `EnabledFlag` (`Y`/`N`) ใช้แยกว่าจะ `POST` (insert) หรือ `PATCH` (update) — สคริปต์แยก record เป็น `insert_details` / `update_details` สองกลุ่มก่อนส่ง เพื่อยิงคนละ batch คนละ HTTP method `erp-gl-001.py` เป็นไฟล์เดียวในกลุ่มที่มี validation เข้มกว่าไฟล์อื่น (เก็บ error list ละเอียดทุกบรรทัด ตรวจ `footer.TotalTransaction` ต้องตรงกับจำนวน detail จริง) — code ใหม่กว่าไฟล์อื่นในกลุ่มเดียวกันอย่างชัดเจน (ไฟล์อื่นยัง raise/return ทันทีที่เจอ error แรกโดยไม่สรุปทั้งหมด) --- ## กลุ่ม PR — Parameter & Payable (→ ncs-ss / ncs-npl ผสมกัน) กลุ่มนี้ไม่ได้ยิงเข้า service เดียวเหมือนกลุ่มอื่น และที่น่าสนใจคือ **ไม่ได้ดาวน์โหลดจากโฟลเดอร์ `PR/` เสมอไป**: | ไฟล์ | โฟลเดอร์ SFTP ต้นทาง | REST endpoint ปลายทาง | ข้อมูล | |---|---|---|---| | `erp-pr-001.py` | `APMAS/` | `ncs-ss` `.../pr/pr001` | VAT Code master (`VatCode`, `VatType`, `VatRate`) | | `erp-pr-002.py` | `APMAS/` | `ncs-ss` `.../pr/pr002` | Withholding Tax Code master (`WithholdingCode`, `WithholdingRate`) | | `erp-pr-003.py` | `PR/` | `ncs-npl` `.../pr/pr003` | รายการจ่ายเงิน (`PrTrxRef`, `PaymentType/Date`, `PayeeAcc*`, `ChequeBank/No`) | | `erp-pr-004.py` | `APMAS/` | `ncs-npl` `.../pr/pr004` | ตั๋วสัญญาใช้เงิน/PN (`PNNumber`, `PNRate`, `PNAmount`, `IssueDate`, `MaturityDate`, `PayerBankCode`, `SupplierCode/Site`) | กลุ่มนี้จึงเป็นการผสมทั้ง master data (PR001, PR002 → master พารามิเตอร์ภาษี) และ transaction data (PR003, PR004 → รายการจ่ายเงิน/ตั๋ว PN) เข้าด้วยกันภายใต้ prefix เดียว — ต่างจากกลุ่ม RC/GL ที่ตรงไปตรงมากว่า (PR = "Payable/Parameter" ผสมกัน อนุมานจากเนื้อหาโค้ด ไม่มีเอกสารระบุชัดเจนในซอร์ส) --- ## SFTP: การเชื่อมต่อและ credential `function/open_file_in_sftp.py` และ `function/check_sftp.py` เชื่อมต่อ SFTP ด้วย RSA private key (`paramiko.RSAKey.from_private_key_file`) — โฟลเดอร์ `function/` มีไฟล์ `.pem` หลายตัวสำหรับ 3 environment (SIT/UAT/DEV) แต่ **โค้ดที่ active อยู่ตอนนี้ hardcode host/port/username/พาธไฟล์คีย์ไว้ในซอร์สโค้ดตรงๆ** (บรรทัด `sftp_host = '172.18.1.237'` เป็นต้น) ไม่ได้ผ่าน env var หรือ secret manager — โค้ด environment อื่นถูก comment ทิ้งไว้แทนที่จะใช้ config switch based on env **สิ่งที่ต้อง flag:** `function/sql_connect.py` มี password ของ SQL Server (`mendix` user) เป็น plaintext ฝังอยู่ในไฟล์ตรงๆ ในซอร์สโค้ด (ทั้งของ dev เก่าที่ comment ไว้ และของ UAT ที่ active) เช่นเดียวกับไฟล์ private key `.pem` หลายไฟล์ที่ commit เข้ามาในซอร์สโดยตรง — เป็นความเสี่ยงเดียวกับที่บทความ [`HKDF-SHA256.md`](./HKDF-SHA256.md) พูดถึงเรื่องการแยกคีย์ออกจากโค้ด ระบบนี้ยังไม่ได้ทำแบบนั้น --- ## Deployment - รันเป็น Kubernetes **Job** (ไม่ใช่ Deployment ปกติ) — `command: python3 ./app.py`, `restartPolicy: Never`, `backoffLimit: 4` แล้ว expose ผ่าน Service + Ingress (`ncs-erp-inbound-uat.bam.co.th`) เข้าถึง endpoint ได้จากภายนอก - แยก manifest ตาม environment: `sit`, `uat`, `uat1` (`k8s/*.yaml`) - Jenkinsfile แยกสาย build/deploy (`deploy-*.Jenkinsfile`) กับ stop app (`stopapp-*.Jenkinsfile`) และสาย release แยกอีกชุด (`erp-inbound-*-release.Jenkinsfile`) - มีสคริปต์ `check_endpoint.py` ไว้ตรวจสุขภาพ endpoint ปลายทางทั้งหมด (DNS, SSL, reachability) ของ `ncs-ss`/`ncs-npl` แยกต่างหากจากตัวแอปหลัก ใช้เป็นเครื่องมือ diagnostic เวลา integration มีปัญหา --- ## สรุป ``` ERP → SFTP (RC/GL/PR/APMAS) → app.py dispatch (semaphore 3, timeout 300s, async 202) → erp--.py: download → validate (H/D/T, mandatory, length, dup seq) → batch POST/PATCH (100 records/batch) → ncs-ss (GL master, PR001/002 master) → ncs-npl (RC receipt/clearing, PR003/004 payable) → success: move SFTP source ไป DONE/, ลบไฟล์ local tmp/ ``` ระบบนี้เป็น integration layer แบบ file-polling ที่ค่อนข้างตรงไปตรงมา จุดที่ควรปรับปรุงเด่นชัดที่สุดคือการจัดการ credential (SFTP key, DB password) ที่ยังฝังอยู่ในซอร์สโค้ดโดยตรงแทนที่จะแยกออกเป็น secret/env var ตามมาตรฐาน

SECURE_ACCESS

DOWNLOAD_LOCKED

รับข้อมูลจาก ERP เข้าระบบ NCS (SS/NPL)

CONFIRM_DELETE