2way-line-service — Persistence & Integrations

บทนี้อธิบายการเชื่อมต่อภายนอกของ 2way-line-service (branch: master) — ไม่มี persistence ชั้น DB ใน runtime path แต่มี outbound ไป LINE Messaging / Rich Menu API และ inbound จาก 2way-api ผ่าน IP hardcode

ดู pipeline ที่ 02-core-pipeline

---

Persistence: ไม่มี TypeORM connection

หลักฐาน:

รายการ	สถานะ	อ้างอิง
TypeOrmModule.forRoot* ใน AppModule	ไม่มี	app.module.ts:9-19
@nestjs/typeorm / typeorm / mssql ใน dependencies	มีใน package.json แต่ไม่ถูก wire	package.json:33,39,46
src/entities/*.ts	มีไฟล์ แต่ไม่ถูกโหลด	โฟลเดอร์ entities
db.* ใน configuration	อ่าน env แต่ไม่มี consumer ใน LineService	configuration.ts:4-10

สรุป: ห้ามเขียนว่า service นี้ "ใช้ MSSQL" ในเส้นทางที่ทำงานจริง — มีแค่ dependency/skeleton ค้าง

---

Outbound — LINE Messaging API

Token: Authorization: Bearer ${config.get('lineToken')} จาก env LINE_AUTH_TOKEN (configuration.ts:11, ใช้ที่ line.service.ts:30,60,93,119)

Operation	HTTP	URL	Body shape	อ้างอิง
Push	POST	https://api.line.me/v2/bot/message/push	{ to, messages:[{type:'text',text}] }	line.service.ts:20-32
Multicast	POST	https://api.line.me/v2/bot/message/multicast	{ to, messages:[...] }	line.service.ts:50-61
Link rich menu	POST	https://api.line.me/v2/bot/user/{userId}/richmenu/{richMenuId}	(ไม่มี body ใน options)	line.service.ts:88-95
Unlink rich menu	DELETE	https://api.line.me/v2/bot/user/{userId}/richmenu	(ไม่มี body)	line.service.ts:114-120

Success criterion ในโค้ด: HTTP status 200 จาก axios (line.service.ts:35,65,98,124)

ไม่มี retry / circuit breaker / queue ใน service นี้

---

Hardcoded rich menu IDs

กิ่ง	richMenuId	อ้างอิง
default ก่อน if / เมื่อ isChula เป็น truthy	richmenu-4a2198498bb2a45c9f8e83f34e1d8b27	line.service.ts:82
เมื่อ !isChula	richmenu-4b7b5788ffc3663761757bf80ffead54	line.service.ts:85
ค่าเก่าที่ comment	richmenu-4eb43ff2ee5b7cee86378e9e9bf1d0ae	line.service.ts:84

ไม่ได้อ่านจาก DB หรือ env — การเปลี่ยนเมนูต้องแก้โค้ดแล้ว deploy ใหม่

---

Inbound caller — 2way-api (branch: prod)

2way-api มี LineService.nextPageLine / previousPageLine ที่ยิงไป IP hardcode:

await this.axios.post('http://20.212.116.206:8200/api/v1/line/nextPage', data);
await this.axios.delete('http://20.212.116.206:8200/api/v1/line/previousPage', data);

แหล่ง: 2way-api/src/modules/line/line.service.ts:76,86 (branch: prod)

พอร์ต 8200 ตรงกับ .env.example ของ line-service (.env.example:5) และ docker-compose.yml:8-9

Contract mismatches ที่พิสูจน์ได้จากซอร์ส

ประเด็น	ฝั่ง 2way-api (caller)	ฝั่ง 2way-line-service (callee)
Path casing	/api/v1/line/nextPage (ตัว l เล็ก)	@Controller('Line') → /api/v1/Line/... (ตัว L ใหญ่)
nextPage body	{ userId: body.lineId, richMenuId: body.richMenuId } (line.service.ts:72-75)	NextPageDto: userId, isChula? — ไม่มี richMenuId (dto/line.dto.ts:24-32)
previousPage body	{ userId: body.lineId }	PreviousPageDto: userId — ตรงชื่อ field
DTO ต้นทางใน 2way-api	NextPageDto.lineId + optional richMenuId (2way-api/src/dto/line.dto.ts:24-32)	ใช้ isChula เลือก menu ใน callee แทน

ผลกระทบที่สรุปได้โดยไม่ invent runtime behavior:

1. Path case ต่างกัน — บน server ที่ case-sensitive อาจได้ 404; บนระบบที่ normalize path เป็น UNVERIFIED
2. richMenuId ที่ caller ส่ง ไม่ถูกใช้ ใน callee — callee เลือกจาก hardcode + isChula
3. Caller ไม่ได้ส่ง isChula ใน object ที่สร้าง (2way-api line.service.ts:72-75) → ที่ callee isChula เป็น undefined → กิ่ง !isChula เลือก menu non-Chula (line.service.ts:83-85)

Push จาก 2way-api ไป LINE โดยตรง (https://api.line.me/...) ใน method pushMassage ของ 2way-api เอง (2way-api/.../line.service.ts:30) — ไม่ได้ ผ่าน 2way-line-service สำหรับ push ในโค้ดที่อ่าน

---

Env ที่เกี่ยวกับ integration

จาก .env.example (อ้างชื่อตัวแปรเท่านั้น — ห้าม paste ค่า secret):

Variable	ใช้ใน runtime path?	อ้างอิง
PORT	ใช่	.env.example:5
BASE_PATH	ใช่ (prefix)	.env.example:3
LINE_AUTH_TOKEN	ใช่	.env.example + configuration.ts:11
SECRET_KEY	JwtStrategy เท่านั้น	configuration.ts:3
DB_*	ไม่ใน Line path	.env.example:7-12
CENTRALIZE_SERVER	ไม่พบการอ้างใน *.ts	.env.example:16
SERVER_URL / PROJECT_NAME	Swagger document	docs/document.config.ts:4-7

---

Compose network

docker-compose.yml เชื่อม vtrc-api_default เป็น external network (docker-compose.yml:28-30) — ชื่อ container api-structure-dev ทั้ง dev และ prod (docker-compose.yml:10,23)

ไม่มีหลักฐานใน repo นี้ว่า nginx reverse-proxy path สำหรับ line-service คืออะไร (ต่างจาก 2way-batch ที่มี nginx/conf.d)

---

สิ่งที่ไม่มี

Integration	สถานะใน repo นี้
cu-central-api / centralize-api HTTP calls	ไม่พบใน src/
vtrc-api GraphQL	ไม่พบ
MSSQL queries	ไม่พบใน LineService
LINE webhook receiver	ไม่มี controller webhook

---

สิ่งที่อยู่นอกขอบเขตบทนี้

• Step-by-step rich menu → 02-core-pipeline
• Debt register → 04-scorecard