Khi đánh giá một nền tảng sạc, sớm muộn doanh nghiệp cũng cần đến kỹ sư phụ trách kết nối nền tảng với các hệ thống đang sử dụng: ERP cho kế toán, CRM cho dữ liệu khách hàng và kho dữ liệu cho báo cáo. Kỹ sư thường không có mặt trong buổi demo đầu tiên, trong khi những câu hỏi của họ hiếm khi được giải đáp đầy đủ ở đó. Bài viết này làm rõ tầng tích hợp của một CSMS gồm những gì, mỗi cơ chế phù hợp với nhiệm vụ nào và doanh nghiệp cần xác nhận điều gì trước khi ký hợp đồng.
Ba cơ chế, ba nhiệm vụ khác nhau
“Ưu tiên API” thường được trình bày như một năng lực duy nhất. Trên thực tế, một tầng tích hợp gồm ba phần riêng biệt. Phần lớn vấn đề phát sinh khi doanh nghiệp dùng sai cơ chế cho nhiệm vụ cần xử lý.
| Cơ chế | Chiều gọi | Dùng cho | Không phù hợp với |
|---|---|---|---|
| REST API | Hệ thống của bạn gọi tới nền tảng | Đọc trạng thái hiện tại, tạo và cập nhật dữ liệu, phát lệnh - khai báo một trụ sạc, gán biểu giá, tra cứu một phiên sạc, bắt đầu hoặc dừng từ xa | Việc biết một sự kiện vừa xảy ra. Gọi một endpoint mỗi 30 giây để phát hiện lỗi là một lỗi thiết kế, không phải một cách tích hợp. |
| Webhook | Nền tảng gọi tới hệ thống của bạn | Phản ứng với các sự kiện nghiệp vụ gần như tức thời - phiên sạc kết thúc, thanh toán đã thu, trụ sạc mất kết nối, sự cố được mở | Dữ liệu lịch sử số lượng lớn. Đẩy lại sáu tháng phiên sạc qua một endpoint webhook là cách làm chậm và dễ đổ vỡ. |
| Luồng sự kiện | Hệ thống của bạn tiêu thụ một luồng liên tục | Dữ liệu vận hành khối lượng lớn và phân tích - nạp vào kho dữ liệu, dựng dashboard vận hành, duy trì một bản sao dữ liệu đồng bộ | Các luồng nghiệp vụ cần câu trả lời đồng bộ ngay lập tức, chẳng hạn xác thực để bắt đầu một phiên sạc. |
Một tầng tích hợp lành mạnh dùng cả ba: webhook để biết điều gì vừa xảy ra, REST API để lấy dữ liệu chính thức của sự kiện đó, và luồng sự kiện hoặc tệp xuất định kỳ để nạp dữ liệu cho hệ thống phân tích và tài chính mà không dồn tải lên API giao dịch.
Những tích hợp thường gặp trong thực tế
Trong các hoạt động vận hành sạc, bốn tích hợp sau xuất hiện ở gần như mọi dự án, và chúng có yêu cầu về độ tin cậy khác nhau:
- Tài chính và ERP. Dữ liệu phiên sạc và hóa đơn được chuyển vào hệ thống kế toán, thường dưới dạng tệp xuất định kỳ hoặc luồng đối soát thay vì một lệnh gọi cho từng sự kiện. Tính chính xác và đầy đủ quan trọng hơn độ trễ: một phiên sạc đến muộn mười phút có thể chấp nhận được, nhưng bản ghi trùng sẽ buộc bộ phận tài chính điều chỉnh số liệu.
- CRM và chăm sóc khách hàng. Nhân viên hỗ trợ cần xem được phiên sạc, thanh toán và khiếu nại của một khách hàng mà không phải đăng nhập vào hệ thống thứ hai. Phần này thường chủ yếu là đọc qua REST, kèm vài webhook cho các thay đổi trạng thái.
- Kho dữ liệu và BI. Bộ phận phân tích muốn có dữ liệu ở mức từng phiên sạc trong công cụ báo cáo họ đang dùng. Một luồng sự kiện hoặc tệp xuất khối lượng lớn luôn tốt hơn việc gọi API theo vòng lặp, và tránh được tình huống thường gặp là tải phân tích làm chậm chính nền tảng vận hành.
- Công cụ vận hành nội bộ. Cảnh báo đẩy vào kênh trao đổi mà đội vận hành đang theo dõi, tạo phiếu trong hệ thống có sẵn, dashboard nội bộ tự xây. Phần lớn là webhook, kèm REST API để bổ sung dữ liệu chi tiết.
Bảy câu hỏi quyết định độ bền vững của tích hợp
1. Webhook có được gửi lại không, và trong bao lâu?
Hệ thống của bạn sẽ có lúc không phản hồi - một lần triển khai phiên bản mới, một chứng chỉ hết hạn, một sự cố hạ tầng. Điều gì xảy ra với những sự kiện phát sinh trong khoảng thời gian đó là câu hỏi quan trọng nhất trong danh sách này. Một nền tảng gửi lại nhiều lần với khoảng cách giãn dần trong nhiều giờ, và cho phép phát lại một khoảng thời gian sau đó, là nền tảng bạn có thể khôi phục được. Một nền tảng gửi một lần rồi bỏ sự kiện sẽ để lại một khoảng trống âm thầm và vĩnh viễn trong dữ liệu, mà không ai phát hiện ra cho đến khi một kỳ đối soát cuối tháng không khớp.
2. Sự kiện được gửi tối thiểu một lần, và có xử lý trùng lặp được không?
Bất kỳ hệ thống nào có gửi lại rồi cũng sẽ gửi cùng một sự kiện hai lần. Điều đó là bình thường và cần được lường trước - vấn đề là mỗi sự kiện phải mang một mã định danh duy nhất và ổn định, để phía bạn nhận ra bản trùng và bỏ qua. Hãy xây mọi thành phần tiêu thụ webhook theo nguyên tắc xử lý trùng lặp an toàn ngay từ đầu; phương án còn lại là thu tiền khách hàng hai lần hoặc ghi nhận doanh thu hai lần ngay lần gửi lại đầu tiên.
3. Sự kiện có thể đến sai thứ tự không?
Trên một đường truyền không ổn định, sự kiện “phiên sạc kết thúc” hoàn toàn có thể đến trước sự kiện “phiên sạc bắt đầu”. Những hệ thống giả định thứ tự sẽ sai ở đúng tình huống này. Cách phòng vệ thực tế là xem mỗi sự kiện như một con trỏ chứ không phải một khối dữ liệu: khi một sự kiện đến, hãy gọi REST API để lấy trạng thái chính thức hiện tại của đối tượng đó, thay vì tự dựng lại trạng thái từ chuỗi sự kiện mà bạn tình cờ nhận được.
4. Lệnh gọi webhook được xác thực thế nào, ở cả hai chiều?
Bạn xác thực với nền tảng bằng một API key hoặc thông tin đăng nhập OAuth. Nền tảng xác thực với bạn bằng một chữ ký trên nội dung webhook - thường là một HMAC tính trên phần thân thông điệp với một khóa chia sẻ, mà endpoint của bạn phải kiểm tra trước khi xử lý. Không có bước đó, địa chỉ webhook của bạn là một endpoint không xác thực trên Internet công cộng mà bất kỳ ai biết được đều có thể gửi vào những bản ghi phiên sạc giả. Hãy xác nhận cơ chế kiểm tra chữ ký có tồn tại, và xác nhận bạn đổi được khóa chia sẻ mà không phải ngừng hoạt động.
5. Giới hạn tần suất là bao nhiêu, và điều gì xảy ra khi chạm ngưỡng?
Giới hạn tần suất là dấu hiệu của một nền tảng biết tự bảo vệ, không phải một hạn chế cần thương lượng bỏ đi. Điều bạn cần biết là con số cụ thể, giới hạn tính theo từng API key hay theo cả tổ chức, và khi vượt ngưỡng thì nhận về một phản hồi rõ ràng kèm chỉ dẫn thử lại hay chỉ đơn giản là các yêu cầu bắt đầu thất bại. API key giới hạn phạm vi truy cập - một khóa đọc được dữ liệu phiên sạc nhưng không phát được lệnh điều khiển - quan trọng vì cùng lý do: một tích hợp chỉ cần đọc thì không nên giữ thông tin đăng nhập có thể dừng một phiên sạc đang chạy.
6. API được đánh phiên bản thế nào, và chính sách ngừng hỗ trợ ra sao?
Bạn sẽ phát triển trên tầng tích hợp này trong nhiều năm. Hãy hỏi những thay đổi gây mất tương thích được đưa ra như thế nào, các phiên bản cũ còn được hỗ trợ bao lâu, và việc ngừng hỗ trợ được thông báo ra sao. Một nhà cung cấp không trả lời được câu này là nhà cung cấp mà bản phát hành kế tiếp của họ sẽ trở thành việc phát sinh ngoài kế hoạch của bạn.
7. Có môi trường thử nghiệm, và tài liệu có thực chất?
Một môi trường ngoài môi trường thật, nơi đội kỹ thuật của bạn tạo được trụ sạc, mô phỏng được phiên sạc và nhận được webhook thử, là khác biệt giữa việc tích hợp song song với triển khai và việc tích hợp sau khi triển khai xong. Hãy yêu cầu xem tài liệu API trong giai đoạn đánh giá, không phải sau khi ký - chất lượng tài liệu là một chỉ dấu đáng tin về mức độ nghiêm túc mà nhà cung cấp dành cho tầng tích hợp.
Vì sao mô hình dữ liệu nền tảng quan trọng hơn danh sách endpoint
Tầng tích hợp chỉ có thể nhất quán khi hệ thống nền tảng cũng nhất quán. Khi một nền tảng được lắp ghép từ một CSMS, một công cụ hóa đơn riêng và một hệ thanh toán riêng, tầng API thừa hưởng luôn các đường nối đó: mã phiên sạc mà API vận hành trả về không phải mã mà API hóa đơn chờ đợi, thời điểm được ghi nhận ở các hệ thống khác nhau với đồng hồ khác nhau, và tầng tích hợp của bạn âm thầm trở thành nơi mô hình dữ liệu của ba nhà cung cấp được hoà giải với nhau. Công việc đó không hiện ra trong một buổi demo và tồn tại vĩnh viễn trong vận hành. Một bản ghi phiên sạc duy nhất từ lúc xác thực đến lúc quyết toán là một đặc tính kỹ thuật trước khi là một thông điệp tiếp thị - cũng chính là đặc tính làm cho việc đối soát và quyết toán doanh thu trở nên khả thi.
Đừng quên lịch sử kiểm toán
Mọi việc một tích hợp thực hiện qua API đều là một thao tác quản trị do máy thực hiện, và nó cần mức độ truy vết ngang với thao tác do người thực hiện. Khi một tiến trình tự động gán biểu giá hoặc dừng một phiên sạc, bản ghi kiểm toán phải cho thấy thông tin đăng nhập nào đã làm việc đó, vào lúc nào và kết quả ra sao. Điều này quan trọng nhất trong đúng sự cố mà bạn chưa từng gặp - một tích hợp bắt đầu cập nhật hàng loạt biểu giá vì một bản triển khai lỗi, khi câu hỏi cần trả lời là cái gì đã thay đổi, do ai, và theo thứ tự nào. Phần này đi kèm trực tiếp với cách vai trò và phân quyền được thiết lập cho người dùng.
CarChargeOS cung cấp REST API, webhook và luồng sự kiện như một phần cốt lõi của nền tảng, kèm API key giới hạn phạm vi truy cập và giới hạn tần suất, cùng các tích hợp cho thanh toán, ERP và tài chính, CRM, định danh và BI - xem phần tích hợp và khả năng liên thông tại trang nền tảng, hoặc mang hệ thống của bạn đến một buổi trao đổi kỹ thuật.
Câu hỏi thường gặp
Nên dùng webhook hay gọi API theo định kỳ?
Dùng webhook cho mọi thứ mang tính sự kiện, dùng API để đọc trạng thái chính thức. Gọi API theo vòng lặp là phương án dự phòng, không phải một thiết kế - nó hoặc làm phí phần lớn số lệnh gọi, hoặc làm tăng độ trễ, và ở quy mô lớn thì thường cả hai. Trường hợp hợp lý duy nhất là một lượt quét định kỳ hằng ngày để bắt những sự kiện mà webhook có thể đã không gửi tới được, tức là một lớp an toàn cho việc đối soát chứ không phải cơ chế chính.
Có cần hiểu OCPP để tích hợp với một CSMS không?
Không. OCPP là giao thức giữa trụ sạc và nền tảng; các hệ thống nghiệp vụ của bạn tích hợp với API của chính nền tảng, nơi dữ liệu được trình bày dưới dạng phiên sạc, biểu giá, khách hàng và thanh toán thay vì các thông điệp của trụ sạc. Hiểu OCPP có ích khi xử lý sự cố phần cứng, nhưng không phải điều kiện cần để xây một tích hợp ERP hay CRM.
Có thể tự xây ứng dụng cho tài xế hoặc màn hình quản trị riêng trên API không?
Về mặt kỹ thuật, đó chính là điều một nền tảng ưu tiên API cho phép, nhưng nên cân nhắc kỹ lý do. Ứng dụng thương hiệu riêng và màn hình quản trị đã có sẵn và được bảo trì theo các thay đổi của hệ điều hành và kho ứng dụng; tự xây nghĩa là nhận lấy phần việc đó vĩnh viễn. Một giao diện riêng chỉ hợp lý khi bạn cần một trải nghiệm thực sự khác biệt hoặc cần nhúng luồng sạc vào một ứng dụng mà khách hàng của bạn đã dùng - không phải chỉ để thay thế một giao diện đã có thể cấu hình. Sự đánh đổi này cũng được phân tích trong bài tự xây dựng, mua sẵn hay nền tảng thương hiệu riêng.