Bỏ qua đến nội dung chính
FromNine
Danh mục

Phần mềm và đám mây

Tích hợp giữ cho dữ liệu luôn lưu chuyển, và cho thấy ngay khi nó dừng lại.

Chúng tôi kết nối CRM, ERP, hệ thống quản lý hồ sơ và nền tảng của khu vực công bằng hợp đồng API, sự kiện và định danh được làm đúng cách, để dữ liệu lưu chuyển ổn định, lỗi được nhìn thấy và các năng lực mới, kể cả AI, có thể kết nối an toàn.

Dành cho tổ chức kết nối hệ thống, đối tác và nền tảng của khu vực công ở nhiều quốc gia, như doanh nghiệp Việt Nam giao dịch với khách hàng và nhà cung cấp châu Âu.

Tích hợp và API: các lớp năng lựcBốn lớp xếp chồng theo chiều sâu. Từ trên xuống: các bên sử dụng như cổng thông tin, ứng dụng và tác tử AI, cổng API với định danh, trục sự kiện, và các hệ thống gốc ở dưới cùng.01Cổng thông tin, ứng dụng, tác tử02Cổng API và định danh03Trục sự kiện04Hệ thống gốc
  1. 01API thiết kế từ hợp đồng với OpenAPI và AsyncAPI, có quản lý phiên bản và tài liệu
  2. 02Sự kiện có thứ tự, xử lý lũy đẳng, hàng đợi thư lỗi (dead-letter queue) và khả năng chạy lại
  3. 03Luồng dữ liệu được giám sát từ đầu đến cuối, hàng đợi lỗi do các nhóm được chỉ định phụ trách

01 Vấn đề

Những vấn đề tích hợp mà chúng tôi thường được mời xử lý

  1. 01

    Kết nối điểm nối điểm không ai dám thay đổi

    Hàng chục kết nối trực tiếp giữa CRM, ERP và hệ thống viết riêng. Đổi một trường dữ liệu là phải kiểm thử mười giao diện.

  2. 02

    Bản ghi trùng lặp và lỗi không ai hay biết

    Một lần thử lại tạo ra đơn hàng thứ hai. Một thông điệp lỗi biến mất. Người dùng nghiệp vụ biết chuyện từ khách hàng.

  3. 03

    Mỗi kênh mới là một lần tích hợp mới

    Cổng thông tin, ứng dụng di động và giờ đây là trợ lý AI đều cần cùng dữ liệu, và mỗi kênh có một bản trích xuất riêng.

  4. 04

    Kết nối với hệ thống của cơ quan nhà nước là một dự án riêng

    Mỗi lần kết nối với một nền tảng chia sẻ dữ liệu quốc gia hay một hệ thống định danh điện tử lại mất nhiều tháng cho thủ tục an ninh và đăng ký kết nối.

02 Hạng mục triển khai

Những gì chúng tôi triển khai

  1. 01 Chiến lược và quản lý API

    Thiết kế ưu tiên API với hợp đồng OpenAPI và AsyncAPI, chính sách quản lý phiên bản, cổng API thực thi chính sách đó và cổng thông tin cho lập trình viên để các nhóm tìm và dùng lại những gì đã có.

    Công việc chúng tôi thực hiện

    • Bản đồ API và người phụ trách
    • Hướng dẫn thiết kế và quy trình rà soát
    • Chính sách cổng API về an ninh, hạn mức và phiên bản
    • Cổng thông tin cho lập trình viên và danh mục API

    Kết quả bàn giao

    • Hướng dẫn API được các nhóm áp dụng
    • Cấu hình cổng API dưới dạng mã
    • Danh mục API có tài liệu
  2. 02 Tích hợp hướng sự kiện

    Bộ trung chuyển thông điệp, ghi nhận thay đổi dữ liệu và mẫu outbox, cùng những chi tiết quyết định thành bại: thứ tự, bên nhận xử lý lũy đẳng (idempotent), hàng đợi thư lỗi và chạy lại.

    Công việc chúng tôi thực hiện

    • Mô hình sự kiện và quy ước đặt tên
    • Outbox và CDC trên hệ thống nguồn
    • Bảo đảm lũy đẳng và thứ tự cho bên nhận
    • Hàng đợi thư lỗi kèm công cụ chạy lại

    Kết quả bàn giao

    • Trục sự kiện vận hành thực tế
    • Kho lược đồ và quy tắc tương thích
    • Sổ tay chạy lại và khôi phục
  3. 03 Nền tảng tích hợp, chọn theo từng luồng

    SAP Integration Suite, MuleSoft và dịch vụ tích hợp gốc đám mây đều có chỗ đứng riêng. Chúng tôi cho biết khi nào một iPaaS tốt hơn mã viết riêng, và khi nào không.

    Công việc chúng tôi thực hiện

    • Đánh giá phần mềm trung gian hiện có
    • Lựa chọn nền tảng theo tổng chi phí sở hữu
    • Ánh xạ và bộ kết nối dùng lại được
    • Chuyển đổi khỏi phần mềm trung gian cũ

    Kết quả bàn giao

    • Hồ sơ quyết định về nền tảng tích hợp
    • Thư viện mẫu tích hợp
    • Kế hoạch chuyển đổi các giao diện hiện có
  4. 04 Định danh và tin cậy giữa các hệ thống

    OAuth 2.0 và OpenID Connect, mutual TLS, định danh giữa các dịch vụ, và tích hợp với hệ thống định danh điện tử cho người dân và doanh nghiệp tại châu Âu: itsme, DigiD và eHerkenning, BundID, FranceConnect, Cl@ve, SPID và CIE.

    Công việc chúng tôi thực hiện

    • Kiến trúc định danh cho người dùng và dịch vụ
    • Thiết kế token, phạm vi quyền và sự đồng ý
    • Hỗ trợ đăng ký kết nối và chứng nhận định danh điện tử
    • Chuẩn bị cho Ví danh tính số châu Âu

    Kết quả bàn giao

    • Thiết kế định danh và mô hình mối đe dọa
    • Tích hợp định danh điện tử vận hành thực tế
    • Định danh dịch vụ và luân chuyển thông tin bí mật được áp dụng
  5. 05 Liên thông với hệ thống khu vực công

    Kết nối với các nền tảng chia sẻ dữ liệu quốc gia ở châu Âu, như Federal Service Bus và MAGDA tại Bỉ, Digikoppeling và Common Ground tại Hà Lan, chuẩn XÖV và FIT-Connect tại Đức, PDND tại Ý và API Entreprise tại Pháp, cũng như với Hệ thống kỹ thuật theo nguyên tắc chỉ một lần của EU.

    Công việc chúng tôi thực hiện

    • Đăng ký kết nối với đơn vị vận hành nền tảng
    • Ánh xạ theo chuẩn dữ liệu quốc gia
    • Yêu cầu về an ninh và ghi nhật ký của từng nền tảng
    • Thiết kế trao đổi chứng từ theo nguyên tắc chỉ một lần

    Kết quả bàn giao

    • Kết nối được chứng nhận với nền tảng chia sẻ dữ liệu
    • Tài liệu ánh xạ
    • Quy trình vận hành phối hợp với đơn vị vận hành
  6. 06 Khả năng quan sát vận hành cho người dùng nghiệp vụ

    Giám sát luồng dữ liệu mà người dùng nghiệp vụ đọc hiểu được, đối chiếu giữa các hệ thống, và hàng đợi lỗi có người phụ trách xử lý đến cùng.

    Công việc chúng tôi thực hiện

    • Giám sát luồng dữ liệu ở cấp nghiệp vụ
    • Báo cáo đối chiếu giữa các hệ thống
    • Phân loại và định tuyến lỗi
    • Cảnh báo cho người phụ trách từng luồng

    Kết quả bàn giao

    • Bảng theo dõi tích hợp cho từng quy trình nghiệp vụ
    • Kiểm tra đối chiếu vận hành thực tế
    • Bản đồ người phụ trách cho mọi hàng đợi lỗi

03 Kiến trúc

Một kiến trúc tham chiếu minh họa

Hai luồng đi ra từ các hệ thống gốc. Yêu cầu đồng bộ đi qua API hệ thống và một cổng API kiểm tra định danh, phạm vi quyền và hạn mức. Thay đổi được phát đi dưới dạng sự kiện qua outbox hoặc ghi nhận thay đổi dữ liệu, và bên nhận xử lý chúng theo cách lũy đẳng.

Thông điệp lỗi đi vào hàng đợi thư lỗi có thể chạy lại, không nằm trong một tệp nhật ký. Một dải giám sát hiển thị mọi luồng bằng ngôn ngữ nghiệp vụ, để người phụ trách quy trình thấy ngay khi luồng dừng lại.

Các lớp trong sơ đồ

Hệ thống gốc
ERP, CRM và hệ thống quản lý hồ sơ giữ thẩm quyền đối với dữ liệu của mình.
API đồng bộ
API hệ thống có quản lý phiên bản sau một cổng API với OAuth 2.0, mTLS và hạn mức.
Sự kiện
Outbox, bộ trung chuyển, hàng đợi thư lỗi và ánh xạ trên nền tảng tích hợp.
Bên sử dụng
Cổng thông tin, ứng dụng, tác tử AI, đối tác và kết nối với cơ quan nhà nước, có định danh điện tử khi liên quan đến người dân.
Ví dụ minh họa
  1. Hệ thống gốc

    • ERP, CRM và hệ thống hồ sơ
  2. API đồng bộ

    • API hệ thống
    • Cổng API: OAuth 2.0, mTLS, hạn mức
  3. Sự kiện

    • Outbox và CDC
    • Bộ trung chuyển sự kiện
    • Thư lỗi và chạy lại
    • Ánh xạ trên nền tảng tích hợp
  4. Bên sử dụng

    • Cổng thông tin, ứng dụng và tác tử
    • Kết nối đối tác và cơ quan nhà nước
    • Định danh: OIDC, mTLS, định danh điện tử
  5. Vận hành

    • Giám sát luồng, đối chiếu, hàng đợi lỗi có người phụ trách
API và trục sự kiện song song

Kiến trúc minh họa, không phải hệ thống của khách hàng.

Đọc sơ đồ dưới dạng văn bản

Luồng chính đi từ các hệ thống gốc qua API hệ thống có quản lý phiên bản và cổng API đến cổng thông tin, ứng dụng và tác tử AI.

Song song, các hệ thống gốc phát thay đổi qua outbox và ghi nhận thay đổi dữ liệu đến bộ trung chuyển sự kiện, nơi chuyển chúng đến các kết nối với đối tác và cơ quan nhà nước và đến nền tảng tích hợp để ánh xạ. Thông điệp lỗi đi vào hàng đợi thư lỗi có thể chạy lại. Dịch vụ định danh với OAuth, mTLS và định danh điện tử bảo vệ các kết nối với đối tác.

Một dải giám sát bên dưới hiển thị trạng thái luồng, kết quả đối chiếu và các hàng đợi lỗi có người phụ trách.

04 Lưu ý và giới hạn

Lưu ý kỹ thuật và giới hạn

  • Xử lý đúng một lần là thiết kế, không phải một tùy chọn cấu hình

    Cách chúng tôi xử lý

    Chúng tôi giả định thông điệp có thể đến hai lần hoặc sai thứ tự, và thiết kế bên nhận xử lý lũy đẳng, với khóa và quy tắc thứ tự thống nhất cho từng loại sự kiện.

    Giới hạn và điều kiện phụ thuộc

    Một số hệ thống cũ không nhận được khóa lũy đẳng hoặc không báo được những gì đã xử lý. Với các hệ thống đó, chúng tôi bổ sung đối chiếu thay vì giả vờ là không có vấn đề.

  • iPaaS không phải lúc nào cũng là câu trả lời

    Cách chúng tôi xử lý

    Nền tảng thắng thế với nhiều bộ kết nối và ánh xạ chuẩn. Dịch vụ viết riêng thắng thế với logic phức tạp, khối lượng lớn hoặc yêu cầu độ trễ nghiêm ngặt. Chúng tôi ghi lại lựa chọn cho từng tích hợp.

    Giới hạn và điều kiện phụ thuộc

    Mô hình cấp phép thay đổi. Một nền tảng rẻ hôm nay có thể trở thành khoản lớn nhất trong ngân sách tích hợp, nên chúng tôi mô hình hóa chi phí cho nhiều năm.

  • Nền tảng của khu vực công có nhịp độ riêng

    Cách chúng tôi xử lý

    Chúng tôi chuẩn bị sớm hồ sơ đăng ký kết nối, bằng chứng an ninh và kế hoạch kiểm thử, và làm việc với đơn vị vận hành nền tảng từ tuần đầu tiên.

    Giới hạn và điều kiện phụ thuộc

    Thời gian chứng nhận và đăng ký kết nối do đơn vị vận hành quyết định, không phải chúng tôi. Chúng tôi lập kế hoạch xoay quanh các mốc đó và cho biết chúng nằm ở đâu trên đường găng.

  • Bên sử dụng là AI cần API hẹp

    Cách chúng tôi xử lý

    Tác tử AI và trợ lý AI được cấp API riêng, có phạm vi quyền, hạn mức và nhật ký kiểm toán, không có quyền truy cập rộng như các dịch vụ nội bộ.

    Giới hạn và điều kiện phụ thuộc

    Mở một API cho tác tử AI làm tăng rủi ro. Chúng tôi rà soát từng API cùng bộ phận an toàn thông tin trước khi đưa vào vận hành.

05 Cách chúng tôi làm việc

Cách chúng tôi làm việc

Chúng tôi gỡ rối trước khi xây dựng, và để lại cho mỗi luồng một người phụ trách.

  1. 01

    Lập bản đồ các luồng

    Mọi giao diện, khối lượng, lịch sử lỗi và người phụ trách nghiệp vụ của nó.

    Kết quảBức tranh tích hợp và xếp hạng rủi ro

  2. 02

    Đặt quy tắc

    Hướng dẫn API, quy ước sự kiện, mô hình định danh và lựa chọn nền tảng.

    Kết quảHướng dẫn tích hợp và hồ sơ quyết định

  3. 03

    Chuyển từng luồng một

    Các luồng rủi ro cao nhất trước, với đối chiếu chạy song song với giao diện cũ cho đến khi số liệu khớp.

    Kết quảCác luồng đã chuyển kèm bằng chứng đối chiếu

  4. 04

    Vận hành minh bạch

    Bảng theo dõi cho từng quy trình nghiệp vụ và hàng đợi lỗi có người phụ trách được chỉ định.

    Kết quảBản đồ người phụ trách luồng và bảng theo dõi

06 Con người kiểm soát

Nơi con người giữ quyền kiểm soát

Tích hợp chạy không cần người trông. Trách nhiệm khi có sự cố thì không thể như vậy.

  • Mỗi hàng đợi lỗi có người phụ trách

    Thông điệp lỗi đến một nhóm chịu trách nhiệm, kèm bối cảnh và nút chạy lại, không nằm trong một nhật ký dùng chung.

  • Thay đổi hợp đồng được rà soát

    Thay đổi phá vỡ tương thích của API hoặc sự kiện được rà soát cùng các bên sử dụng trước khi công bố.

  • Chạy lại là hành động có chủ đích

    Chạy lại thông điệp vào một hệ thống gốc là hành động cần thẩm quyền, được ghi lại ai thực hiện và vì sao.

07 Công nghệ

Các công nghệ chúng tôi sử dụng

Nền tảng tích hợp
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Dịch vụ tích hợp của AWS và Google Cloud
Sự kiện và dữ liệu luồng
  • Apache Kafka
  • RabbitMQ
  • Bộ trung chuyển sự kiện trên đám mây
  • Debezium cho ghi nhận thay đổi dữ liệu
API
  • OpenAPI và AsyncAPI
  • Cổng API và cổng thông tin cho lập trình viên
  • GraphQL ở nơi phù hợp
  • Kiểm thử hợp đồng
Định danh
  • OAuth 2.0 và OpenID Connect
  • Mutual TLS
  • Keycloak và dịch vụ định danh trên đám mây
  • Hệ thống định danh điện tử quốc gia

Việc liệt kê một công nghệ mô tả kinh nghiệm kỹ thuật của chúng tôi. Điều đó không có nghĩa là chúng tôi có quan hệ đối tác với nhà cung cấp hoặc được nhà cung cấp chứng nhận.

08 Ví dụ

Một ví dụ minh họa

Ví dụ minh họa

Một ERP gửi hóa đơn điện tử trong nước và hóa đơn Peppol sang châu Âu

01Bối cảnh
Ví dụ: một nhà sản xuất hàng may mặc xuất khẩu sang ba nước châu Âu. Hóa đơn trong nước đi qua một nhà cung cấp dịch vụ hóa đơn điện tử, hóa đơn cho khách hàng châu Âu được xuất từ ERP rồi gửi email dạng PDF, và bộ phận kế toán đối chiếu thủ công khi khách hàng báo chưa nhận được.
02Hệ thống chúng tôi sẽ xây dựng
Một lớp tích hợp nối ERP với nhà cung cấp dịch vụ hóa đơn điện tử trong nước và với một điểm truy cập Peppol, qua các hợp đồng API ổn định, với trạng thái từng hóa đơn hiển thị trên một bảng theo dõi và hàng đợi lỗi có người phụ trách.
03Nơi con người quyết định
Kế toán trưởng phê duyệt quy tắc ánh xạ và mọi lần gửi lại hóa đơn; thay đổi thông tin thanh toán của khách hàng luôn cần người phê duyệt.
04Những gì chúng tôi sẽ đo lường
Tỷ lệ hóa đơn được chấp nhận ngay lần gửi đầu, thời gian xử lý một hóa đơn lỗi và số lần đối chiếu thủ công mỗi tháng.

09 Theo ngành

Theo ngành của quý vị

  • Trao đổi dữ liệu theo nguyên tắc chỉ một lần với nguồn dữ liệu gốc, định danh điện tử cho người dân và doanh nghiệp, và nhật ký mà các nền tảng quốc gia yêu cầu. Xem thêm trang Khu vực công.

  • ERP, MES và cổng nhà cung cấp kết nối qua sự kiện, để lập kế hoạch, sản xuất và dịch vụ cùng nhìn một bức tranh.

  • Hệ thống lõi, CRM và API đối tác kết nối với định danh chặt chẽ, nhật ký kiểm toán và đối chiếu mà bộ phận tài chính tin tưởng.

Việt Nam

Một ERP, hai quy tắc hóa đơn điện tử

Một doanh nghiệp xuất khẩu Việt Nam lập hóa đơn cho hai thế giới. Trong nước, hóa đơn điện tử thực hiện theo Nghị định số 254/2026/NĐ-CP, có hiệu lực từ ngày 1/7/2026 và thay thế Nghị định số 123/2020/NĐ-CP và Nghị định số 70/2025/NĐ-CP. Khách hàng ở một số nước châu Âu yêu cầu hóa đơn điện tử theo chuẩn Peppol, gửi qua một điểm truy cập (access point). Ở khu vực công châu Âu, Đạo luật Liên thông châu Âu yêu cầu cơ quan nhà nước đánh giá khả năng liên thông xuyên biên giới, và eIDAS 2 đưa vào Ví danh tính số châu Âu mà mọi quốc gia thành viên phải cung cấp.

Chúng tôi thiết kế lớp tích hợp trong đó từng kênh hóa đơn, nền tảng chia sẻ dữ liệu và hệ thống định danh là một bộ chuyển đổi đặt sau các hợp đồng nội bộ ổn định. Thêm một quốc gia hay một kênh khi đó chỉ là thêm một bộ chuyển đổi và thủ tục kết nối của nó, không phải làm lại các hệ thống phía sau.

Câu hỏi về tích hợp và API

Nên dùng nền tảng tích hợp hay xây dựng tích hợp riêng?

Cả hai, cho những luồng khác nhau. Bộ kết nối chuẩn, ánh xạ và kết nối đối tác phù hợp với nền tảng. Luồng khối lượng lớn, nhạy cảm về độ trễ hoặc nhiều logic thường phù hợp với dịch vụ viết riêng. Chúng tôi quyết định theo từng luồng và ghi lại lý do.

FromNine có tích hợp Salesforce, SAP và Odoo không?

Có, thường xuyên, giữa các nền tảng này với nhau và với hệ thống viết riêng. FromNine là đối tác của cả ba nền tảng (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), nên các nhóm tích hợp của chúng tôi làm việc cùng chuyên gia nền tảng. Tìm hiểu thêm về SAP.

Tổ chức có cần tích hợp hướng sự kiện không?

Khi nhiều hệ thống cần phản ứng với cùng một thay đổi, hoặc khi cần tách rời chu kỳ phát hành, sự kiện sẽ hữu ích. Với yêu cầu và phản hồi đơn giản giữa hai hệ thống, một API thường là đủ. Phần lớn hệ thống dùng cả hai.

FromNine có tích hợp được hệ thống định danh điện tử không?

Có, với các hệ thống định danh điện tử cho người dân và doanh nghiệp tại châu Âu, và chúng tôi thiết kế cho Ví danh tính số châu Âu mà các quốc gia thành viên đang triển khai theo eIDAS 2. Tại Việt Nam, định danh điện tử dựa trên ứng dụng VNeID theo Nghị định số 69/2024/NĐ-CP, có cả tài khoản định danh điện tử cho tổ chức. Điều kiện kết nối khác nhau theo từng hệ thống, nên chúng tôi làm rõ từ sớm.

Chúng tôi đang dùng phần mềm trung gian cũ. Có phải thay thế không?

Không phải thay một lần. Chúng tôi lập bản đồ những gì đang chạy trên đó, chuyển các luồng rủi ro nhất hoặc tốn kém nhất trước, và duy trì đối chiếu cho đến khi từng luồng đã chuyển được chứng minh là chạy đúng.

Hãy mang đến giao diện hay lỗi nhất

Chúng tôi sẽ cho thấy cách làm cho nó quan sát được, lũy đẳng và có người phụ trách, và cần những gì để làm điều tương tự cho phần còn lại.