PHASE 4 - Workflow Automation (Ngày 96–135)

TUẦN 20 - N8N CORE

Ngày 96: n8n Setup & Trigger

• Mục tiêu: Chạy được n8n và hiểu cách workflow được kích hoạt.

• Lý thuyết: Trigger node (Webhook, Schedule, Manual), khác biệt trigger vs action node.

• Thực hành: Cài n8n bằng Docker, tạo workflow đầu tiên: Webhook trigger → gửi log ra console.

Ngày 97: Workflow Cơ bản

• Mục tiêu: Nối nhiều node thành một luồng xử lý.

• Lý thuyết: Node connection, data flow giữa các node (items array).

• Thực hành: Xây workflow nhận webhook Task mới (từ Phase 2) → format lại dữ liệu → gửi vào Slack.

Ngày 98: Expression Syntax

• Mục tiêu: Truy xuất và biến đổi dữ liệu linh hoạt giữa các node.

• Lý thuyết: {{ $json }}, {{ $node["..."] }}, hàm built-in (date, string).

• Thực hành: Dùng expression để format ngày tháng và nối chuỗi thông báo Slack động theo dữ liệu Task.

Ngày 99: Branching (IF/Switch)

• Mục tiêu: Xử lý logic rẽ nhánh trong workflow.

• Lý thuyết: IF node, Switch node, Merge node.

• Thực hành: Thêm nhánh: nếu Task priority = "high" thì gửi Slack ngay, ngược lại chỉ ghi log.

Ngày 100: Sub-workflow & Credentials

• Mục tiêu: Tái sử dụng logic và quản lý bí mật an toàn.

• Lý thuyết: Execute Workflow node, Credential management trong n8n.

• Thực hành: Tách phần "gửi Slack" thành sub-workflow riêng, gọi lại từ workflow chính; lưu Slack token vào Credential thay vì hard-code.

TUẦN 21 - N8N WORKFLOW PATTERNS

Ngày 101: Error Handling trong Workflow

• Mục tiêu: Workflow không "chết âm thầm" khi có lỗi.

• Lý thuyết: Error Trigger node, Continue On Fail, try/catch pattern trong n8n.

• Thực hành: Thêm Error Workflow bắt lỗi khi gọi Slack API fail, gửi cảnh báo qua email thay thế.

Ngày 102: HTTP Request Node nâng cao

• Mục tiêu: Gọi mọi API tự viết ở Phase 2 từ n8n.

• Lý thuyết: Authentication trong HTTP node (OAuth2, API Key), pagination trong loop.

• Thực hành: Gọi API Task (có OAuth2) để lấy toàn bộ task phân trang, dùng SplitInBatches node.

Ngày 103: Data Transformation

• Mục tiêu: Biến đổi dữ liệu phức tạp giữa các hệ thống khác định dạng.

• Lý thuyết: Set node, Code node (JS), Item Lists node.

• Thực hành: Viết Code node chuyển đổi payload Jira sang định dạng Notion (Phase 2) trước khi đồng bộ.

Ngày 104: Scheduling & Batch Job

• Mục tiêu: Chạy automation định kỳ đáng tin cậy.

• Lý thuyết: Cron expression, xử lý overlap khi job trước chưa xong.

• Thực hành: Tạo workflow chạy mỗi giờ đồng bộ dữ liệu Task → Notion, có cơ chế tránh chạy chồng.

Ngày 105: Practice - Multi-system Workflow

• Mục tiêu: Ghép nhiều node/pattern thành 1 workflow thực tế.

• Lý thuyết: Ôn tập branching, sub-workflow, error handling.

• Thực hành: Xây workflow: GitHub issue mới → tạo Jira ticket → gửi Slack → nếu lỗi bất kỳ bước nào → gửi email cảnh báo.

TUẦN 22 - N8N ADVANCED (SCALING)

Ngày 106: Queue Mode

• Mục tiêu: Hiểu kiến trúc n8n khi chạy production với nhiều workflow đồng thời.

• Lý thuyết: Main process vs Worker process, Redis làm queue backend.

• Thực hành: Cấu hình n8n Queue Mode với Docker Compose (main + Redis + 1 worker).

Ngày 107: Worker & Scaling

• Mục tiêu: Tăng throughput xử lý workflow.

• Lý thuyết: Concurrency setting, horizontal scaling worker.

• Thực hành: Scale lên 3 worker, chạy thử 50 webhook đồng thời, quan sát phân phối tải.

Ngày 108: Error Workflow ở cấp Instance

• Mục tiêu: Có 1 nơi tập trung xử lý mọi lỗi của mọi workflow.

• Lý thuyết: Global Error Workflow setting trong n8n.

• Thực hành: Cấu hình 1 workflow xử lý lỗi chung, gửi tất cả lỗi vào 1 kênh Slack "alerts".

Ngày 109: Monitoring n8n

• Mục tiêu: Biết workflow nào đang chạy chậm/lỗi nhiều.

• Lý thuyết: n8n execution log, metrics endpoint cơ bản.

• Thực hành: Xem lại execution history, xác định workflow lỗi nhiều nhất trong tuần qua giả lập.

Ngày 110: Practice - Production Setup Review

• Mục tiêu: Tự đánh giá một setup n8n có sẵn sàng production chưa.

• Lý thuyết: Checklist production-readiness (queue mode, error workflow, credential, backup).

• Thực hành: Viết checklist review setup n8n Queue Mode đã dựng, đánh dấu phần còn thiếu.

TUẦN 23 - N8N CUSTOM NODE

Ngày 111: Cấu trúc Custom Node

• Mục tiêu: Hiểu bộ khung một node n8n được xây dựng thế nào.

• Lý thuyết: Node package structure, description, execute() function.

• Thực hành: Đọc source code 1 node có sẵn (ví dụ HTTP Request) để hiểu cấu trúc.

Ngày 112: Xây Custom Node cơ bản

• Mục tiêu: Tạo node riêng cho 1 nhu cầu chưa có sẵn.

• Lý thuyết: Input/Output properties, credential type riêng.

• Thực hành: Viết custom node gọi 1 SaaS chưa có sẵn trong n8n (ví dụ 1 API nội bộ tự viết ở Phase 2).

Ngày 113: Testing Custom Node

• Mục tiêu: Đảm bảo node hoạt động đúng trước khi dùng thật.

• Lý thuyết: Local testing với n8n-node-dev, unit test cho hàm logic bên trong node.

• Thực hành: Viết test cho hàm xử lý dữ liệu trong custom node bằng Jest.

Ngày 114: Publish & Package

• Mục tiêu: Chia sẻ node cho team hoặc cộng đồng dùng lại.

• Lý thuyết: npm package cho n8n community node, versioning.

• Thực hành: Đóng gói custom node thành npm package cục bộ, cài vào n8n instance để test.

Ngày 115: Review Custom Node

• Mục tiêu: Củng cố kỹ năng xây node.

• Lý thuyết: Ôn tập toàn bộ tuần.

• Thực hành: Refactor lại custom node đã viết cho rõ ràng, viết README hướng dẫn sử dụng.

TUẦN 24 - PROJECT: EMPLOYEE ONBOARDING

Ngày 116: Thiết kế Employee Onboarding Workflow

• Mục tiêu: Chuyển một quy trình nghiệp vụ (HR) thành sơ đồ automation.

• Lý thuyết: Mapping các bước onboarding thực tế (tạo email, cấp quyền, gửi welcome message) sang node.

• Thực hành: Vẽ flow onboarding: Form nhân viên mới → tạo tài khoản → thêm vào Slack channel → gửi email chào mừng.

Ngày 117: Xây phần Tạo tài khoản

• Mục tiêu: Tự động hóa bước cấp phát tài khoản đầu tiên.

• Lý thuyết: Tích hợp Google Workspace Admin API (đã học Phase 2).

• Thực hành: Node gọi Google Workspace API tạo tài khoản email mới cho nhân viên.

Ngày 118: Xây phần Cấp quyền & Thông báo

• Mục tiêu: Hoàn thiện luồng cấp quyền tự động.

• Lý thuyết: Thêm user vào group/Slack channel qua API.

• Thực hành: Node thêm nhân viên mới vào Slack workspace + channel phòng ban tương ứng.

Ngày 119: Human-in-the-loop Approval

• Mục tiêu: Thêm bước phê duyệt thủ công trước khi cấp quyền nhạy cảm.

• Lý thuyết: Wait node, form response node trong n8n.

• Thực hành: Thêm bước "chờ quản lý duyệt" trước khi cấp quyền truy cập hệ thống nội bộ.

Ngày 120: Test & Deploy Employee Onboarding

• Mục tiêu: Đưa workflow vào chạy thử với dữ liệu giả.

• Lý thuyết: Test case cho workflow (happy path + edge case: nhân viên trùng tên).

• Thực hành: Chạy thử toàn bộ workflow với 3 bộ dữ liệu test, sửa lỗi phát sinh.

TUẦN 25 - PROJECT: APPROVAL FLOW

Ngày 121: Thiết kế Approval Flow tổng quát

• Mục tiêu: Xây một pattern phê duyệt tái sử dụng được cho nhiều loại request.

• Lý thuyết: Generic approval pattern (request → notify approver → wait → action theo kết quả).

• Thực hành: Vẽ flow phê duyệt tổng quát cho "Purchase Request".

Ngày 122: Xây phần Request & Notify

• Mục tiêu: Bắt đầu luồng khi có yêu cầu mới.

• Lý thuyết: Webhook/Form trigger, xác định người duyệt theo cấp bậc.

• Thực hành: Node nhận request từ form, xác định approver dựa vào số tiền request.

Ngày 123: Xây phần Wait & Response Handling

• Mục tiêu: Xử lý được cả 2 kết quả duyệt/từ chối.

• Lý thuyết: Multi-step form, xử lý response bất đồng bộ.

• Thực hành: Approver nhận link duyệt qua Slack/email, click Approve/Reject, workflow tiếp tục theo nhánh tương ứng.

Ngày 124: Escalation & Timeout

• Mục tiêu: Xử lý khi approver không phản hồi kịp.

• Lý thuyết: Timeout pattern, escalation tới người duyệt cấp cao hơn.

• Thực hành: Thêm logic: nếu sau 24h không duyệt, tự động escalate lên manager cấp trên.

Ngày 125: Test & Deploy Approval Flow

• Mục tiêu: Đảm bảo flow chạy đúng trong mọi tình huống.

• Lý thuyết: Test case cho timeout, reject, approve.

• Thực hành: Chạy thử 3 kịch bản, ghi nhận kết quả vào audit table (Phase 1).

TUẦN 26 - PROJECT: INCIDENT & TICKET AUTOMATION

Ngày 126: Thiết kế Incident Automation

• Mục tiêu: Tự động hóa phản ứng ban đầu khi có sự cố.

• Lý thuyết: Incident lifecycle (detect → notify → triage → resolve), mapping vào workflow.

• Thực hành: Vẽ flow: alert từ hệ thống monitoring → tạo incident ticket → thông báo on-call qua Slack.

Ngày 127: Xây Incident Automation

• Mục tiêu: Hiện thực hóa flow đã thiết kế.

• Lý thuyết: Webhook nhận alert, phân loại mức độ nghiêm trọng (severity).

• Thực hành: Node phân loại severity dựa vào payload alert, route tới đúng kênh/đúng người on-call.

Ngày 128: Thiết kế Ticket Automation

• Mục tiêu: Tự động hóa xử lý ticket hỗ trợ khách hàng.

• Lý thuyết: Ticket triage pattern (phân loại, gán người xử lý, SLA tracking).

• Thực hành: Vẽ flow: ticket mới → phân loại tự động (dựa keyword) → gán agent → theo dõi SLA.

Ngày 129: Xây Ticket Automation

• Mục tiêu: Hiện thực hóa và tích hợp với Dashboard đã xây ở Phase 3.

• Lý thuyết: Kết nối n8n với DB Customer Support Dashboard.

• Thực hành: Workflow ghi ticket mới trực tiếp vào DB Dashboard, cập nhật trạng thái theo thời gian thực.

Ngày 130: Test & Deploy cả hai Automation

• Mục tiêu: Đảm bảo 2 workflow hoạt động ổn định song song.

• Lý thuyết: Ôn tập error handling, monitoring.

• Thực hành: Chạy thử đồng thời Incident + Ticket automation với dữ liệu giả lập tải cao.

TUẦN 27 - ZAPIER, MAKE, TESTING & CAPSTONE

Ngày 131: Zapier Overview

• Mục tiêu: Biết dùng Zapier khi khách hàng/team không có kỹ thuật.

• Lý thuyết: Zap structure (Trigger-Action), giới hạn so với n8n.

• Thực hành: Dựng 1 Zap đơn giản tương đương workflow Ngày 97 để so sánh trải nghiệm.

Ngày 132: Make (Integromat) Overview

• Mục tiêu: Biết thêm 1 lựa chọn no-code phổ biến ở châu Âu.

• Lý thuyết: Scenario, Module, Router trong Make; so sánh visual với n8n.

• Thực hành: Dựng lại workflow tương tự trong Make, so sánh UX với n8n/Zapier.

Ngày 133: Testing Strategy cho Automation

• Mục tiêu: Đưa automation vào quy trình kiểm thử như code thật.

• Lý thuyết: Unit test cho Code node (Jest), test workflow bằng mock webhook, CI cho n8n (export/import JSON qua Git).

• Thực hành: Setup Git-based version control cho các workflow đã xây, viết 1 test kiểm tra Code node đồng bộ dữ liệu.

Ngày 134: So sánh & Chọn công cụ Workflow

• Mục tiêu: Có framework quyết định n8n vs Zapier vs Make cho từng tình huống.

• Lý thuyết: Bảng so sánh chi phí, độ phức tạp cho phép, self-host.

• Thực hành: Viết bảng so sánh 3 công cụ dựa trên trải nghiệm thực tế toàn Phase 4.

Ngày 135: Capstone Phase 4 - Demo Day

• Mục tiêu: Tổng kết toàn bộ Phase 4.

• Lý thuyết: Ôn tập toàn bộ workflow đã xây.

• Thực hành: Demo end-to-end 4 workflow (Onboarding, Approval, Incident, Ticket) chạy trên n8n Queue Mode, kèm error workflow và monitoring.

PHASE 5 - Browser Automation & RPA (Ngày 136–165)

TUẦN 28 - BROWSER FUNDAMENTALS

Ngày 136: DOM & CSS Selector

• Mục tiêu: Xác định chính xác một phần tử trên trang web.

• Lý thuyết: DOM tree, CSS selector (class, id, attribute, nth-child).

• Thực hành: Mở DevTools trên 1 trang web bất kỳ, viết 5 CSS selector khác nhau trỏ đúng 1 nút bấm.

Ngày 137: XPath

• Mục tiêu: Chọn phần tử trong trường hợp CSS selector không đủ mạnh.

• Lý thuyết: XPath syntax, absolute vs relative path, axes (following-sibling, ancestor).

• Thực hành: Viết XPath tìm 1 dòng trong bảng dựa vào nội dung text của ô bên cạnh.

Ngày 138: Shadow DOM

• Mục tiêu: Xử lý được các trang dùng Web Component.

• Lý thuyết: Shadow DOM là gì, vì sao selector thông thường không xuyên qua được.

• Thực hành: Tìm 1 trang có Shadow DOM (ví dụ có <custom-element>), thử truy cập qua DevTools Console.

Ngày 139: SPA Behavior

• Mục tiêu: Hiểu vì sao automation trên SPA khó hơn trang tĩnh.

• Lý thuyết: Client-side rendering, phần tử xuất hiện trễ (async render), network idle.

• Thực hành: Quan sát Network tab của 1 SPA (React/Vue) để thấy dữ liệu load sau khi trang đã hiển thị.

Ngày 140: Ôn tập & Chuẩn bị Playwright

• Mục tiêu: Củng cố nền tảng trước khi vào công cụ chính.

• Lý thuyết: Ôn tập selector, XPath, Shadow DOM, SPA.

• Thực hành: Setup môi trường Node.js + Playwright, chạy thử script mẫu đầu tiên.

TUẦN 29 - PLAYWRIGHT CORE

Ngày 141: Locator

• Mục tiêu: Viết locator ổn định, ít bị "flaky".

• Lý thuyết: page.locator(), auto-waiting, best practice chọn locator (role, text > CSS mong manh).

• Thực hành: Viết script mở trang demo, dùng locator theo role/text để click và điền form.

Ngày 142: Browser Context

• Mục tiêu: Chạy nhiều phiên độc lập (nhiều user) trong 1 script.

• Lý thuyết: Browser vs Context vs Page, cách context cô lập cookie/session.

• Thực hành: Mở 2 context riêng biệt mô phỏng 2 user đăng nhập cùng lúc vào 1 trang.

Ngày 143: Storage State

• Mục tiêu: Không phải login lại mỗi lần chạy script.

• Lý thuyết: storageState, lưu và tái sử dụng session.

• Thực hành: Login 1 lần, lưu storage state ra file, viết script thứ 2 tái sử dụng session đó.

Ngày 144: Debug Playwright Script

• Mục tiêu: Tự tìm ra lý do script fail.

• Lý thuyết: Playwright Inspector, trace viewer, screenshot on failure.

• Thực hành: Cố tình viết 1 selector sai, dùng trace viewer để debug và sửa.

Ngày 145: Practice - Form Automation

• Mục tiêu: Củng cố kỹ năng core qua bài thực tế.

• Lý thuyết: Ôn tập locator, context, storage state.

• Thực hành: Viết script tự động điền và submit 1 form nhiều bước (multi-step form) trên trang demo.

TUẦN 30 - PLAYWRIGHT ADVANCED

Ngày 146: Network Interception

• Mục tiêu: Kiểm soát request/response của trang trong lúc automation.

• Lý thuyết: page.route(), mock response, chặn request không cần thiết (ảnh, ads) để tăng tốc.

• Thực hành: Viết script chặn toàn bộ request ảnh để tăng tốc độ chạy, mock 1 API response để test UI.

Ngày 147: File Upload & Download

• Mục tiêu: Tự động hóa thao tác file trên trình duyệt.

• Lý thuyết: setInputFiles(), xử lý download event.

• Thực hành: Viết script upload 1 file lên form demo, và script tải file xuống rồi verify nội dung.

Ngày 148: Authentication Reuse ở quy mô lớn

• Mục tiêu: Chạy hàng loạt script với nhiều tài khoản khác nhau hiệu quả.

• Lý thuyết: Storage state per-user, global setup trong Playwright Test.

• Thực hành: Cấu hình globalSetup login sẵn 3 tài khoản, mỗi test dùng đúng storage state tương ứng.

Ngày 149: Xử lý Dynamic Content

• Mục tiêu: Không bị fail vì phần tử load chậm hoặc thay đổi liên tục.

• Lý thuyết: Wait strategy (waitForSelector, waitForLoadState, waitForResponse), tránh dùng sleep cứng.

• Thực hành: Viết script tương tác với 1 trang có loading spinner/infinite scroll, xử lý đúng bằng wait strategy.

Ngày 150: Practice - Scraping có Auth

• Mục tiêu: Kết hợp mọi kỹ thuật advanced vào 1 bài thực tế.

• Lý thuyết: Ôn tập interception, upload/download, wait strategy.

• Thực hành: Viết script login vào 1 hệ thống demo, tải báo cáo dạng file, lưu lại kèm log.

TUẦN 31 - PLAYWRIGHT PRODUCTION

Ngày 151: Parallel Execution

• Mục tiêu: Chạy nhiều test/script cùng lúc để tiết kiệm thời gian.

• Lý thuyết: Playwright Test workers, sharding.

• Thực hành: Cấu hình chạy song song 5 script trên các trang khác nhau, đo thời gian trước/sau.

Ngày 152: Docker Execution

• Mục tiêu: Chạy Playwright ổn định trên môi trường server không có GUI.

• Lý thuyết: Playwright Docker image chính thức, headless mode.

• Thực hành: Đóng gói script thành Docker image, chạy thử trong container.

Ngày 153: CI/CD Integration

• Mục tiêu: Tự động chạy automation mỗi khi có thay đổi code.

• Lý thuyết: GitHub Actions cơ bản, cache dependency để chạy nhanh hơn.

• Thực hành: Viết GitHub Actions workflow chạy script Playwright mỗi khi push code, upload report khi fail.

Ngày 154: Project - Employee Portal Automation

• Mục tiêu: Tự động hóa thao tác lặp lại trên 1 hệ thống nội bộ giả lập.

• Lý thuyết: Xác định quy trình thủ công lặp lại phù hợp để tự động hóa.

• Thực hành: Viết script tự động login + trích xuất dữ liệu nhân viên từ 1 "Employee Portal" demo, xuất ra CSV.

Ngày 155: Hoàn thiện Employee Portal Automation

• Mục tiêu: Đưa script vào chạy định kỳ ổn định.

• Lý thuyết: Kết hợp với n8n (Phase 4) để trigger script theo lịch.

• Thực hành: Đóng gói script thành job chạy hàng ngày qua cron/n8n, gửi báo cáo CSV qua Slack.

TUẦN 32 - LEGACY SYSTEM, SELENIUM & PUPPETEER

Ngày 156: Project - Legacy System Automation

• Mục tiêu: Tự động hóa 1 hệ thống cũ không có API.

• Lý thuyết: Chiến lược automation khi UI không ổn định (legacy system thường vậy).

• Thực hành: Viết script tương tác với 1 trang demo giả lập hệ thống cũ (nhiều iframe, table lồng nhau).

Ngày 157: Project - Automated Data Collection

• Mục tiêu: Thu thập dữ liệu định kỳ từ nhiều nguồn web.

• Lý thuyết: Retry strategy khi trang lỗi tạm thời, rate limit khi scrape.

• Thực hành: Viết script thu thập dữ liệu từ 2-3 trang demo, tổng hợp vào 1 file, có retry khi lỗi.

Ngày 158: Selenium Overview

• Mục tiêu: Đọc hiểu và maintain được hệ thống automation cũ dùng Selenium.

• Lý thuyết: WebDriver protocol, so sánh kiến trúc với Playwright.

• Thực hành: Đọc 1 script Selenium mẫu, giải thích từng dòng, chuyển đổi thử sang Playwright.

Ngày 159: Selenium Grid & Remote Driver

• Mục tiêu: Hiểu cách chạy Selenium ở quy mô lớn trong tổ chức cũ.

• Lý thuyết: Selenium Grid architecture (Hub/Node), Remote WebDriver.

• Thực hành: Đọc kiến trúc 1 Selenium Grid mẫu, vẽ sơ đồ Hub-Node.

Ngày 160: Puppeteer

• Mục tiêu: Dùng đúng công cụ cho use case sinh PDF/screenshot.

• Lý thuyết: Puppeteer API cơ bản, page.pdf(), page.screenshot().

• Thực hành: Viết service nhỏ nhận URL, trả về PDF của trang đó (dùng cho báo cáo tự động).

TUẦN 33 - RPA & CAPSTONE

Ngày 161: UiPath Overview

• Mục tiêu: Hiểu RPA truyền thống khác gì với code-based automation.

• Lý thuyết: UiPath Studio (visual workflow), Robot, Orchestrator (quản lý tập trung).

• Thực hành: Cài UiPath Studio (Community), dựng 1 workflow đơn giản kéo-thả (mở app, nhập liệu).

Ngày 162: UiPath Orchestrator

• Mục tiêu: Hiểu cách vận hành RPA ở quy mô doanh nghiệp.

• Lý thuyết: Queue, Job, Schedule trong Orchestrator; so sánh với n8n Queue Mode.

• Thực hành: Đọc tài liệu Orchestrator, viết bảng so sánh UiPath vs n8n cho từng loại use case.

Ngày 163: Power Automate Overview

• Mục tiêu: Biết làm việc với doanh nghiệp dùng hệ sinh thái Microsoft.

• Lý thuyết: Power Automate Cloud Flow vs Desktop Flow, tích hợp Microsoft 365.

• Thực hành: Dựng thử 1 flow đơn giản trong Power Automate (ví dụ: email mới → lưu file đính kèm vào OneDrive).

Ngày 164: So sánh toàn bộ hệ Browser Automation & RPA

• Mục tiêu: Có bộ tiêu chí chọn công cụ đúng cho từng bài toán.

• Lý thuyết: Bảng so sánh Playwright/Selenium/Puppeteer/UiPath/Power Automate theo: có API hay không, độ ổn định UI, chi phí, đối tượng người dùng.

• Thực hành: Viết bảng so sánh đầy đủ 5 công cụ.

Ngày 165: Capstone Phase 5

• Mục tiêu: Tổng kết Phase 5.

• Lý thuyết: Ôn tập toàn bộ.

• Thực hành: Demo: Employee Portal Automation + Data Collection chạy trong Docker qua CI/CD, kèm báo cáo PDF sinh bởi Puppeteer.

PHASE 6 - BPM & Process Engineering (Ngày 166–195)

TUẦN 34 - BPMN FUNDAMENTALS

Ngày 166: Event trong BPMN

• Mục tiêu: Mô hình hóa điểm bắt đầu/kết thúc/trung gian của quy trình.

• Lý thuyết: Start Event, End Event, Intermediate Event (Timer, Message, Error).

• Thực hành: Vẽ 1 quy trình đơn giản (nghỉ phép) chỉ dùng Start/End Event và Task.

Ngày 167: Task trong BPMN

• Mục tiêu: Phân biệt các loại công việc trong quy trình.

• Lý thuyết: User Task, Service Task, Script Task, Send/Receive Task.

• Thực hành: Bổ sung quy trình nghỉ phép: User Task "nhân viên nộp đơn" → Service Task "gửi email tự động".

Ngày 168: Gateway

• Mục tiêu: Mô hình hóa logic rẽ nhánh/hội tụ trong quy trình.

• Lý thuyết: Exclusive Gateway (XOR), Parallel Gateway (AND), Inclusive Gateway (OR).

• Thực hành: Thêm Exclusive Gateway: nếu số ngày nghỉ > 3 thì cần thêm 1 cấp duyệt.

Ngày 169: Subprocess

• Mục tiêu: Đóng gói quy trình con để tái sử dụng và dễ đọc.

• Lý thuyết: Embedded Subprocess vs Call Activity.

• Thực hành: Tách phần "duyệt đơn" thành 1 subprocess riêng, gọi lại từ quy trình chính.

Ngày 170: Practice - BPMN Modeling

• Mục tiêu: Tự vẽ được 1 quy trình nghiệp vụ hoàn chỉnh.

• Lý thuyết: Ôn tập Event/Task/Gateway/Subprocess.

• Thực hành: Vẽ hoàn chỉnh quy trình "Nghỉ phép" đầy đủ từ nộp đơn tới thông báo kết quả bằng công cụ BPMN.io.

TUẦN 35 - DMN & CHUẨN BỊ CAMUNDA

Ngày 171: DMN Fundamentals

• Mục tiêu: Tách logic quyết định ra khỏi luồng quy trình.

• Lý thuyết: Decision Table, Hit Policy (Unique, First, Collect).

• Thực hành: Vẽ 1 Decision Table đơn giản: mức duyệt nghỉ phép dựa trên số ngày + cấp bậc nhân viên.

Ngày 172: DMN nâng cao

• Mục tiêu: Xử lý quyết định phức tạp nhiều điều kiện.

• Lý thuyết: FEEL expression language cơ bản trong DMN.

• Thực hành: Viết DMN table dùng FEEL expression cho quy tắc duyệt chi phí theo nhiều điều kiện (số tiền, phòng ban, loại chi phí).

Ngày 173: Kết hợp BPMN + DMN

• Mục tiêu: Gọi bảng quyết định từ trong quy trình.

• Lý thuyết: Business Rule Task trong BPMN gọi DMN.

• Thực hành: Gắn Decision Table Ngày 171 vào Gateway của quy trình nghỉ phép Ngày 170.

Ngày 174: Cài đặt Camunda Platform 8

• Mục tiêu: Chuẩn bị môi trường thực thi cho quy trình đã vẽ.

• Lý thuyết: Kiến trúc Camunda 8 (Zeebe engine, Operate, Tasklist).

• Thực hành: Cài Camunda 8 (Docker Compose/SaaS trial), deploy thử quy trình nghỉ phép.

Ngày 175: Practice - Deploy quy trình đầu tiên

• Mục tiêu: Chạy được 1 process instance thực tế trên Camunda.

• Lý thuyết: Process Instance, Operate UI để theo dõi.

• Thực hành: Khởi tạo 1 process instance nghỉ phép, theo dõi trạng thái qua Camunda Operate.

TUẦN 36 - CAMUNDA CORE

Ngày 176: Process Engine sâu hơn

• Mục tiêu: Hiểu cách Zeebe thực thi và lưu trạng thái quy trình.

• Lý thuyết: Event-driven execution trong Zeebe, process variable.

• Thực hành: Thêm process variable (số ngày nghỉ, tên nhân viên) và quan sát cách chúng thay đổi qua từng bước trong Operate.

Ngày 177: Worker cơ bản

• Mục tiêu: Kết nối code bên ngoài để xử lý Service Task.

• Lý thuyết: Job Worker pattern, polling job.

• Thực hành: Viết 1 worker Node.js xử lý Service Task "gửi email" bằng Zeebe client SDK.

Ngày 178: Message Correlation

• Mục tiêu: Cho quy trình "chờ" một sự kiện từ bên ngoài.

• Lý thuyết: Message Event, correlation key.

• Thực hành: Thêm Intermediate Message Event chờ "kết quả duyệt" gửi từ hệ thống ngoài (giả lập qua API call).

Ngày 179: External Task Pattern

• Mục tiêu: Xử lý Service Task với worker độc lập, có thể scale riêng.

• Lý thuyết: So sánh External Task Worker với Job Worker của Zeebe.

• Thực hành: Viết 1 external worker riêng biệt xử lý bước "tính toán số ngày nghỉ còn lại".

Ngày 180: Practice - Error Handling trong Camunda

• Mục tiêu: Quy trình không bị "treo" khi worker lỗi.

• Lý thuyết: BPMN Error Event, retry trong Job Worker.

• Thực hành: Giả lập worker Ngày 177 lỗi 2 lần đầu, cấu hình retry và Error Boundary Event xử lý khi hết retry.

TUẦN 37 - CAMUNDA ADVANCED

Ngày 181: Timer Event

• Mục tiêu: Xử lý deadline/escalation trong quy trình.

• Lý thuyết: Timer Boundary Event, Timer Start Event.

• Thực hành: Thêm Timer Boundary Event: nếu quản lý không duyệt trong 24h thì tự escalate (tương tự Approval Flow Phase 4 nhưng ở tầng BPM).

Ngày 182: Multi-instance

• Mục tiêu: Lặp lại 1 bước cho nhiều đối tượng (ví dụ nhiều người duyệt).

• Lý thuyết: Multi-instance Marker (parallel/sequential), collection variable.

• Thực hành: Cấu hình bước duyệt song song bởi 3 người, quy trình tiếp tục khi đủ 2/3 duyệt.

Ngày 183: Versioning quy trình

• Mục tiêu: Cập nhật quy trình đang chạy mà không phá vỡ instance cũ.

• Lý thuyết: Process version trong Camunda, migration.

• Thực hành: Deploy version 2 của quy trình nghỉ phép (thêm 1 bước mới), quan sát instance cũ vẫn chạy version 1.

Ngày 184: Monitoring quy trình

• Mục tiêu: Biết instance nào đang bị kẹt, tỉ lệ hoàn thành ra sao.

• Lý thuyết: Camunda Operate metrics, incident view.

• Thực hành: Cố tình tạo 1 incident (worker lỗi liên tục), xem cách Operate hiển thị và xử lý.

Ngày 185: Practice - Tổng hợp Camunda

• Mục tiêu: Củng cố toàn bộ kỹ năng Camunda trước khi vào project lớn.

• Lý thuyết: Ôn tập Worker, Message, Timer, Multi-instance.

• Thực hành: Hoàn thiện quy trình nghỉ phép đầy đủ: DMN duyệt tự động, escalation, multi-approval, error handling.

TUẦN 38 - PROJECT: PROCUREMENT PROCESS

Ngày 186: Thiết kế Procurement Process

• Mục tiêu: Mô hình hóa 1 quy trình doanh nghiệp phức tạp hơn.

• Lý thuyết: Các bước procurement thực tế (yêu cầu mua → duyệt → chọn nhà cung cấp → tạo PO → nhận hàng).

• Thực hành: Vẽ BPMN đầy đủ cho quy trình Procurement gồm ít nhất 2 Gateway và 1 Subprocess.

Ngày 187: DMN cho Procurement

• Mục tiêu: Tự động hóa quyết định "ai duyệt, cần bao nhiêu cấp duyệt".

• Lý thuyết: Ôn tập Decision Table nhiều điều kiện.

• Thực hành: Viết DMN table xác định số cấp duyệt dựa trên giá trị đơn hàng.

Ngày 188: Worker cho Procurement

• Mục tiêu: Kết nối quy trình với hệ thống thật (giả lập).

• Lý thuyết: Ôn tập Job Worker/External Task.

• Thực hành: Viết worker tạo Purchase Order (PO) trong DB (Phase 1) khi quy trình tới bước đó.

Ngày 189: Test Procurement Process

• Mục tiêu: Đảm bảo quy trình chạy đúng ở nhiều kịch bản giá trị đơn hàng khác nhau.

• Lý thuyết: Test case theo từng nhánh Gateway.

• Thực hành: Chạy 3 process instance với giá trị đơn hàng khác nhau, xác nhận đúng số cấp duyệt.

Ngày 190: Hoàn thiện Procurement Process

• Mục tiêu: Đưa quy trình sẵn sàng demo.

• Lý thuyết: Ôn tập toàn bộ.

• Thực hành: Review và tối ưu lại BPMN, viết tài liệu mô tả quy trình cho người không kỹ thuật đọc hiểu.

TUẦN 39 - PROJECT: CHANGE REQUEST & INCIDENT WORKFLOW

Ngày 191: Thiết kế Change Request Workflow

• Mục tiêu: Mô hình hóa quy trình quản lý thay đổi (ITIL-style).

• Lý thuyết: Change Advisory Board (CAB) pattern, risk assessment.

• Thực hành: Vẽ BPMN cho Change Request: submit → risk assessment (DMN) → CAB approval → implement → review.

Ngày 192: Xây Change Request Workflow

• Mục tiêu: Hiện thực hóa quy trình đã vẽ.

• Lý thuyết: Ôn tập Business Rule Task, Multi-instance approval.

• Thực hành: Deploy và test Change Request Workflow với dữ liệu giả lập.

Ngày 193: Thiết kế Incident Workflow (tầng BPM)

• Mục tiêu: So sánh Incident Automation ở n8n (Phase 4) với cách BPM engine quản lý.

• Lý thuyết: Khi nào nên dùng BPM engine thay vì workflow tool (quy trình dài, cần audit trail chặt, nhiều bên liên quan).

• Thực hành: Vẽ BPMN cho Incident Workflow có SLA timer và escalation nhiều cấp.

Ngày 194: Xây & Test Incident Workflow

• Mục tiêu: Hoàn thiện quy trình sự cố có theo dõi SLA.

• Lý thuyết: Ôn tập Timer Event, Error Event.

• Thực hành: Deploy, test với kịch bản SLA bị vi phạm để xác nhận escalation hoạt động đúng.

Ngày 195: Capstone Phase 6

• Mục tiêu: Tổng kết toàn bộ Phase 6.

• Lý thuyết: Ôn tập BPMN, DMN, Camunda.

• Thực hành: Demo 3 quy trình (Procurement, Change Request, Incident) chạy trên cùng 1 Camunda cluster, kèm tài liệu so sánh "khi nào dùng BPM engine vs khi nào dùng n8n".

PHASE 7 Messaging & Event Driven Architecture (Ngày 196–225)

TUẦN 40 REDIS

Ngày 196: Redis Data Structures

• Mục tiêu: Chọn đúng cấu trúc dữ liệu cho từng bài toán cache.

• Lý thuyết: String, Hash, List, Set, Sorted Set; TTL.

• Thực hành: Dùng redis-cli lưu và truy vấn thử cả 5 kiểu dữ liệu với dữ liệu Task (Phase 2).

Ngày 197: Caching Pattern

• Mục tiêu: Giảm tải cho DB bằng cache đúng cách.

• Lý thuyết: Cache-aside pattern, cache invalidation, TTL strategy.

• Thực hành: Thêm Redis cache-aside cho API GET /tasks (Phase 2), đo tốc độ trước/sau.

Ngày 198: Rate Limiting với Redis

• Mục tiêu: Bảo vệ API khỏi bị gọi quá tải.

• Lý thuyết: Token bucket, fixed window, sliding window algorithm.

• Thực hành: Implement rate limit 100 request/phút cho API Task bằng Redis (sliding window).

Ngày 199: Redis Pub/Sub

• Mục tiêu: Hiểu giới hạn của Redis khi dùng làm message broker.

• Lý thuyết: Pub/Sub cơ bản, vì sao không đảm bảo delivery (khác Kafka/RabbitMQ).

• Thực hành: Viết demo publisher/subscriber đơn giản, tắt subscriber giữa chừng để quan sát mất message.

Ngày 200: Practice Redis Production Checklist

• Mục tiêu: Biết vận hành Redis an toàn.

• Lý thuyết: Persistence (RDB/AOF), eviction policy, memory limit.

• Thực hành: Cấu hình 1 Redis instance với maxmemory + eviction policy phù hợp cho cache.

TUẦN 41 RABBITMQ CƠ BẢN

Ngày 201: RabbitMQ Fundamentals

• Mục tiêu: Hiểu message broker khác cache/pub-sub thế nào.

• Lý thuyết: Producer, Consumer, Queue, Message durability.

• Thực hành: Cài RabbitMQ (Docker), gửi/nhận 1 message đơn giản qua queue.

Ngày 202: Exchange Types

• Mục tiêu: Định tuyến message linh hoạt tới đúng queue.

• Lý thuyết: Direct, Fanout, Topic, Headers Exchange.

• Thực hành: Dựng 1 Fanout Exchange gửi cùng 1 sự kiện "Task created" tới 3 queue khác nhau (email, Slack, log).

Ngày 203: Routing

• Mục tiêu: Chỉ gửi message tới đúng consumer cần thiết.

• Lý thuyết: Routing key, binding trong Topic Exchange.

• Thực hành: Dùng Topic Exchange với routing key task.created.high_priority để chỉ route task ưu tiên cao tới queue riêng.

Ngày 204: Queue Binding & Practice

• Mục tiêu: Củng cố kỹ năng thiết kế topology RabbitMQ.

• Lý thuyết: Ôn tập exchange + binding.

• Thực hành: Vẽ sơ đồ topology cho hệ thống Task với 3 loại consumer khác nhau.

Ngày 205: Consumer Acknowledgment

• Mục tiêu: Không mất message khi consumer crash giữa chừng.

• Lý thuyết: ack/nack, prefetch count.

• Thực hành: Viết consumer chỉ ack sau khi xử lý xong, giả lập consumer crash để xác nhận message không mất.

TUẦN 42 RABBITMQ ADVANCED

Ngày 206: Dead Letter Queue

• Mục tiêu: Không để message lỗi biến mất âm thầm.

• Lý thuyết: DLX (Dead Letter Exchange), khi nào message vào DLQ (reject, TTL hết hạn).

• Thực hành: Cấu hình DLQ cho queue Task, giả lập message lỗi liên tục để xác nhận nó rơi vào DLQ.

Ngày 207: Retry Pattern trong RabbitMQ

• Mục tiêu: Tự động thử lại message lỗi trước khi bỏ cuộc.

• Lý thuyết: Delay queue pattern (TTL + DLX kết hợp) vì RabbitMQ không có retry sẵn.

• Thực hành: Implement retry 3 lần với delay tăng dần bằng kỹ thuật delay queue.

Ngày 208: Priority Queue

• Mục tiêu: Xử lý message quan trọng trước.

• Lý thuyết: Priority Queue trong RabbitMQ, giới hạn thực tế.

• Thực hành: Cấu hình queue có priority, gửi message với độ ưu tiên khác nhau, quan sát thứ tự xử lý.

Ngày 209: Monitoring RabbitMQ

• Mục tiêu: Biết queue nào đang bị nghẽn.

• Lý thuyết: RabbitMQ Management UI, các chỉ số quan trọng (queue length, consumer count).

• Thực hành: Xem Management UI, giả lập consumer chậm để queue length tăng, xác định vấn đề.

Ngày 210: Practice RabbitMQ Production Setup

• Mục tiêu: Tổng hợp kỹ năng RabbitMQ vào 1 hệ thống hoàn chỉnh.

• Lý thuyết: Ôn tập DLQ, retry, priority.

• Thực hành: Hoàn thiện topology Task Notification với DLQ + retry + priority queue.

TUẦN 43 KAFKA CƠ BẢN

Ngày 211: Kafka Fundamentals

• Mục tiêu: Hiểu vì sao Kafka phù hợp cho luồng sự kiện lớn, khác RabbitMQ.

• Lý thuyết: Topic, Log-based storage, so sánh Kafka vs RabbitMQ (message queue vs event log).

• Thực hành: Cài Kafka (Docker/Redpanda), tạo 1 topic, gửi/nhận message bằng CLI.

Ngày 212: Partition

• Mục tiêu: Hiểu cách Kafka scale bằng partition.

• Lý thuyết: Partition, partition key, thứ tự message chỉ đảm bảo trong 1 partition.

• Thực hành: Tạo topic 3 partition, gửi message với key khác nhau, quan sát message rơi vào partition nào.

Ngày 213: Producer/Consumer với Client Library

• Mục tiêu: Viết code thật thay vì chỉ dùng CLI.

• Lý thuyết: KafkaJS (Node.js) cơ bản, producer config (acks).

• Thực hành: Viết producer gửi sự kiện "Task created" và consumer đọc lại bằng KafkaJS.

Ngày 214: Serialization

• Mục tiêu: Đảm bảo dữ liệu giữa producer/consumer đồng bộ định dạng.

• Lý thuyết: JSON vs Avro/Protobuf, Schema Registry ở mức khái niệm.

• Thực hành: Định nghĩa schema JSON cho event Task, validate trước khi gửi vào Kafka.

Ngày 215: Practice Event Producer/Consumer

• Mục tiêu: Củng cố kỹ năng Kafka core.

• Lý thuyết: Ôn tập topic, partition, producer/consumer.

• Thực hành: Xây pipeline: API Task (Phase 2) publish sự kiện vào Kafka, 1 consumer riêng ghi log ra file.

TUẦN 44 KAFKA ADVANCED

Ngày 216: Consumer Group

• Mục tiêu: Scale việc xử lý message bằng nhiều consumer.

• Lý thuyết: Consumer Group, mỗi partition chỉ 1 consumer trong group xử lý.

• Thực hành: Chạy 3 consumer cùng group đọc topic 3 partition, quan sát cách chia tải.

Ngày 217: Offset Management

• Mục tiêu: Kiểm soát chính xác message đã xử lý tới đâu.

• Lý thuyết: Auto commit vs manual commit offset, at-least-once vs at-most-once.

• Thực hành: Chuyển consumer sang manual commit, giả lập crash trước khi commit để quan sát message được xử lý lại.

Ngày 218: Rebalance

• Mục tiêu: Hiểu điều gì xảy ra khi consumer join/leave group.

• Lý thuyết: Rebalance protocol, ảnh hưởng tới xử lý (dừng tạm thời).

• Thực hành: Thêm/bớt consumer khi đang chạy, quan sát log rebalance.

Ngày 219: Kafka Streams / Stateful Processing (overview)

• Mục tiêu: Biết Kafka còn dùng được cho xử lý luồng dữ liệu real-time.

• Lý thuyết: Khái niệm stream processing, windowing (chỉ overview, không đi sâu).

• Thực hành: Đọc 1 ví dụ Kafka Streams tính tổng số Task tạo mới theo cửa sổ 5 phút, giải thích logic.

Ngày 220: Practice Kafka Monitoring

• Mục tiêu: Biết theo dõi sức khỏe cụm Kafka.

• Lý thuyết: Consumer lag, các chỉ số quan trọng.

• Thực hành: Đo consumer lag khi cố tình cho consumer chạy chậm hơn producer.

TUẦN 45 PATTERNS & CAPSTONE

Ngày 221: Outbox Pattern

• Mục tiêu: Đảm bảo ghi DB và publish event là nhất quán (atomic).

• Lý thuyết: Vấn đề dual-write, Outbox Pattern giải quyết thế nào.

• Thực hành: Implement Outbox table trong Postgres (Phase 1), viết 1 worker đọc outbox và publish vào Kafka.

Ngày 222: Saga Pattern

• Mục tiêu: Quản lý transaction xuyên nhiều service không dùng distributed transaction.

• Lý thuyết: Choreography-based Saga vs Orchestration-based Saga, so sánh với Camunda (Phase 6).

• Thực hành: Thiết kế (trên giấy) 1 Saga cho quy trình "Đặt hàng" gồm 3 service, có bước compensating transaction khi lỗi.

Ngày 223: Event Sourcing (Overview)

• Mục tiêu: Biết khi nào nên cân nhắc lưu trạng thái bằng chuỗi sự kiện thay vì snapshot.

• Lý thuyết: Event Store, rebuild state từ event, trade-off độ phức tạp.

• Thực hành: Viết ví dụ nhỏ: tính số dư tài khoản bằng cách replay danh sách sự kiện (deposit/withdraw) thay vì đọc trực tiếp 1 cột balance.

Ngày 224: Kết hợp Messaging với Automation đã học

• Mục tiêu: Thấy rõ vị trí của messaging trong toàn bộ automation platform.

• Lý thuyết: Khi nào dùng RabbitMQ, khi nào dùng Kafka, khi nào webhook (Phase 2) là đủ.

• Thực hành: Viết bảng quyết định "chọn kiểu giao tiếp nào" theo: volume, cần thứ tự hay không, cần replay hay không.

Ngày 225: Capstone Phase 7

• Mục tiêu: Tổng hợp toàn bộ Phase 7 vào 1 hệ thống.

• Lý thuyết: Ôn tập Outbox, Saga, Redis, RabbitMQ, Kafka.

• Thực hành: Demo pipeline: API Task ghi Outbox → publish Kafka → 1 consumer cập nhật cache Redis → 1 consumer khác gửi vào RabbitMQ để n8n (Phase 4) xử lý tiếp.