mamnon76
Thành viên
- Tham gia
- 20/11/2015
- Bài viết
- 12
Trong chuỗi bài viết này, các chuyên gia công nghệ của Bitrix chia sẻ một số kinh nghiệm khi tiến hành xây dựng công cụ tích hợp giữa hệ thống quản trị Web (CMS) của Bitrix với giải pháp Back-office của 1C. Hiện nay, công cụ này có tính đa năng và đã được đóng gói sẵn trong CMS Bitrix và 1C. Như vậy, việc tích hợp Website và 1C đã trở nên đơn giản hơn bao giờ hết.
Làm thế nào để luôn đảm bảo cho danh sách hàng hóa và số lượng hàng tồn trên Website luôn được cập nhật, việc xử lý đơn hàng của khách được thực hiện theo đúng như quy trình nghiệp vụ được quy định trong doanh nghiệp? Rất nhiều chủ gian hàng trực tuyến (cửa hàng trên Internet) đã va chạm đến bài toán này.
Tích hợp một gian hàng trực tuyến với hệ thống kế toán của doanh nghiệp, nói chung không phải là một công việc quá phức tạp. Nhưng để tạo ra một cơ chế tích hợp một giải pháp CMS đóng gói và sao cho việc này trở nên đơn giản và dễ hiểu khi ứng dụng đại trà, đồng thời đảm bảo tính đa năng cho nhiều nhiệm vụ khác nhau thì lại là bài toán không hề đơn giản, nhưng rất hấp dẫn. Trong bài viết này, chúng tôi sẽ mô tả kinh nghiệm triển khai công cụ tích hợp gian hàng trực tuyến với hệ thống giải pháp 1C
OANH NGHIỆP.
Trước tiên, chúng tôi sẽ nói về việc lựa chọn kiến trúc và kỹ thuật của giải pháp, và cuối cùng để biết được xem cách tùy chỉnh và làm việc của cơ chế tích hợp này.
Thường thì rất nhiều các gian hàng trực tuyến được tạo ra để bổ sung cho các kênh bán hàng sẵn có: cửa hàng, điểm bán hàng, bán hàng đại lý… Và thông thường thì tất cả các kênh đều hợp nhất vào một hệ thống kế toán chung hoặc hệ thống ERP mà trong đó có thực hiện các quy trình nghiệp vụ chính của công ty:
Điều đầu tiên và quan trọng nhất khi tích hợp là ý thức được mục đích và nhiệm vụ cần giải quyết. Và sau đó từ đây thì mới lên kế hoạch thực thi, xem cần chuyển dữ liệu gì và và chuyển như thế nào:
Tất nhiên, đối với cửa hàng như vậy chỉ có thể có chung một kết quả như sau: với tâm trạng thất vọng và bức xúc, khách hàng sẽ khó có được mong muốn quay trở lại đây một lần nữa, cho dù có rất nhiều cố gắng chăm sóc từ phía người quản lý bán hàng.
Việc này đã xảy ra vào năm 2007. Cùng với việc phổ cập các gian hàng trực tuyến và mức độ tăng nhanh về nhu cầu đối với bài toán tích hợp thì chúng tôi, những người phát triển hệ thống CMS hiểu ra rằng, cần phải đề xuất cho khách hàng một giải pháp đóng gói và có độ tin cậy cao để giải quyết bài toán tích hợp như vậy: đơn giản trong tùy chỉnh và sử dụng.
Nhiệm vụ đầu tiên: cần lựa chọn hệ thống Back-office nào để xây dựng giải pháp tích hợp? Tại thời điểm đó, và cũng như hiện tại, giải pháp phổ dụng nhất ở Nga là nền tảng công nghệ 1COANH NGHIỆP, và phần lớn khách hàng đều muốn tích hợp Website của mình với 1C. Trong phần giải quyết bài toán thương mại, nhu cầu lớn nhất là cấu hình 1C:Quản lý thương mại. Và việc tích hợp đã được tiến hành chính cho giải pháp này.
Tất nhiên, tất cả những gì được viết ra ở đây đều có thể áp dụng cho việc giải quyết bài toán tích hợp của các giải pháp ERP và CMS khác. Nhưng phương pháp và ý tưởng là điều quan trọng, bởi vì nó mang tính đa năng, và mã nguồn đã dùng đều có thể tùy biến cho mọi tình huống.
Nhiệm vụ ngày càng được chi tiết hóa và chúng tôi đã bắt đầu công việc. Để bắt đầu, cần phải xác định xem cần có kiến trúc tương tác như thế nào. Nói chung, ở đây có 2 cách tiếp cận (phương pháp):
Khi áp dụng phương pháp này, khi cần thiết, Website sẽ gửi 1 truy vấn đến 1C hoặc gửi đi dữ liệu cho 1C.
Cần lưu ý rằng, việc hiển thị danh mục hàng hóa trên Internet và đặt hàng trực tuyến hoàn toàn có thể được thực hiện mà không cần phải có CMS, bởi vì 1C đã có tính năng như vậy, ví dụ như Web-extension, hoặc nền tảng công nghệ 1COANH NGHIỆP phiên bản 8.2 với công nghệ "Managed application" mà cho phép chuyển các tính năng cục bộ của giải pháp 1C lên Website.
Đây là ví dụ điển hình của phương pháp thứ nhất mà có một số ưu điểm, cũng như nhược điểm cho bài toán của chúng ta.
Các ưu điểm rất dễ dàng nhận thấy:
Khi đó, tại 1C cần đăng tải Web-service với bộ các phương thức, còn Website sẽ "gõ cửa" đều đều theo thời gian: lấy đi và chuyển lại dữ liệu. Tất cả đều có vẻ rất chuẩn. NHƯNG… phương pháp đầy tính công nghệ này trên thực tế rất tiếc lại không được phổ biến rộng rãi. Theo chúng tôi, có một số nguyên nhân sau đây:
Bởi vậy, chúng tôi đã áp dụng phương pháp thứ hai.
Đồng bộ hóa dữ liệu giữa 1C và Website theo lịch biểu
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:
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.
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 1COANH 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:
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:
(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 xâu 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
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
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:
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
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:
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ề:
Làm thế nào để luôn đảm bảo cho danh sách hàng hóa và số lượng hàng tồn trên Website luôn được cập nhật, việc xử lý đơn hàng của khách được thực hiện theo đúng như quy trình nghiệp vụ được quy định trong doanh nghiệp? Rất nhiều chủ gian hàng trực tuyến (cửa hàng trên Internet) đã va chạm đến bài toán này.
Tích hợp một gian hàng trực tuyến với hệ thống kế toán của doanh nghiệp, nói chung không phải là một công việc quá phức tạp. Nhưng để tạo ra một cơ chế tích hợp một giải pháp CMS đóng gói và sao cho việc này trở nên đơn giản và dễ hiểu khi ứng dụng đại trà, đồng thời đảm bảo tính đa năng cho nhiều nhiệm vụ khác nhau thì lại là bài toán không hề đơn giản, nhưng rất hấp dẫn. Trong bài viết này, chúng tôi sẽ mô tả kinh nghiệm triển khai công cụ tích hợp gian hàng trực tuyến với hệ thống giải pháp 1C
OANH NGHIỆP.
Thường thì rất nhiều các gian hàng trực tuyến được tạo ra để bổ sung cho các kênh bán hàng sẵn có: cửa hàng, điểm bán hàng, bán hàng đại lý… Và thông thường thì tất cả các kênh đều hợp nhất vào một hệ thống kế toán chung hoặc hệ thống ERP mà trong đó có thực hiện các quy trình nghiệp vụ chính của công ty:
- Quản lý danh mục hàng hóa;
- Bán hàng và mua hàng;
- Tài chính, báo cáo, phân tích…
Điều đầu tiên và quan trọng nhất khi tích hợp là ý thức được mục đích và nhiệm vụ cần giải quyết. Và sau đó từ đây thì mới lên kế hoạch thực thi, xem cần chuyển dữ liệu gì và và chuyển như thế nào:
- Đảm bảo kết xuất danh mục hàng hóa (mà đã nhập trong ERP) lên Website và duy trì tính thiết thực của danh mục này;
- Chuyển đơn hàng với các thông tin cần thiết từ Website vào ERP;
- Thông báo cho khách hàng về tiến trình thực hiện đơn hàng của khách mà đã được xử lý trong ERP.
Tất nhiên, đối với cửa hàng như vậy chỉ có thể có chung một kết quả như sau: với tâm trạng thất vọng và bức xúc, khách hàng sẽ khó có được mong muốn quay trở lại đây một lần nữa, cho dù có rất nhiều cố gắng chăm sóc từ phía người quản lý bán hàng.
Việc này đã xảy ra vào năm 2007. Cùng với việc phổ cập các gian hàng trực tuyến và mức độ tăng nhanh về nhu cầu đối với bài toán tích hợp thì chúng tôi, những người phát triển hệ thống CMS hiểu ra rằng, cần phải đề xuất cho khách hàng một giải pháp đóng gói và có độ tin cậy cao để giải quyết bài toán tích hợp như vậy: đơn giản trong tùy chỉnh và sử dụng.
Nhiệm vụ đầu tiên: cần lựa chọn hệ thống Back-office nào để xây dựng giải pháp tích hợp? Tại thời điểm đó, và cũng như hiện tại, giải pháp phổ dụng nhất ở Nga là nền tảng công nghệ 1C
OANH NGHIỆP, và phần lớn khách hàng đều muốn tích hợp Website của mình với 1C. Trong phần giải quyết bài toán thương mại, nhu cầu lớn nhất là cấu hình 1C:Quản lý thương mại. Và việc tích hợp đã được tiến hành chính cho giải pháp này.
Nhiệm vụ ngày càng được chi tiết hóa và chúng tôi đã bắt đầu công việc. Để bắt đầu, cần phải xác định xem cần có kiến trúc tương tác như thế nào. Nói chung, ở đây có 2 cách tiếp cận (phương pháp):
- Kết nối trực tiếp Website đến 1C.
- Trao đổi định kỳ giữa 1C và Website.
Khi áp dụng phương pháp này, khi cần thiết, Website sẽ gửi 1 truy vấn đến 1C hoặc gửi đi dữ liệu cho 1C.
Cần lưu ý rằng, việc hiển thị danh mục hàng hóa trên Internet và đặt hàng trực tuyến hoàn toàn có thể được thực hiện mà không cần phải có CMS, bởi vì 1C đã có tính năng như vậy, ví dụ như Web-extension, hoặc nền tảng công nghệ 1C
OANH NGHIỆP phiên bản 8.2 với công nghệ "Managed application" mà cho phép chuyển các tính năng cục bộ của giải pháp 1C lên Website. Đây là ví dụ điển hình của phương pháp thứ nhất mà có một số ưu điểm, cũng như nhược điểm cho bài toán của chúng ta.
Các ưu điểm rất dễ dàng nhận thấy:
- Danh mục hàng hóa luôn được cập nhật ở chế độ thời gian thực;
- Xuất hiện tức thời các đơn hàng mới ở 1C sau khi khách hàng đặt trên Website;
- Thông báo nhanh chóng cho khách hàng về kết quả xử lý đơn hàng;
Khi đó, tại 1C cần đăng tải Web-service với bộ các phương thức, còn Website sẽ "gõ cửa" đều đều theo thời gian: lấy đi và chuyển lại dữ liệu. Tất cả đều có vẻ rất chuẩn. NHƯNG… phương pháp đầy tính công nghệ này trên thực tế rất tiếc lại không được phổ biến rộng rãi. Theo chúng tôi, có một số nguyên nhân sau đây:
- Phức tạp trong việc tùy chỉnh để sử dụng đại trà: Để có thể đăng tải Web-service, cần phải thiết lập Web-server, viết lại mã nguồn kết nhập của mô-đun mở rộng, và đăng tải chính Web-service đó. Nếu có ai đó nói rằng: "điều này hoàn toàn không khó, là chuyện nhỏ" thì nói chung đó là ý kiến đúng. Trong 1C thậm chí đã có cả hàm để đăng tải Web-service trên Web-server. NHƯNG… cuộc sống vẫn là cuộc sống, đối với những người sử dụng đại trà, những người không phải là lập trình viên thì cảm thấy rất phức tạp và khó hiểu. Còn khi bắt đầu xuất hiện các vấn đề như: Web-service không làm việc, nhìn ngoài thì không thấy gì, không khởi tạo được người sử dụng, không đủ quyền truy cập… thì mọi người mới bắt đầu thấy choáng váng. Ngoài ra, nếu như doanh nghiệp có quy mô lớn thì cần phải huy động đến chuyên gia công nghệ.
- Tính phụ thuộc Website vào 1C: Hệ thống kế toán theo nhiều nguyên nhân khác nhau có thể không làm việc: đang cập nhật phần mềm, thay đổi thiết bị, phục hồi từ bản sao lưu dự phòng… Trong khoảng thời gian này, Website sẽ có thể làm việc không chuẩn xác, bởi vì hoàn toàn gắn kết với 1C. Tất nhiên, bạn có thể tính đến các tình huống này và tạo thêm các công cụ bảo vệ nhất định cho Website mà có thể tính đến một số tình huống có lỗi của cơ sở dữ liệu. Nhưng điều này lại buộc phải viết thêm mã nguồn, thêm các thủ thuật lô-gic mà sẽ làm phức tạp hóa hệ thống Web.
- Tính phụ thuộc của 1C vào Website: Một gian hàng trực tuyến có tiếng thường có nhiều khách ghé thăm, có mức tải lớn, nhiều đơn hàng trong một đơn vị thời gian. Nếu như Website cần phải thường xuyên chui vào 1C để lấy ra danh mục hàng hóa, bảng giá và số lượng hàng tồn thì tất cả mọi thứ đều rất chậm! Web-service là cơ chế thuận tiện, đầy tính công nghệ nhưng không phải là phương pháp trao đổi nhanh. Và ngay cả trong trường hợp khi mà Server 1C được chạy trên thiết bị khá tốt. Còn khi Website có mức tải cao điểm thì có thể làm tê liệt hoàn toàn công việc của cơ sở dữ liệu. Tất nhiên, danh mục hàng hóa có thể để trong bộ nhớ đệm trung gian (Cach) và truy vấn đến đó theo từng thời điểm, nhưng, thứ nhất, sẽ mất đi ưu việt của phương pháp này (chế độ thời gian thực), và thứ hai, còn có một một đề khá lớn nữa theo cách nhìn của chúng tôi: đó là yếu tố TÂM LÝ…
- Đe dọa tiềm tàng từ phía Website: Cùng nhớ lại rằng, 1C là hệ thống kế toán và quản lý chính của doanh nghiệp, trong đó có lưu toàn bộ cuộc sống của doanh nghiệp. Chương trình “1C:Quản lý thương mại” thường được tích hợp với "1C:KẾ TOÁN", "1C:Nhân sự và tiền lương". Còn có giải pháp tổng thể, trong đó có tất cả trong 1 gói. Thường thì vấn đề bảo mật của hệ thống này giống như để trên đầu kim, và cách giải quyết khá đơn giản: ngắt bỏ dây cáp "với Internet" ra khỏi Server (phương pháp vật lý, nếu theo như cách nói khoa học). Bây giờ, thử tưởng tượng xem, Bạn đang đứng ở vị trí nhà lãnh đạo mà được nghe thông báo rằng, bây giờ Website sẽ thường xuyên chui vào 1C để lấy ra dữ liệu: ghi, nhận, cập nhật. Như chúng ta đã biết, Website không chui trực tiếp vào 1C mà chỉ thông qua Web-service, nơi mà chỉ có một số quyền với mức độ hạn chế, tuy nhiên dù sao thì như thế cũng sẽ rất khó có thể chấp nhận được. Tại sao vậy? Website có thể bị tấn công và nhiễm vi-rút, đồng thời lại CÓ QUYỀN TRUY CẬP TỚI 1C? Ôi, thế thì phải giải tán ngay…!?
Đồng bộ hóa dữ liệu giữa 1C và Website theo lịch biểu
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.
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.
Kết quả là chúng ta có được kiến trúc tích hợp như sau:
OANH 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:
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:
(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 xâu 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
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
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:
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
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ở.
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.
