Trong mô hình này, Website và 1C làm việc hoàn toàn độc lập với nhau, mỗi chương trình đều có riêng một cơ sở dữ liệu, nhưng trong một khoảng thời gian đã định thì các thông tin cần thiết sẽ được đồng bộ hóa với nhau.
Phương pháp này có tính đến yếu tố tâm lý đã nêu ở trên, Website không có bất kỳ truy cập nào tới 1C! Như vậy, để tất cả đều có thể hoạt động đúng cách thì 1C cần phải định kỳ liên hệ với Website để gửi đi hay nhận lại dữ liệu.
Ưu điểm của phương pháp này so với phương pháp đầu tiên như sau:
- Website làm việc độc lập, cùng với dữ liệu của mình và không phụ thuộc vào khả năng truy cập tới 1C;
- 1C không tiếp nhận và xử lý các truy vấn từ Website, và như vậy không bị chịu thêm tải;
- Trong trường hợp vi phạm bảo mật của Website, khả năng bảo mật của 1C không hề bị vi phạm.
Trong kiến trúc này, có một nhược điểm so với phương pháp đầu tiên: có độ chễ về việc cập nhật dữ liệu. Nếu như, ví dụ, ngoài bán hàng trên mạng, chúng ta còn kinh doanh bán lẻ tại cửa hàng thì trên Website có thể vẫn hiển thị là còn hàng hóa, nhưng trong kho thì thực tế không còn. Tỷ lệ xác suất vênh dữ liệu giữa 2 hệ thống sẽ tỷ lệ nghịch với khoảng thời gian cập nhật. Đối với khoảng thời gian cập nhật không lớn (một vài phút) thì tỷ lệ vênh này có thể sẽ không lớn.
Nhưng, thứ nhất, có một tiền đề mà sau đó đã được chứng minh trong thực tế: đối với gian hàng trực tuyến đại trà, nhược điểm này không phải là TỐI QUAN TRỌNG. Xác suất phát sinh tình huống này không lớn và càng giảm đi khi giảm khoảng thời gian trao đổi, ngoài ra, phần lớn các gian hàng trực tuyến đều bán hàng mà không theo số lượng hàng tồn thực tế và thường ẩn đi số lượng hàng tồn thực tế đối với khách ghé thăm. Vâng, và nếu như tình huống này có xảy ra thì trong phần lớn các trường hợp đều có thể tìm được hàng hóa một cách nhanh chóng.
Thế còn điều thứ hai? Còn điều thứ hai là có thể sử dụng một số giải pháp công nghệ để sao cho có thể làm giảm khoảng thời gian cập nhật mà không để lại hậu quả.
Xin nhắc lại một lần nữa, chúng ta cần giải quyết bài toán tích hợp mà dành cho giải pháp đóng gói trong phần lớn các trường hợp. Tất nhiên, cũng có những cửa hàng quan tâm tới sự khác biệt với các yêu cầu đặc thù. Cũng giống như mua xe con, nhiều người không chỉ dùng các xe đóng hộp mà còn muốn “độ” thêm một vài thứ?! Tất nhiên, nếu khách hàng cần "độ" thì chúng tôi luôn sẵn sàng đáp ứng…
Thế còn về Web-service, Bạn có thể đặt ra câu hỏi như vậy? Bởi vì nếu như không phải là từ phía 1C thì bây giờ cần phải đăng tải Web-service trên phía Website? Nếu nói về Web-service thì thế này: chúng tôi đã bỏ qua nó. Và thay vào đó, chúng tôi quyết định thực thi cơ chế trao đổi theo một chuẩn giao thức thường dùng từ trước đến nay là HTTP kèm theo trao đổi qua tệp với chuẩn CommerceML.
Việc trao đổi theo HTTP có nghĩa là 1C truy cập đến một Script trên Website bằng phương thức POST, chuyển lên đó các tệp dữ liệu. Điều này cũng tốt, bởi vì ở đây không cần phải tùy chỉnh thêm gì cả. Cổng 80 đã được mở trong phần lớn các Firewall, bởi vì thông qua cổng này có kết nối với Internet cho cả văn phòng, và 1C cũng thường kết nối với Internet đúng như vậy. Script trên Website đã có sẵn trong bộ cài đặt của CMS, và Script này cũng chẳng cần phải đăng tải bổ sung tại bất kỳ nơi nào.
Còn chuẩn CommerceML cũng khá tốt bởi vì đây là chuẩn mở trên cơ sở XML mà được dùng chuyên dụng để trao đổi các thông tin thương mại: bảng mã hiệu danh mục, nhóm hàng cùng với thuộc tính hàng hóa, hàng hóa, đơn hàng. Việc chuyển dữ liệu có thể được thực hiện giữa các hệ thống, trong đó bao gồm giữa Website và Back-office. Hiện nay, chuẩn này đã bắt đầu được áp dụng vào thực tế và phát triển. Hiện tại đã có phiên bản 2.05, trong đó có rất nhiều điểm mới. Nhưng, tất nhiên, có một điều làm chúng ta vui mừng, vì chuẩn này đã được hỗ trợ mặc định trong các giải pháp của 1C.
Ví dụ về các tệp CommerceML: tệp với thông tin hàng hóa, tệp với bảng giá (đề xuất thương mại), tệp với thông tin đơn hàng từ Website và đến Website.
Kết quả là chúng ta có được kiến trúc tích hợp như sau:
Trong thành phần của 1C:DOANH NGHIỆP có bao gồm một mô-đun chuyên dụng để trao đổi dữ liệu với Website mà trong đó có thể thiết lập các tham số trao đổi. Từ mạng cục bộ của doanh nghiệp có tạo ra các truy vấn đến Website (được đặt trên một Hosting nào đó) theo giao thức HTTP. Mũi tên đến Website là hiển thị hướng truy vấn, hơn nữa, phía chủ động tạo truy vấn bao giờ cũng là 1C.
Giao thức trao đổi 1C với Website
Giao thức trao đổi là chuẩn mở hoàn toàn, có thể được bổ sung và thay đổi. Thông tin về giao thức dược đăng tải trong các tài liệu của Bitrix và trên trang Web của 1C.
Như vậy, tất cả những gì đã nói ở trên bằng lời nói có thể hình dung như sau:
Chương trình 1C gửi truy vấn HTTP cùng với đăng nhập HTTP dưới dạng:
http://<Site>/bitrix/admin/1c_exchange.php?type=catalog&mode=checkauth
Website trả lời bằng 3 dòng (với dấu cach “\n”):
1. Từ "success";
2. Tên Cookie;
3. Giá trị Cookie.
Ghi chú:
Tất cả các truy vấn tiếp theo đến Website đều được dẫn dắt từ phía 1C bằng tên và giá trị Cookie mà nhận lại được bằng lệnh “checkauth”.
Bước tiếp theo, 1C hỏi Website một vài tham số để tiến hành trao đổi tiếp theo:
http://<Site>/bitrix/admin/1c_exchange.php?type=<chế_độ>&mode=init
(chế_độ: catalog hoặc sale, để kết xuất hàng hóa và kết nhập đơn hàng tương ứng)
Website trả lại 2 dòng nhỏ:
1. zip=yes/no, thông báo về việc hỗ trợ trao đổi theo định dạng ZIP.
2. file_limit=<number>, trong đó <number> - kích cỡ lớn nhất được phép của tệp (tính bằng byte) để chuyển 1 truy vấn. Nếu kích thước của tệp lớn hơn thì nó sẽ bị cắt thành nhiều phần.
Khi đã thiết lập kết nối và đã xác định các tham số thì sẽ bắt đầu trao đổi tệp CommerceML. Phụ thuộc vào chế độ trao đổi 1C:
a. Chuyển cho Website các thông tin về danh mục hàng hóa
http://<Site>/bitrix/admin/1c_exchange.php?type=catalog&mode=file&filename=<tên_tệp>
Chương trình 1C kết nhập tệp trao đổi theo định dạng CommerceML 2 lên Server bằng cách gửi nội dung tệp hoặc một phần của tệp dưới dạng POST. Trong trường hợp ghi lại tệp thành công, Website trả lại "success".
b. Truy vấn đơn hàng từ Website
http://<Site>/bitrix/admin/1c_exchange.php?type=sale&mode=query
Website đưa ra các đơn hàng theo định dạng CommerceML 2. Trong trường hợp nhận được thành công và ghi đơn hàng vào 1C, sẽ kết thúc truy vấn dưới dạng:
http://<Site>/bitrix/admin/1c_exchange.php?type=sale&mode=success
c. Chuyển lên Website các dữ liệu về kết quả xử lý đơn hàng nhận được trước đây
http://<Site>/bitrix/admin/1c_exchange.php?type=sale&mode=file&filename=<tên_tệp>
Kết nhập tệp trao đổi lên Server bằng các gửi nội dung tệp dưới dạng POST. Trong trường hợp ghi tệp thành công, Bitrix đưa ra phản hồi “success”. Thông tin bổ sung trong các dòng tiếp theo có thể là ghi chú cho việc kết nhập.
Nếu như trong quá trình thực hiện một truy vấn nào đó mà có xảy ra lỗi thì hệ thống Bitrix sẽ trả lời dưới dạng: trong dòng đầu tiên là từ “failure”, còn trong các dòng tiếp theo là mô tả lỗi mà đã xảy ra trong quá trình xử lý truy vấn. Nếu như đã xảy ra lỗi không thể xử lý được ở mức độ hạt nhân của sản phẩm hay truy vấn SQL thì trong trường hợp này sẽ trả lại mã HTML của Website.
Như vậy, những gì mà chúng ta vừa xem xét là một thủ tục rất đơn giản nhưng đảm bảo được tính tin cậy. Toàn bộ được xây dựng trên 3 trụ cột:
- Trao đổi dữ liệu bằng giao thức HTTP;
- Chủ trì trao đổi bao giờ cũng là 1C;
- Định dạng và giao thức trao đổi dữ liệu là dạng mở.
Nhân tiện cũng cần nói thêm rằng, sau một khoảng thời gian, giao thức trao đổi CommerceML đã nhận được nhiều ủng hộ từ phía những công ty phát triển CMS khác, và hiện nay, đây là chuẩn được thừa nhận rộng rãi để tương tác giữa 1C và Website. Điều này khá quan trọng, bởi vì ngay từ đầu chúng tôi đã xác định rằng: sẽ không là người độc quyền, không tạo ra chuẩn đóng mà sẽ cung cấp khả năng cho mọi người để phát triển tiếp theo, để hoàn thiện và tùy ứng trong từng dự án cụ thể. Và như vậy, theo cách nhìn của chúng tôi, đã đạt được mục tiêu lựa chọn kiến trúc tối ưu.
Phần một của bài viết này không quá dài, nhưng tạm thời là như vậy.
Trong phần hai, chúng tôi sẽ nói về:
- Cách mà chúng tôi đã tối ưu việc chuyển dữ liệu giữa 1C và Website;
- Cách chuyển dữ liệu lớn và vượt qua được các hạn chế thường gặp của Hoster;
- Giao diện tùy chỉnh tích hợp theo từng bài toán cụ thể trong 1C cũng như trên Website;
- Cách tạo thêm các khả năng bổ sung cho trao đổi và làm những điều khác biệt.
Không có nhận xét nào:
Đăng nhận xét