Cogover Learning

Cogover Platform — Tổng quan nâng cao

Cogover Platform là nền tảng low-code/no-code giúp doanh nghiệp số hóa và quản lý hoạt động kinh doanh. Nền tảng được tổ chức theo ba tầng: Object Manager, Business Logic và Application. Mỗi tầng sử dụng các thành phần của tầng bên dưới.

Tài liệu này trình bày kiến trúc ba tầng, các nhóm khả năng chính và cách chúng liên kết với nhau. Tính năng có sẵn và mức độ tùy chỉnh cần được kiểm tra trên từng workspace trước khi triển khai.

Kiến trúc ba tầng

Kiến trúc ba tầng của Cogover Platform

Tầng Vai trò Thành phần chính
1. Object Manager Quản lý dữ liệu có cấu trúc và giao diện làm việc với bản ghi Object, field, layout, action, UI Rules, Data Security Rules, Transition Rules, Duplicate Rules và Field Change History
2. Business Logic Xử lý nghiệp vụ trên dữ liệu của Tầng 1 Process, App/Menu, Role và phân quyền, thông báo, mẫu văn bản, Assignment Rules, email, report, dashboard và API
3. Application Cung cấp các miền ứng dụng được cấu hình theo workspace Sales, Inventory, People, Process, Omni Channel, Finance, Service, Manufacture và Goal

Mối liên kết giữa dữ liệu, quy trình, ứng dụng và báo cáo

Tầng 1 — Object Manager

Object Manager biến dữ liệu nghiệp vụ thành các Object có cấu trúc. Có thể đối chiếu Object với bảng, Field với cột và Record với dòng trong cơ sở dữ liệu. Khác với một bảng dữ liệu thuần, Object đi kèm giao diện, phân quyền và các module quản trị bản ghi.

Thiết kế database-first, rồi mới bổ sung khả năng low-code

Khi thiết kế một ứng dụng mới, cần xây dựng mô hình dữ liệu trước khi tạo cấu hình trên workspace:

  1. Xác định các thực thể cần quản lý.
  2. Xác định thuộc tính và trạng thái của từng thực thể.
  3. Thiết kế quan hệ một–một, một–nhiều hoặc nhiều–nhiều.
  4. Chọn kiểu field phù hợp cho từng thuộc tính.
  5. Tạo Object theo thứ tự phụ thuộc: Object được tham chiếu phải có trước Object chứa lookup.
  6. Bổ sung layout, Owner, Transition Rules, UI Rules, Data Security Rules, Duplicate Rules, Field Change History và action khi nghiệp vụ cần.

Với quan hệ nhiều–nhiều, có thể dùng lookup nhiều giá trị hoặc tạo Object trung gian. Object trung gian phù hợp khi quan hệ có thuộc tính riêng. Ví dụ, dòng đơn hàng liên kết Đơn hàng với Sản phẩm và đồng thời lưu số lượng, đơn giá hoặc chiết khấu.

Chọn field theo ngữ nghĩa, không theo hình thức hiển thị

Các nhóm field thường gặp gồm văn bản, số, tiền tệ, tỷ lệ, lựa chọn, ngày giờ, tệp, liên kết Object và trường tính toán. Việc chọn kiểu field dựa trên cách dữ liệu được nhập, kiểm tra và sử dụng:

  • Dùng mã tự sinh khi mã phải duy nhất và không phụ thuộc thao tác nhập tay.
  • Dùng kiểu tiền tệ cho giá trị tài chính thay vì số thập phân chung chung.
  • Dùng lựa chọn đơn cho trạng thái hoặc phân loại có tập giá trị kiểm soát.
  • Dùng khoảng ngày/giờ khi nghiệp vụ cần cả điểm bắt đầu và kết thúc.
  • Dùng Formula cho phép tính trên một record; dùng tổng hợp quan hệ khi kết quả đến từ nhiều record liên quan.
  • Dùng quan hệ phụ thuộc khi record con không có ý nghĩa nếu thiếu record cha; không suy đoán hành vi xóa mà chưa kiểm chứng.

Các module quản trị Object

Object Manager có tám nhóm khả năng chính:

  1. Object & Field Definition: định nghĩa Object, field, option, Formula và quan hệ giữa các Object. Formula sử dụng Cogover Scripting, có cú pháp gần Java và hỗ trợ biểu thức, điều kiện, vòng lặp, kiểu dữ liệu cùng các hàm nghiệp vụ.
  2. Layout Builder: thiết kế giao diện Tạo, Xem/Sửa hoặc giao diện kết hợp Tạo/Xem/Sửa. Field được bố trí trong Section và Group; mỗi Group có thể cấu hình số cột.
  3. Action và Action Sequence: định nghĩa hành động trên record và nối nhiều hành động thành chuỗi.
  4. UI Rules: ẩn hoặc hiện field, đặt field bắt buộc hoặc chỉ đọc theo điều kiện dữ liệu.
  5. Data Security Rules: kiểm soát quyền xem, sửa hoặc xóa record theo Owner, phòng ban, vai trò và phạm vi chia sẻ.
  6. Transition Rules: quy định trạng thái được phép chuyển, điều kiện trước khi chuyển và hành động trước hoặc sau khi chuyển.
  7. Duplicate Rules: phát hiện và xử lý record trùng dựa trên các field so sánh.
  8. Field Change History: ghi nhận giá trị trước, giá trị sau, thời điểm và người thực hiện thay đổi.

Layout có thể dùng JavaScript cho các yêu cầu giao diện phức tạp như ẩn/hiện, bắt buộc, chỉ đọc, giới hạn lựa chọn, tự điền giá trị hoặc làm việc với related list. Khi sửa layout hiện có, cần đọc cấu hình và script đang dùng để không làm mất logic ngoài phạm vi thay đổi.

Tầng 2 — Business Logic

Business Logic kết hợp dữ liệu và giao diện của Object Manager thành quy trình, quyền, menu, tài liệu, báo cáo và tích hợp.

Chọn đúng loại quy trình theo cơ chế khởi chạy

Loại quy trình Khi phù hợp Ví dụ
Manual Flow Người dùng gửi một biểu mẫu để bắt đầu Xin nghỉ, đề nghị mua sắm, yêu cầu thanh toán
Normal Flow Người có quyền chủ động chạy một chuỗi xử lý Tính lại dữ liệu hoặc chạy thao tác nghiệp vụ theo yêu cầu
Scheduled Flow Công việc lặp theo lịch Nhắc hạn, kiểm tra SLA, tổng hợp định kỳ
Triggered Flow Phản ứng với thay đổi dữ liệu hoặc tín hiệu tích hợp Phân bổ lead mới, cập nhật khi đơn đổi trạng thái
Sequence Flow Theo đuổi một record qua chuỗi bước tuần tự Onboarding, nurture lead, chuỗi follow-up

Khi thiết kế Process, cần xác định mục tiêu, sự kiện bắt đầu, tiêu chí kết thúc, người tham gia, quyền chạy/xem/hủy và các nhánh ngoại lệ. Với Process có tích hợp, cần xử lý timeout, retry, lỗi và yêu cầu gửi lặp.

Các thành phần Process tiêu biểu gồm User Task, Gateway, Loop, Variable, Assignment, Organization, Wait, Sub Process, Send Email, Send HTTP Request, Send Notification, Get/Create/Update Record, To Do, Phone Call, Omni Message và Export Record.

Phân quyền là mô hình nhiều lớp

Quyền hiển thị menu và quyền truy cập dữ liệu là hai cấu hình khác nhau. Khi nghiệm thu, cần kiểm tra bốn lớp:

  1. App và menu: người dùng có nhìn thấy điểm vào hay không?
  2. Object: được tạo, đọc, cập nhật hoặc xóa loại record nào?
  3. Record: được thao tác record nào theo owner, đơn vị, vai trò hoặc điều kiện?
  4. Process: được khởi chạy, xử lý task, xem tiến độ hoặc hủy quy trình nào?

Mỗi kịch bản quyền nên được thử bằng một tài khoản được phép và một tài khoản không được phép.

Báo cáo và dashboard

Report được tạo từ dữ liệu Object dưới dạng bảng, nhóm, số liệu hoặc biểu đồ được lưu. Cần kiểm tra dữ liệu, filter, quyền và kết quả report trước khi đưa report lên dashboard. Nếu report hoặc dashboard cần xuất hiện trong App, cấu hình thêm menu và quyền truy cập tương ứng.

Yêu cầu đối với tích hợp

Cogover API cho phép hệ thống bên ngoài làm việc với tài nguyên trên nền tảng. Mỗi nhóm API có cơ chế xác thực riêng. Khi tích hợp, cần kiểm tra quyền, phân trang, xử lý lỗi, retry, idempotency và tác động đến Process, validation hoặc bảo mật dữ liệu. Không lưu thông tin xác thực trong repository hoặc log.

Ngoài Process, tầng Business Logic còn có các nhóm chức năng sau:

  • App và Menu: gom Object, saved filter, report, dashboard và các trang liên quan thành cấu trúc menu cho từng nhóm người dùng.
  • Role và phân quyền: quản lý quyền truy cập App/menu, quyền chức năng trên Object, Data Security ở cấp record và quyền Process.
  • Thông báo: gửi thông báo theo sự kiện như record mới, đổi trạng thái, đến hạn hoặc kết quả phê duyệt.
  • Mẫu văn bản: dùng dữ liệu động để tạo đề nghị, biên bản, hợp đồng và các tài liệu nghiệp vụ khác.
  • Assignment Rules: phân bổ record theo điều kiện, nhóm nhân sự, lịch hoặc tải công việc.
  • Tích hợp email: kết nối email ở cấp workspace hoặc cá nhân để gửi, nhận và liên kết lịch sử với record.

Khả năng cấu hình cụ thể của thông báo, Assignment Rules và email cần được kiểm tra trên workspace. Một bước gửi thông báo, gửi email hoặc gán giá trị trong Process không thay thế cho toàn bộ module cấu hình tương ứng.

Tầng 3 — Application

Các miền ứng dụng được lắp ghép từ Object, layout, rule, Process, permission, report, dashboard và App menu của hai tầng dưới.

Miền ứng dụng Phạm vi chuẩn hoặc mô hình tham khảo
Sales Khách hàng và người liên hệ; lead, cơ hội, đối thủ và đối tác; báo giá, hợp đồng, sản phẩm, bảng giá, đơn bán hàng, yêu cầu hỗ trợ, chiến dịch và đơn vị tính
Inventory Cấu hình kho, vị trí và tuyến cung ứng; tồn theo số lượng/lô/serial; đơn vị tính và combo; phiếu nhập/xuất/điều chuyển; phân bổ FIFO/LIFO/FEFO; nhập Excel; đồng bộ đơn hàng; kiểm kê; sổ kho; định giá và báo cáo
People Nhân sự, phòng ban, chức vụ, vai trò và các quy trình nội bộ
Process Thiết kế, kích hoạt, theo dõi và kiểm thử quy trình BPMN
Omni Channel Hội thoại đa kênh; thành viên và hồ sơ khách hàng; chuyển người phụ trách và hàng đợi; AI Agent; phân quyền; nhãn; trạng thái đã đọc; tin nhắn; tương tác; tìm kiếm và thông báo
Finance Hóa đơn khách hàng và nhà cung cấp; mua hàng và đề nghị thanh toán; phiếu thu/chi; lịch thanh toán; đặt cọc; công nợ; tạm ứng/quyết toán; ngân sách; dự báo dòng tiền và sao kê
Service Contact Center và Call Center phục vụ tiếp nhận, định tuyến và theo dõi tương tác khách hàng
Manufacture BOM nhiều cấp; lệnh sản xuất; nguyên vật liệu theo lô/serial; cấp phát, tiêu thụ, công đoạn, sản lượng, nhập thành phẩm và sửa chữa
Goal Thiết lập, theo dõi và đo lường mục tiêu theo thời gian thực với các chỉ số

Các miền như Order Management, Warranty, Purchasing, Reseller, E-Commerce, Ticket hoặc Task Management cũng có thể được mô hình hóa trên nền tảng. Đây không phải là danh sách module mặc định của mọi workspace; cần kiểm tra cấu hình thực tế trước khi lập kế hoạch.

Mối liên kết giữa các tầng

  • Từ Object Manager đến Business Logic: Object được dùng làm dữ liệu đầu vào cho Process. Ví dụ, khi một record Lead được tạo, Triggered Flow có thể chạy để phân bổ Lead.
  • Từ Business Logic đến Application: Process, quyền, menu, report và dashboard được lắp ghép thành trải nghiệm của từng ứng dụng.
  • Thay đổi xuyên tầng: thêm hoặc sửa Object, field, layout, Process hay App có thể ảnh hưởng đến các thành phần đang tham chiếu. Cần phân tích dependency và kiểm tra lại các chức năng liên quan.

Nguyên tắc khi thiết kế và thay đổi

Chu trình quản trị thay đổi trên Cogover

  1. Với ứng dụng hiện có, đọc cấu hình thực tế trước khi sửa, giữ nguyên phần ngoài phạm vi và kiểm tra lại sau thay đổi.
  2. Với ứng dụng mới, hoàn thành phân tích nghiệp vụ và mô hình dữ liệu trước khi tạo Object hoặc cấu hình ứng dụng.
  3. Tạo Object theo thứ tự phụ thuộc; Object được lookup đến phải có trước.
  4. Kiểm tra dữ liệu và kết quả report trước khi đưa report lên dashboard.
  5. Kiểm thử phân quyền bằng ít nhất một tài khoản được phép và một tài khoản bị từ chối.
  6. Sau khi thay đổi, đọc lại cấu hình và chạy một kịch bản nghiệp vụ tiêu biểu.

Kết luận

Object Manager cung cấp dữ liệu và giao diện bản ghi. Business Logic sử dụng dữ liệu đó cho Process, quyền, menu, tài liệu, báo cáo và tích hợp. Application lắp ghép các thành phần của hai tầng dưới theo từng miền nghiệp vụ và workspace.

Khi thiết kế hoặc thay đổi cấu hình, cần làm từ mô hình dữ liệu, xác minh state hiện có và kiểm tra lại các thành phần liên quan ở cả ba tầng.

© 2026 Cogover LLC