Yêu cầu chuyển đổi thường nằm giữa hai thái cực. Phương án chuyển đổi được hỗ trợ mặc định có thể đã phù hợp về cấu trúc, nhưng doanh nghiệp vẫn cần kiểm soát chặt hơn bản ghi nào được di chuyển, một số giá trị sẽ được đưa vào đâu hoặc những giá trị được chọn cần thay đổi như thế nào trước khi đến Cửa hàng đích. Đó là vai trò của Add-ons trong các Dịch vụ chuyển đổi dữ liệu của Next-Cart.
Điểm quan trọng không phải chỉ là một Add-on nghe có vẻ phù hợp hay không. Mỗi Add-on xử lý một loại vấn đề dữ liệu khác nhau, và nhiều Add-ons có thể phối hợp khi cùng một yêu cầu chuyển đổi gồm nhiều bước. Hiểu rõ các khác biệt này giúp tách những phần mở rộng vẫn nằm trong phạm vi hỗ trợ khỏi công việc rộng hơn cần Custom Service.
Add-ons xử lý những nhu cầu dữ liệu có phạm vi rõ ràng
Add-ons mở rộng cách dữ liệu được xử lý trong phạm vi hỗ trợ mà không thay đổi lộ trình chuyển đổi cố định. Một yêu cầu Add-on hữu ích nên bắt đầu từ kết quả kinh doanh cần đạt, sau đó xác định chính xác thao tác dữ liệu cần thực hiện để tạo ra kết quả đó.
Có thể phân biệt bốn Standard Add-ons bằng bốn câu hỏi:
- Bản ghi nào cần tiếp tục được xử lý trong quá trình chuyển đổi? Đây là câu hỏi dành cho Data Filter.
- Trường đích tương thích nào cần nhận một trường nguồn được hỗ trợ? Đây là câu hỏi dành cho Advanced Data Mapping.
- Yêu cầu có cần chuyển trường hoặc cột cơ sở dữ liệu được hỗ trợ khi cả Nền tảng nguồn và Nền tảng đích đều là Open Source hay không? Đây là câu hỏi dành cho Advanced Database Mapping.
- Giá trị của một trường đích đã chọn cần được thay đổi như thế nào trong quá trình chuyển đổi? Đây là câu hỏi dành cho Data Transformation.
Các chức năng này có liên quan nhưng không thể thay thế lẫn nhau. Lọc dữ liệu thay đổi phạm vi bản ghi tham gia. Mapping thay đổi nơi giá trị được đưa tới. Database mapping có thể làm việc ở tầng cơ sở dữ liệu trong phạm vi được hỗ trợ. Transformation thay đổi giá trị đích được chọn.
Bốn Standard Add-ons, bốn quyết định khác nhau
Cách rõ nhất để hiểu bốn Standard Add-ons là xem mỗi Add-on kiểm soát phần nào của kết quả chuyển đổi. Đây không phải bốn phiên bản của cùng một tính năng. Một Add-on kiểm soát bản ghi nào tham gia, hai Add-ons kiểm soát giá trị được biểu diễn ở đâu, và một Add-on kiểm soát giá trị cuối cùng tại hệ thống đích sẽ trở thành gì.
| Standard Add-on | Vai trò chính | Dấu hiệu phù hợp | Vai trò khi kết hợp | Giá cố định |
|---|---|---|---|---|
| Data Filter | Chọn bản ghi được di chuyển bằng các điều kiện ở cấp trường được hỗ trợ cho một loại dữ liệu. | Doanh nghiệp chỉ cần một nhóm con xác định trong số các bản ghi vốn đủ điều kiện. | Chạy đầu tiên và xác định tập bản ghi mà mọi Add-on phía sau sẽ xử lý. | $50 |
| Advanced Data Mapping | Chuyển một trường nguồn được hỗ trợ sang trường đích tương thích khác mà không thay đổi giá trị trong thao tác mapping. | Giá trị nguồn đã đúng nhưng cần nằm ở một trường đích được hỗ trợ khác. | Chạy sau bước lọc và xác định vị trí cho các trường được hỗ trợ trước khi xử lý ở tầng cơ sở dữ liệu. | $50 |
| Advanced Database Mapping | Chuyển các trường và cột cơ sở dữ liệu được hỗ trợ sang trường hoặc cột đích tương thích, gồm những trường đặc thù của nền tảng và các trường tùy chỉnh đủ điều kiện. | Yêu cầu phụ thuộc vào cách dữ liệu được biểu diễn ở tầng cơ sở dữ liệu chứ không chỉ ở lớp trường được hỗ trợ. | Chạy sau Advanced Data Mapping và có thể xác định giá trị hoặc vị trí mà Data Transformation nhận ở bước tiếp theo. Chỉ áp dụng khi cả hai nền tảng đều Open Source. | $100 |
| Data Transformation | Biến đổi giá trị của các trường đích được chọn trong quá trình chuyển đổi. | Bản thân giá trị cuối cùng tại hệ thống đích cần được tính lại, chuẩn hóa, định dạng lại hoặc thay đổi theo một quy tắc được hỗ trợ. | Chạy cuối cùng và xử lý giá trị đích đã được thiết lập sau các bước mapping. | $50 |
Bảng trên đặc biệt hữu ích vì một yêu cầu kinh doanh có thể đồng thời xuất hiện nhiều dấu hiệu. Chẳng hạn, yêu cầu "chỉ di chuyển nhóm Products này, đưa một giá trị nguồn sang trường khác, dùng một giá trị trong custom database làm Price rồi cộng thêm biên giá" không phải một yêu cầu tùy chỉnh mơ hồ. Đó là bốn thao tác khác nhau có thể được đánh giá riêng, sau đó kết hợp theo đúng trình tự xử lý.
Data Filter: xác định tập bản ghi tham gia
Data Filter phù hợp khi doanh nghiệp có thể mô tả những bản ghi nào cần xuất hiện trong kết quả chuyển đổi bằng các điều kiện ở cấp trường được hỗ trợ.
Những câu hỏi điển hình gồm:
- Chỉ Products đang hoạt động mới cần được đưa sang hay không?
- Orders có cần giới hạn theo một khoảng thời gian kinh doanh hoặc điều kiện trạng thái xác định không?
- Chỉ Customers đáp ứng một điều kiện trường đã thống nhất mới tiếp tục được xử lý hay không?
- Một loại dữ liệu nội dung có cần thu hẹp còn những bản ghi liên quan đến Cửa hàng mới không?
Ranh giới quan trọng là Data Filter thay đổi việc bản ghi có tham gia hay không, chứ không thay đổi trường đích hoặc giá trị của bản ghi đó. Bản ghi Products bị loại bởi bộ lọc sẽ không đi vào các bước Add-on phía sau trong phạm vi chuyển đổi này. Bản ghi Products vượt qua bộ lọc tiếp tục được xử lý với dữ liệu được hỗ trợ ở các bước mapping và transformation tiếp theo.
Điều này khiến Data Filter đặc biệt quan trọng trong các yêu cầu kết hợp. Nếu một quy tắc mapping hoặc transformation phía sau chỉ nên áp dụng cho một phần catalog, bước lọc cần xác định tập bản ghi đó ngay từ đầu thay vì yêu cầu một Add-on phía sau phân biệt những bản ghi mà Add-on đó không được thiết kế để lựa chọn.
Entity Points vẫn là một khái niệm riêng về dung lượng. Products, Customers, Orders và Blog Posts có thể tiêu thụ Entity Points theo trọng số được quy định, nhưng số Entity Points không cho biết chính xác bản ghi nào cần được di chuyển. Data Filter xử lý quyết định lựa chọn bản ghi đó.
Hai tình huống Data Filter có thể xử lý độc lập
Chỉ di chuyển Products đang được bật. Doanh nghiệp đang loại bỏ Products đã ngừng kinh doanh hoặc bị vô hiệu hóa và chỉ muốn đưa vào phạm vi chuyển đổi những Products có trường trạng thái được hỗ trợ cho biết chúng đang được bật. Data Filter phù hợp vì quyết định kinh doanh nằm ở bản ghi Products nào được tham gia, không phải giá trị được chuyển sang trường nào hay cần thay đổi ra sao. Điều kiện cụ thể vẫn phụ thuộc vào các trường và toán tử được hỗ trợ trên lộ trình chuyển đổi đã chọn.
Giới hạn Orders trong một giai đoạn kinh doanh xác định. Doanh nghiệp có thể chỉ cần những Orders được tạo sau một ngày đã thống nhất cho dự án, còn những Orders được tạo từ trước đó không thuộc phạm vi dự kiến. Khi trường ngày và phép so sánh cần dùng đều được hỗ trợ, Data Filter có thể xác định tập bản ghi này trước khi bất kỳ quy tắc mapping hoặc transformation nào ở các bước sau được đánh giá. Việc lọc không làm thay đổi ý nghĩa của những Orders được chọn; bước lọc chỉ quyết định bản ghi nào tiếp tục được xử lý.
Advanced Data Mapping: giữ nguyên giá trị, thay đổi trường đích được hỗ trợ
Advanced Data Mapping phù hợp khi giá trị nguồn đã đúng nhưng vị trí đích được hỗ trợ hiện tại không phù hợp.
Có thể hình dung đây là việc chuyển trực tiếp:
trường nguồn được hỗ trợ -> trường đích tương thích
Ví dụ, nếu lộ trình chuyển đổi đã chọn hỗ trợ cả Short Description và Description của Products, doanh nghiệp có thể cần giá trị Short Description ở nguồn trở thành Description tại hệ thống đích. Giá trị không cần được tính lại. Điều cần thay đổi là trường đích được hỗ trợ nhận giá trị đó.
Sự khác biệt này giúp phân loại yêu cầu rõ ràng hơn:
- "Đưa giá trị nguồn được hỗ trợ này sang trường đích tương thích kia" hướng đến Advanced Data Mapping.
- "Thay đổi giá trị này trước khi giá trị được đưa tới Cửa hàng đích" hướng đến Data Transformation.
- "Giá trị nằm trong một cột cơ sở dữ liệu bên dưới và cần được xử lý ở tầng cơ sở dữ liệu" có thể hướng đến Advanced Database Mapping nếu toàn bộ lộ trình đủ điều kiện.
Trong một quy trình kết hợp, Advanced Data Mapping chỉ nhận những bản ghi đã vượt qua Data Filter. Add-on này xác định vị trí cho các trường được hỗ trợ trước khi Advanced Database Mapping và Data Transformation chạy. Nếu các bước phía sau cùng tác động đến một trường đích hoặc các vị trí có liên quan, trình tự xử lý quyết định giá trị nào sẽ được chuyển tiếp sang bước sau.
Advanced Data Mapping vẫn có các giới hạn. Trường nguồn và trường đích phải được hỗ trợ và tương thích, còn dữ liệu Tax nằm ngoài phạm vi mapping của Standard Add-on. Việc đưa giá trị sang một trường đích khác cũng không bảo đảm ứng dụng, theme, extension hoặc quy tắc nghiệp vụ ở hệ thống đích sẽ sử dụng giá trị đó theo một cách cụ thể.
Hai tình huống Advanced Data Mapping có thể xử lý độc lập
Dùng Short Description của Products làm Description ở đích. Nội dung nguồn đã đúng, nhưng Cửa hàng đích cần giá trị được hỗ trợ đó nằm ở một trường tương thích khác. Advanced Data Mapping phù hợp vì yêu cầu chỉ thay đổi vị trí đích: Short Description -> Description. Thao tác mapping giữ nguyên giá trị thay vì viết lại nội dung.
Chuyển một giá trị liên hệ được hỗ trợ của Customers sang trường liên hệ khác. Hai nền tảng có thể tổ chức thông tin Customers khác nhau, khiến một trường liên hệ được hỗ trợ ở nguồn cần được đưa sang một trường liên hệ tương thích khác ở đích. Khi cả hai trường đều được hỗ trợ và trường đích có thể biểu diễn đúng giá trị nguồn, Advanced Data Mapping có thể thực hiện việc chuyển vị trí này mà không biến vấn đề về trường đích thành yêu cầu transformation hoặc Custom Service.
Advanced Database Mapping: xử lý dữ liệu ở tầng cơ sở dữ liệu khi đủ điều kiện
Advanced Database Mapping trở nên phù hợp khi yêu cầu không thể mô tả đơn giản là chuyển một trường ứng dụng được hỗ trợ sang một trường ứng dụng được hỗ trợ khác. Add-on này mở rộng phạm vi mapping đến các trường và cột cơ sở dữ liệu đủ điều kiện, bao gồm các trường đặc thù của nền tảng và các trường tùy chỉnh vẫn nằm trong phạm vi Standard được hỗ trợ.
Phạm vi áp dụng hẹp hơn có chủ đích vì xử lý ở tầng cơ sở dữ liệu phụ thuộc vào kiến trúc ở cả hai phía. Cả Nền tảng nguồn và Nền tảng đích đều phải là Open Source. Nếu một trong hai nền tảng là Non-Open-Source, Advanced Database Mapping không áp dụng.
Điều kiện kiến trúc này mới chỉ trả lời câu hỏi đủ điều kiện đầu tiên. Một lộ trình chuyển đổi phù hợp không có nghĩa mọi trường hoặc cột đều có thể được mapping. Yêu cầu cụ thể vẫn phải được kiểm tra về:
- trường nguồn hoặc cột cơ sở dữ liệu có nằm trong phạm vi được hỗ trợ hay không;
- có trường hoặc cột đích tương thích hay không;
- kiểu dữ liệu của giá trị có đủ tương thích hay không;
- quan hệ và ý nghĩa dữ liệu có được hỗ trợ hay không;
- dữ liệu Tax có được loại khỏi phạm vi Standard mapping hay không.
Vì vậy, Add-on này hữu ích nhất khi doanh nghiệp có thể xác định rõ giá trị ở tầng cơ sở dữ liệu cần được giữ lại, vị trí tương thích mà giá trị đó phải chiếm ở Cửa hàng đích và bằng chứng cần dùng để xác nhận kết quả mapping vẫn phục vụ đúng mục đích.
Trong trình tự xử lý, Advanced Database Mapping chạy sau Advanced Data Mapping và trước Data Transformation. Vị trí này quan trọng khi database mapping thiết lập một giá trị cần được tính lại hoặc định dạng lại ở bước sau. Data Transformation nhận kết quả có sẵn sau cả hai bước mapping, vì vậy giá trị được thiết lập từ database mapping có thể trở thành đầu vào trực tiếp cho quy tắc thay đổi giá trị cuối cùng.
Database mapping cũng tách biệt với việc triển khai ở hệ thống đích. Lưu thành công một giá trị vào trường hoặc cột đích tương thích không chứng minh rằng theme, extension, workflow của ứng dụng, quy tắc thuế hoặc chức năng trên storefront sẽ diễn giải hay hiển thị giá trị đó đúng như mong muốn. Các kết quả này cần được xác thực riêng.
Hai tình huống Advanced Database Mapping có thể xử lý độc lập
Dùng một cột số tùy chỉnh được hỗ trợ của Products làm mức giá ở đích. Trên một lộ trình Open Source sang Open Source đủ điều kiện, doanh nghiệp có thể có một cột cơ sở dữ liệu tùy chỉnh được hỗ trợ, chẳng hạn regional_base_price, cần được đưa vào một trường hoặc cột giá tương thích ở đích. Advanced Database Mapping phù hợp vì giá trị nguồn nằm ở tầng cơ sở dữ liệu. Tuy nhiên, điều kiện kiến trúc mới chỉ là bước đầu: cột nguồn cụ thể, vị trí đích, khả năng tương thích của kiểu dữ liệu và phạm vi Standard vẫn phải được xác nhận.
Giữ một giá trị cơ sở dữ liệu đặc thù của nền tảng. Một Nền tảng nguồn Open Source có thể lưu một giá trị Products quan trọng trong cột cơ sở dữ liệu riêng của nền tảng thay vì ở lớp trường tiêu chuẩn. Nếu Nền tảng đích Open Source đã chọn có vị trí tương thích được hỗ trợ và yêu cầu chỉ là mapping trực tiếp, giữ nguyên giá trị, Advanced Database Mapping có thể đưa giá trị đó vào trường hoặc cột đích dự kiến. Điều này không có nghĩa theme, app, extension hay workflow ở đích sẽ tự động sử dụng giá trị đã lưu.
Data Transformation: thay đổi giá trị cuối cùng tại hệ thống đích
Data Transformation phù hợp khi đã biết vị trí đích nhưng giá trị cần tồn tại tại đó phải thay đổi.
Các trường hợp phổ biến gồm:
- áp dụng phép tính cho một giá trị số;
- thêm, loại bỏ hoặc tái cấu trúc nội dung văn bản bằng biểu thức được hỗ trợ;
- chuẩn hóa giá trị về cách biểu diễn đã thống nhất ở hệ thống đích;
- tính giá trị cuối cùng từ dữ liệu đã được thiết lập ở một bước mapping trước đó.
Cách phân biệt rõ nhất là: mapping trả lời giá trị này cần đi đâu? Còn transformation trả lời giá trị cuối cùng cần trở thành gì?
Vì Data Transformation chạy cuối, Add-on này xử lý giá trị đích có sẵn sau Advanced Data Mapping và, khi đủ điều kiện, Advanced Database Mapping. Điều này đặc biệt hữu ích ở bước cuối của một yêu cầu kết hợp. Chẳng hạn, nếu database mapping thiết lập giá trị Price tại hệ thống đích, Data Transformation có thể tính Price cuối cùng từ giá trị vừa được mapping thay vì dựa trên một trường nguồn trước đó không còn là đầu vào phù hợp.
Data Transformation không quyết định bản ghi nào tham gia và không quyết định trường hoặc cột đích nào nhận giá trị nguồn. Các quyết định đó thuộc những bước trước. Vì vậy, một quy tắc transformation được xác định tốt cần có trường đích rõ ràng, giá trị đầu vào rõ ràng sau mapping và quy tắc được hỗ trợ để tạo ra đầu ra mong muốn.
Hai tình huống Data Transformation có thể xử lý độc lập
Tăng giá bán ở đích thêm 12%. Doanh nghiệp có thể muốn Regular Price ở đích cao hơn 12% so với giá trị đã được thiết lập sau bước mapping trước đó. Data Transformation phù hợp vì vị trí đích đã rõ và giá trị kết quả cần thay đổi. Một phép tính được hỗ trợ như Regular Price x 1.12 vì vậy là yêu cầu transformation, không phải quyết định mapping.
Chuẩn hóa một giá trị văn bản ở đích. Nền tảng nguồn và Nền tảng đích có thể biểu diễn cùng một ý nghĩa kinh doanh theo những quy ước văn bản khác nhau. Khi một quy tắc transformation được hỗ trợ có thể chuẩn hóa giá trị cuối ở đích về cách biểu diễn cần thiết, Data Transformation là Add-on phù hợp. Quy tắc này làm việc với giá trị đang có ở đích sau các bước mapping áp dụng; Data Transformation không chọn bản ghi tham gia và cũng không quyết định trường đích nào nhận giá trị nguồn.
Vì sao thứ tự xử lý dữ liệu qua các Add-ons lại quan trọng
Khi dùng nhiều Add-ons cùng nhau, hệ thống xử lý theo thứ tự cố định:
Data Filter → Advanced Data Mapping → Advanced Database Mapping → Data Transformation
Thứ tự này giúp phân tích một yêu cầu chuyển đổi nhiều bước thành bốn quyết định liên tiếp:
- Lựa chọn bản ghi: Bản ghi nào được phép tiếp tục?
- Trường đích: Các trường nguồn được hỗ trợ cần được biểu diễn ở đâu?
- Vị trí ở tầng cơ sở dữ liệu: Một lộ trình Open Source sang Open Source đủ điều kiện có cần liên kết trường hoặc cột cơ sở dữ liệu được hỗ trợ vượt ra ngoài lớp trường tiêu chuẩn hay không?
- Giá trị cuối cùng: Sau khi mapping hoàn tất, giá trị tại hệ thống đích cần trở thành gì?
Mỗi Add-on được áp dụng sẽ xử lý dữ liệu dựa trên kết quả mà các bước trước đã tạo ra. Điều này không có nghĩa mọi dự án đều cần đủ bốn Add-ons, cũng không có nghĩa mọi Add-on phải tác động đến cùng một trường. Khi kết hợp nhiều Add-ons, cần xem yêu cầu như một chuỗi xử lý dữ liệu liên tiếp, trong đó kết quả của bước trước trở thành dữ liệu mà bước tiếp theo có liên quan tiếp tục xử lý, thay vì thiết kế từng quy tắc tách rời.
Các cách kết hợp Add-ons thường gặp
Nhiều yêu cầu thực tế chỉ cần hai hoặc ba bước. Nhận diện đúng mô hình giúp đánh giá khả năng hỗ trợ trước khi kết luận cần công việc tùy chỉnh.
| Mô hình yêu cầu kinh doanh | Tổ hợp Add-on thường phù hợp | Vì sao phù hợp |
|---|---|---|
| Chỉ di chuyển một nhóm bản ghi xác định, sau đó thay đổi một giá trị đích của nhóm đó. | Data Filter + Data Transformation | Data Filter xác định bản ghi tham gia; Data Transformation thay đổi giá trị cần thiết chỉ trên các bản ghi đó. |
| Đưa một trường nguồn được hỗ trợ sang trường đích tương thích khác, sau đó thay đổi giá trị kết quả. | Advanced Data Mapping + Data Transformation | Mapping xác định vị trí; transformation xử lý giá trị có sẵn tại vị trí đó ở bước sau. |
| Dùng một giá trị đủ điều kiện ở tầng cơ sở dữ liệu làm giá trị đích, sau đó áp dụng phép tính hoặc quy tắc chuẩn hóa. | Advanced Database Mapping + Data Transformation | Database mapping thiết lập giá trị đích; transformation tạo giá trị cuối cùng. Cả hai nền tảng phải Open Source để bước database mapping áp dụng. |
| Giới hạn bản ghi, chuyển các trường được hỗ trợ sang vị trí khác rồi thay đổi giá trị đích. | Data Filter + Advanced Data Mapping + Data Transformation | Quy trình kết hợp phạm vi bản ghi, kiểm soát vị trí và thay đổi giá trị cuối mà không cần database mapping. |
| Giới hạn bản ghi, liên kết trường được hỗ trợ, dùng database mapping đủ điều kiện rồi biến đổi kết quả cuối cùng. | Cả bốn Standard Add-ons | Mỗi bước xử lý một phần riêng của cùng một yêu cầu và chuyển kết quả phù hợp sang bước tiếp theo. |
Việc có nhiều bước không tự động biến dự án thành trường hợp Custom Service. Nếu mỗi thao tác vẫn nằm trong phạm vi Standard được hỗ trợ của Add-on tương ứng, yêu cầu kết hợp vẫn có thể được xử lý bằng Standard Add-ons. Công việc tùy chỉnh chỉ trở nên cần thiết khi bản thân một thao tác cần được sửa đổi, phụ thuộc vào dữ liệu chưa được hỗ trợ, cần quy tắc xử lý riêng hoặc vượt ra ngoài giới hạn Standard.
Một cách lập kế hoạch thực tế là bắt đầu từ kết quả mong muốn tại Cửa hàng đích rồi đi ngược lại. Xác định giá trị hoặc cách biểu diễn cuối cùng trước, sau đó xem cần transformation, database mapping, cách liên kết giữa các trường, record filtering hay tổ hợp nào trong số đó.
Ví dụ: bốn Add-ons bổ trợ cho nhau để đáp ứng một yêu cầu chuyển đổi của khách hàng
Xét một lộ trình chuyển đổi từ OpenCart sang WooCommerce, trong đó các trường của Products cần thiết đều được hỗ trợ và custom database column được chọn đáp ứng các kiểm tra mapping và tương thích áp dụng. Cả hai đều là nền tảng Open Source, vì vậy lộ trình này có thể được đánh giá cho Advanced Database Mapping.
Doanh nghiệp muốn đạt bốn kết quả liên kết với nhau:
- chỉ di chuyển Products đang được bật và vẫn còn tồn kho;
- dùng
Short Descriptionở nguồn làmDescriptiontại hệ thống đích; - dùng một custom numeric database column của Products được hỗ trợ có tên
regional_base_pricelàmRegular Pricetại hệ thống đích; - tăng
Regular Pricekết quả thêm 12% trong quá trình chuyển đổi.
Không Add-on nào có thể xử lý toàn bộ yêu cầu này một mình.
Bước 1: chọn bản ghi Products
Data Filter áp dụng các điều kiện Products đã thống nhất, chẳng hạn trạng thái đang bật và số lượng tồn kho lớn hơn 0. Products không đáp ứng điều kiện sẽ không tiếp tục đi qua các bước Add-on còn lại trong phạm vi chuyển đổi này.
Bộ lọc chỉ giải quyết việc lựa chọn bản ghi. Data Filter không quyết định mô tả hoặc giá sẽ được biểu diễn như thế nào tại Cửa hàng đích.
Bước 2: chuyển trường mô tả được hỗ trợ sang vị trí mới
Advanced Data Mapping chuyển trường nguồn Short Description được hỗ trợ sang trường đích Description tương thích.
Thao tác này thay đổi vị trí của giá trị được hỗ trợ nhưng vẫn tách biệt với mọi thay đổi giá trị có thể diễn ra ở bước sau.
Bước 3: thiết lập giá từ nguồn dữ liệu ở tầng cơ sở dữ liệu
Advanced Database Mapping chuyển giá trị số được hỗ trợ trong custom database column regional_base_price sang vị trí đích Regular Price tương thích.
Bước này chỉ khả thi trong ví dụ vì cả hai phía của lộ trình đều là nền tảng Open Source và giả định rằng trường hoặc cột cụ thể đáp ứng đầy đủ điều kiện của Standard Add-on. Không nên mặc định một custom column đủ điều kiện chỉ vì Advanced Database Mapping tồn tại.
Bước 4: tính giá cuối cùng tại hệ thống đích
Data Transformation sau đó áp dụng phép tính cần thiết cho Regular Price, ví dụ:
Regular Price x 1.12
Vì Data Transformation chạy sau cả hai bước mapping, phép tính sẽ dùng Regular Price đã được Advanced Database Mapping thiết lập chứ không dựa trên một giá trị Price trước đó không còn là đầu vào liên quan.
Kết quả cuối cho thấy vì sao Add-ons nên được đánh giá như một chuỗi xử lý phối hợp. Data Filter xác định Products tham gia, các bước mapping xác định nơi thông tin liên quan được biểu diễn, còn Data Transformation tạo giá cuối cùng sau tính toán.
Kết quả chuyển đổi vẫn cần được xác thực. Ví dụ này minh họa cách xử lý dữ liệu, không bảo đảm mọi quy tắc giá, theme, extension, cách áp dụng Tax hoặc cách trình bày trên storefront sẽ tự động được cấu hình bởi quá trình chuyển đổi.
Add-ons tương tác thế nào khi cùng tác động đến một nhóm dữ liệu
Nhiều Add-ons kết hợp có thể tương tác theo các cách khác nhau. Điều quan trọng là hiểu mô hình tương tác, không chỉ đếm số Add-ons đang được sử dụng.
| Mô hình tương tác | Điều xảy ra về mặt xử lý | Ý nghĩa đối với việc lập kế hoạch |
|---|---|---|
| Cùng bản ghi, khác trường | Data Filter xác định bản ghi tham gia, còn các quy tắc mapping hoặc transformation riêng tác động đến những trường khác nhau trong cùng bản ghi. | Các Add-ons vẫn được phối hợp bởi cùng phạm vi bản ghi dù không tác động cùng một vị trí đích. |
| Các bước mapping khác nhau, cùng vị trí đích | Advanced Data Mapping và Advanced Database Mapping đều có thể góp phần xác định giá trị ở một vị trí đích. Bước mapping áp dụng sau cùng xác định giá trị được chuyển sang quá trình xử lý tiếp theo. | Các quy tắc mapping chồng lên nhau cần thể hiện một chiến lược dữ liệu cuối cùng có chủ đích, không phải những ý định độc lập. |
| Mapping rồi transformation | Một bước mapping thiết lập giá trị hoặc vị trí đích, sau đó Data Transformation thay đổi giá trị tồn tại sau mapping. | Quy tắc transformation cần được thiết kế dựa trên kết quả đã mapping, không dựa trên giá trị nguồn trước đó không còn là đầu vào phù hợp. |
| Lọc rồi xử lý phía sau | Data Filter loại bản ghi khỏi tập tham gia trước khi bất kỳ mapping hoặc transformation nào diễn ra. | Các Add-ons phía sau cần được đánh giá trên tập bản ghi đã lọc sẽ thực sự tới bước đó. |
Mô hình này giúp yêu cầu nhiều bước dễ được rà soát hơn. Doanh nghiệp có thể tách một yêu cầu thành phạm vi bản ghi, vị trí đích, cách biểu diễn ở tầng cơ sở dữ liệu và quy tắc giá trị cuối cùng, sau đó kiểm tra xem các phần đó bổ trợ cho nhau hay tạo ra giả định xung đột.
Trường hợp nhạy cảm nhất là khi nhiều quy tắc mapping cùng tác động đến một trường hoặc cột đích. Khi đó, thứ tự xử lý quyết định giá trị nào sẽ được chuyển sang Data Transformation. Cách thiết kế an toàn nhất là bắt đầu từ giá trị cuối cùng mong muốn tại Cửa hàng đích rồi lần ngược từng bước, xác nhận bước nào cần thiết lập mỗi kết quả trung gian.
Cách kiểm tra ngược này cũng hữu ích khi Add-ons tác động đến các trường khác nhau. Việc lần ngược quy trình giúp phát hiện quy tắc không cần thiết, vị trí đích không thể biểu diễn đúng ý nghĩa nguồn, transformation đang chờ sai đầu vào hoặc bản ghi đáng lẽ phải bị loại trước khi xử lý phía sau bắt đầu.
Tương thích không chỉ là tên trường giống nhau
Trường nguồn và trường đích có thể có tên tương tự nhưng vẫn không tương thích. Quyết định mapping cần xét liệu Nền tảng đích có thể biểu diễn giá trị nguồn đúng hay không.
Đối với các mapping Add-ons, trường hoặc cột đích phải có khả năng chứa phù hợp với kiểu dữ liệu của giá trị nguồn. Một giá trị số thường có thể được biểu diễn trong trường văn bản, nhưng một chuỗi văn bản bất kỳ không thể an toàn được coi là số chỉ vì vài mẫu tình cờ trông giống dữ liệu số. Khi chưa chắc chắn về khả năng tương thích, cần xác thực thay vì giả định.
Các mapping Add-ons cũng có giới hạn chức năng. Dữ liệu Tax nằm ngoài phạm vi được hỗ trợ của Advanced Data Mapping và Advanced Database Mapping. Yêu cầu liên quan đến loại dữ liệu, trường, cột, quan hệ, script hoặc cách ứng dụng hoạt động chưa được hỗ trợ có thể cần Tailored Add-on, Custom Add-on hoặc Custom Service rộng hơn.
Standard, Tailored và Custom Add-ons
Chức năng cần có và mức độ tùy chỉnh cần thiết là hai quyết định riêng.
| Cấp Add-on | Ý nghĩa | Cách tính giá |
|---|---|---|
| Standard Add-on | Add-on dựng sẵn được dùng trong phạm vi cố định được hỗ trợ. | Giá cố định theo catalog. |
| Tailored Add-on | Chức năng của một Standard Add-on cần được tinh chỉnh, sửa đổi hoặc mở rộng vượt khỏi phạm vi Standard. | Được rà soát và báo giá thông qua Custom Service. |
| Custom Add-on | Chức năng Add-on riêng được xây dựng ngoài phạm vi chức năng của catalog Standard Add-on. | Được rà soát và báo giá thông qua Custom Service. |
Một yêu cầu không trở thành Custom Service chỉ vì kết hợp nhiều Standard Add-ons. Nếu từng thao tác đều nằm trong phạm vi Standard tương ứng, toàn bộ quy trình vẫn có thể chỉ dùng Standard Add-ons.
Tương tự, cụm từ custom field hoặc database column không tự động đồng nghĩa với một dự án tùy chỉnh. Yêu cầu cần được kiểm tra trước với phạm vi được hỗ trợ của Advanced Data Mapping hoặc Advanced Database Mapping. Custom Service chỉ trở nên phù hợp khi kết quả cần đạt vượt quá phạm vi xử lý mà các Add-ons này hỗ trợ.
Add-ons và Custom Service giải quyết những vấn đề khác nhau
Add-ons xử lý các yêu cầu dữ liệu có phạm vi rõ ràng. Custom Service sở hữu phần công việc rộng hơn, cần điều chỉnh hoặc không theo chuẩn khi yêu cầu không thể được đáp ứng trong phạm vi chuyển đổi được hỗ trợ và chức năng Standard Add-on.
Custom Service trở nên cần thiết khi thao tác yêu cầu không còn phù hợp với mô hình Standard Add-on có giới hạn rõ. Dấu hiệu điển hình gồm dữ liệu của ứng dụng hoặc extension bên thứ ba chưa được hỗ trợ, script hoặc API processing riêng, quan hệ hoặc quy tắc chuyển đổi không theo chuẩn, và chức năng Add-on phải được tinh chỉnh hoặc phát triển vượt ra ngoài catalog Standard. Phạm vi không theo chuẩn rộng hơn được giải thích trong nội dung riêng về Custom Service; quyết định quan trọng ở đây là nhận biết khi Add-on một mình không còn mô tả đầy đủ công việc cần thực hiện.
Một dự án Custom Service vẫn có thể sử dụng Standard Add-ons bên trong phạm vi tùy chỉnh rộng hơn. Việc có Custom Service không thay đổi chức năng của từng Add-on; Custom Service chỉ thay đổi cách phần công việc riêng của dự án cần được xử lý.
Add-ons liên quan thế nào đến Entity Points và chi phí
Entity Points và Add-ons trả lời hai câu hỏi lập kế hoạch khác nhau.
Entity Points đo dung lượng chuyển đổi được tính cho Products, Customers, Orders và Blog Posts. Add-ons kiểm soát những thao tác xử lý được hỗ trợ cụ thể. Add-on không tạo thêm trọng số Entity Points mới, và một loại dữ liệu không được tính điểm cũng không trở thành dữ liệu tính điểm chỉ vì loại dữ liệu đó được xử lý bằng Add-on.
Giá cố định của Standard Add-ons trong bảng catalog ở trên tách biệt với dung lượng Entity Points. Tailored Add-ons và Custom Add-ons không dùng mức giá Standard cố định đó làm báo giá cuối cùng vì phần công việc bổ sung của chúng được rà soát thông qua Custom Service.
Khi một Add-on đủ điều kiện được bổ sung sau vào cùng Dịch vụ chuyển đổi dữ liệu đã mua, nâng cấp áp dụng nguyên tắc chỉ tính phần chênh lệch. Add-on thay đổi cấu hình dịch vụ cho lần chuyển đổi đó; việc nâng cấp không thay đổi lộ trình cố định từ Nền tảng nguồn sang Nền tảng đích và cũng không khởi động lại thời hạn dịch vụ.
Cách đánh giá Add-on có phù hợp với yêu cầu thực tế hay không
Nên bắt đầu việc đánh giá Add-on từ kết quả mong muốn tại Cửa hàng đích, thay vì bắt đầu từ tên Add-on. Sau đó có thể tách yêu cầu kinh doanh thành những quyết định mà bốn bước xử lý thực sự kiểm soát.
| Câu hỏi đánh giá | Câu trả lời cho biết điều gì |
|---|---|
| Bản ghi nào cần tham gia vào kết quả? | Có cần Data Filter hay không. |
| Giá trị nguồn đã đúng nhưng cần được đưa sang trường đích được hỗ trợ khác hay không? | Có cần Advanced Data Mapping hay không. |
| Yêu cầu có phụ thuộc vào trường hoặc cột cơ sở dữ liệu bên dưới, và cả hai nền tảng có phải Open Source hay không? | Có cần đánh giá Advanced Database Mapping hay không. |
| Sau khi mapping hoàn tất, bản thân giá trị đích có cần thay đổi hay không? | Có cần Data Transformation hay không. |
| Bằng chứng nào sẽ xác nhận giá trị, vị trí, quan hệ và ý nghĩa nghiệp vụ của kết quả đều đúng? | Nội dung nào phải được xác thực trước khi yêu cầu có thể được coi là hoàn thành. |
Ngôn ngữ trong yêu cầu thường cung cấp tín hiệu hữu ích. Các từ như include, exclude, only, condition thường mô tả việc lựa chọn bản ghi. Map, place, send, destination thường mô tả việc đưa dữ liệu sang trường đích. Các tham chiếu đến database columns, các trường đặc thù của nền tảng hoặc các trường tùy chỉnh có thể cần Advanced Database Mapping khi toàn bộ lộ trình và phạm vi hỗ trợ đủ điều kiện. Calculate, normalize, append, remove, convert hoặc restructure thường chỉ ra nhu cầu thay đổi giá trị.
Đây là các dấu hiệu để phân loại, không phải cơ chế phê duyệt tự động. Một trường có tên phù hợp vẫn có thể có kiểu dữ liệu không tương thích. Một trường tùy chỉnh có thể phù hợp với Standard mapping Add-on, trong khi trường tùy chỉnh khác phụ thuộc vào quy tắc xử lý chưa được hỗ trợ và cần Custom Service. Một lộ trình Open Source sang Open Source có thể đủ điều kiện kiến trúc cho Advanced Database Mapping nhưng cột cơ sở dữ liệu cụ thể vẫn nằm ngoài phạm vi hỗ trợ.
Vì vậy, một yêu cầu tốt nhất cần mô tả cùng lúc năm yếu tố: loại dữ liệu và bản ghi bị ảnh hưởng, giá trị nguồn, vị trí đích mong muốn, quy tắc giá trị cuối cùng nếu có và bằng chứng dùng để xác nhận kết quả. Khi các yếu tố này đã rõ, tổ hợp Add-on có thể được đánh giá theo giới hạn hỗ trợ thay vì được chọn chỉ vì tên tính năng nghe có vẻ liên quan.
Cách tiếp cận từ kết quả giúp tránh hai sai lầm đối lập: đẩy một yêu cầu vẫn được hỗ trợ sang Custom Service chỉ vì có nhiều thao tác, hoặc kéo Standard Add-on vượt quá chức năng được hỗ trợ chỉ vì tên Add-on có vẻ phù hợp với yêu cầu.
Kết luận
Next-Cart Add-ons hữu ích nhất khi được hiểu là các bước riêng trong một mô hình xử lý dữ liệu được hỗ trợ, thay vì một danh sách tính năng rời rạc. Data Filter chọn bản ghi, Advanced Data Mapping thay đổi trường đích được hỗ trợ, Advanced Database Mapping mở rộng mapping đến các trường và cột cơ sở dữ liệu đủ điều kiện khi cả Nền tảng nguồn và Nền tảng đích đều Open Source, còn Data Transformation thay đổi giá trị cuối cùng tại hệ thống đích.
Trình tự xử lý cố định là một phần của quyết định. Mỗi bước được áp dụng làm việc với kết quả đã được thiết lập trước đó, vì vậy yêu cầu kết hợp cần được thiết kế xoay quanh kết quả cuối cùng tại Cửa hàng đích và được xác thực như một quy trình phối hợp thống nhất.
Standard Add-ons vẫn là các chức năng được hỗ trợ với phạm vi rõ ràng. Khi chức năng cần được sửa đổi, mở rộng quy tắc xử lý, phát triển riêng hoặc xử lý dữ liệu chưa được hỗ trợ, yêu cầu sẽ chuyển sang Tailored Add-on, Custom Add-on hoặc phạm vi Custom Service rộng hơn thay vì kéo Standard capability vượt khỏi giới hạn được thiết kế.
Câu hỏi thường gặp
Làm sao biết doanh nghiệp cần một Add-on hay nhiều Add-ons?
Hãy tách yêu cầu thành bốn phần: lựa chọn bản ghi, trường đích, cách biểu diễn ở tầng cơ sở dữ liệu và thay đổi giá trị cuối cùng. Nếu kết quả kinh doanh chứa nhiều hơn một thao tác, nhiều Add-ons có thể phù hợp. Số lượng Add-ons không quan trọng bằng việc mỗi bước xử lý một phần riêng, được hỗ trợ của cùng một kết quả.
Có thể dùng nhiều Standard Add-ons trong cùng một lần chuyển đổi mà không cần Custom Service không?
Doanh nghiệp có thể kết hợp nhiều Standard Add-ons mà không tự động biến dự án thành trường hợp Custom Service. Mỗi thao tác phải nằm trong phạm vi Standard được hỗ trợ của Add-on tương ứng, các bước phải tạo thành một chiến lược xử lý nhất quán và kết quả kết hợp phải được xác thực theo mục tiêu kinh doanh đã xác định.
Thứ tự Add-ons có quan trọng khi sử dụng nhiều Add-ons cùng lúc không?
Thứ tự Add-ons có ý nghĩa trực tiếp đối với kết quả. Trình tự xử lý là Data Filter, Advanced Data Mapping, Advanced Database Mapping, sau đó Data Transformation. Mỗi bước được áp dụng làm việc với kết quả từ các bước trước, vì vậy các quy tắc chồng lấn cần được thiết kế như một chuỗi thống nhất.
Advanced Database Mapping có áp dụng khi chỉ Nền tảng đích là Open Source không?
Advanced Database Mapping không áp dụng nếu chỉ Nền tảng đích là Open Source. Cả Nền tảng nguồn và Nền tảng đích đều phải Open Source để Add-on này có thể áp dụng. Nếu một trong hai là Non-Open-Source, Add-on này không khả dụng.
Advanced Data Mapping khác Data Transformation như thế nào?
Advanced Data Mapping thay đổi trường đích tương thích nhận một trường nguồn được hỗ trợ mà không thay đổi giá trị trong thao tác mapping. Data Transformation thay đổi chính giá trị ở trường đích được chọn. Khi sử dụng cả hai, mapping xác định giá trị sẽ nằm ở đâu trước khi transformation áp dụng quy tắc thay đổi giá trị cuối cùng.
Hai mapping Add-ons có thể cùng tác động đến một vị trí đích không?
Có thể cùng tham gia một yêu cầu hội tụ về một vị trí đích, nhưng các quy tắc phải được thiết kế như một chuỗi thống nhất chứ không phải hai mapping độc lập. Advanced Database Mapping chạy sau Advanced Data Mapping, nên giá trị do bước mapping áp dụng sau cùng thiết lập là giá trị được chuyển tiếp sang Data Transformation.
trường tùy chỉnh hoặc database column có thể vẫn phù hợp với Standard Add-on không?
Có thể. trường tùy chỉnh hoặc database column cần được đánh giá trước theo phạm vi được hỗ trợ của Advanced Data Mapping hoặc Advanced Database Mapping. Từ custom không tự động đồng nghĩa với Custom Service, nhưng chức năng chưa nằm trong phạm vi được hỗ trợ hoặc yêu cầu phát triển riêng vẫn cần được xem xét thêm.
Advanced Data Mapping và Advanced Database Mapping có hỗ trợ dữ liệu Tax không?
Cả hai Add-ons dùng cho mapping đều không hỗ trợ dữ liệu Tax trong phạm vi Standard: Advanced Data Mapping và Advanced Database Mapping.
Add-ons có thay đổi cách tính Entity Points không?
Add-ons không thay đổi cách tính Entity Points. Entity Points vẫn được tính theo mô hình Products, Customers, Orders và Blog Posts. Add-ons ảnh hưởng đến cách xử lý dữ liệu được hỗ trợ và chi phí riêng, không thay đổi dung lượng Entity Points.
Khi nào yêu cầu Add-on nên chuyển sang Custom Service?
Custom Service phù hợp khi yêu cầu vượt quá phạm vi của quá trình chuyển đổi Standard và phạm vi xử lý được hỗ trợ của Add-ons, bao gồm Tailored Add-on, Custom Add-on hoặc quy tắc xử lý dữ liệu riêng/chưa được hỗ trợ. Yếu tố quyết định là giới hạn được hỗ trợ, không phải chỉ vì dự án dùng nhiều Add-ons, có trường tùy chỉnh hoặc có database column.