NocoDB thay excel Quản lý kho, Mã QR, API REST

Hệ thống quản lý kho đơn giản với trình tạo mã QR. NocoDB tự động tạo mã QR. NocoDB cung cấp sẵn API REST. Hướng dẫn sau đây giúp bạn hoàn thành các chức năng trên trong vòng 10 phút.

Địa chỉ truy cập là //www.nocodb.com/.

NocoDB là một dự án mã nguồn mở. Bạn có thể tìm thấy nhiều lựa chọn nền tảng tại đây. Đây là dự án mã nguồn mở. Do đó, về mặt kỹ thuật, không có chi phí sử dụng phần mềm. Tuy nhiên, bạn sẽ phải trả chi phí cho cơ sở hạ tầng, cụ thể là chi phí lưu trữ máy chủ.

NocoDB đóng vai trò là backend.

Retool đóng vai trò là frontend cho ứng dụng di động.

Bắt đầu

Cấu hình các bảng

1. Bắt đầu bằng cách tạo một dự án mới. Chúng ta sẽ đặt tên dự án là “Inventory System” (Hệ thống quản lý kho).
2. Tiếp theo, tạo một bảng trong dự án này. Đặt tên bảng là “products” (sản phẩm).
3. Sau đó, tạo các trường cần thiết cho bảng “products”. Các trường này dựa trên yêu cầu cụ thể.
   
4. Để tạo mã QR, chúng ta sử dụng ID hàng (Row ID) làm dữ liệu mã QR. Hiện tại, trường mã QR của NocoDB không thể trực tiếp tham chiếu đến Row ID. Do đó, chúng ta phải tạo một cột loại công thức (Formula column type). Cột này sẽ phản ánh Row ID.Đặt tên cột này là “QR Code String”.Công thức để phản ánh Row ID trong NocoDB là {Id}.
5. Bây giờ, chúng ta có thể tạo một cột mã QR. Đảm bảo giá trị của mã QR tham chiếu đến cột vừa tạo, tức là “QR Code String”.

Sau khi hoàn tất cấu hình bảng, hãy tải một số dữ liệu mẫu. Sau khi tải dữ liệu mẫu, bạn sẽ thấy “QR Code String” và “QR Code” được tự động tạo. Đây là một tính năng tiện lợi.

Cấu hình API REST

1. Bây giờ, chúng ta cần thiết lập API REST cho ứng dụng di động sau này. Bắt đầu bằng cách tạo token truy cập.Trong dự án này, nhấp vào “Team & Auth” (Nhóm & Xác thực). Sau đó, chọn “API Tokens Management” (Quản lý Token API). Nhấp vào nút “Add New Token” (Thêm Token mới).
2. NocoDB đi kèm với Swagger. Swagger là một công cụ hữu ích để kiểm tra API REST một cách dễ dàng. Nhấp vào “API & Support” (API & Hỗ trợ) ở phía dưới bên trái. Sau đó, chọn “Swagger Documentation” (Tài liệu Swagger).
3. Khi chuyển sang trang Swagger, bạn sẽ thấy API REST cho bảng “products” đã được tự động tạo. Điều này rất thuận tiện.
4. Để thử nghiệm, chúng ta cần cấp quyền trước. Nhấp vào nút “Authorize” (Cấp quyền) ở phía trên bên phải. Đặt khóa token truy cập đã tạo vào trường xcToken (apiKey). Sau đó, nhấp lại vào nút “Authorize”.
5. Đối với dự án này, chúng ta chỉ cần một API REST cụ thể. Đó là API để lấy chi tiết sản phẩm theo Row ID. Do đó, chúng ta sẽ chọn API REST này để thử nghiệm.Để kiểm tra API REST, hãy truy cập điểm cuối API REST cụ thể này. Mở rộng nó. Bạn sẽ thấy nút “Try it out” (Thử ngay). Nhập Row ID vào ô văn bản bên dưới. Sau đó, nhấp vào nút “Try it out”.
6. Nếu Row ID bạn nhập hợp lệ, bạn sẽ nhận được phản hồi thành công từ API REST. Phản hồi này sẽ trả về thông tin sản phẩm.
7. Bạn vừa tạo một cơ sở dữ liệu với các chức năng sau:
   • Tự động tạo mã QR.
   • API REST có sẵn để trả về thông tin sản phẩm theo Row ID.

   Cơ sở dữ liệu đã sẵn sàng để ứng dụng di động kích hoạt. Hãy theo dõi chương tiếp theo về tích hợp ứng dụng di động với NocoDB.

Chúng tôi đã xây dựng phần (backend) của hệ thống quản lý kho hàng bằng cách sử dụng một số công cụ low-code / no-code. Bây giờ là lúc để xây dựng một ứng dụng di động đơn giản cho giao diện người dùng (frontend) để tận dụng những gì đã học.

Trong trường hợp sử dụng Hệ thống Quản lý Kho hàng này:

• Phần phụ trợ (Backend): Lưu trữ dữ liệu kho hàng. Bao gồm tạo mã QR và cung cấp API REST để truy vấn dữ liệu kho hàng cụ thể.
• Giao diện người dùng (Frontend): Một ứng dụng di động dành cho nhân viên bán hàng. Ứng dụng này sẽ quét nhanh mã QR, kích hoạt API REST của backend và hiển thị dữ liệu kho hàng trên ứng dụng di động.

Trong ví dụ này, chúng tôi sẽ sử dụng Retool làm giao diện người dùng ứng dụng di động và NocoDB làm cơ sở dữ liệu.

URL sản phẩm di động của Retool là //retool.com/products/mobile.

Retool Mobile vẫn đang trong giai đoạn beta. Tuy nhiên, nhờ giao diện người dùng xuất sắc và khả năng xây dựng ứng dụng di động low-code gần như “dễ như ăn kẹo”, sẽ là một thiếu sót lớn nếu không đưa công cụ này vào danh sách các công cụ low-code dành cho ứng dụng di động.

Bắt đầu

Tạo ứng dụng di động

1. Hãy bắt đầu bằng cách tạo một ứng dụng di động. Chúng tôi gọi nó là “Inventory Scanner” (Máy quét kho hàng). Mục tiêu chính của ứng dụng di động này là quét mã QR.
2. Theo mặc định, Retool sẽ tạo một số mẫu màn hình mặc định. Trong trường hợp này, chúng tôi chỉ cần một màn hình. Do đó, hãy xóa các màn hình còn lại.
3. Hãy bắt đầu bằng cách thêm thành phần đầu tiên, nhãn chào mừng. Với tư cách là một nhà phát triển “lão làng” từ thời Visual Basic 6, tôi thích đặt tên các thành phần một cách phù hợp để tránh nhầm lẫn sau này. Tôi đặt tên nó là “text_greeting” và đặt giá trị là “Hi, please start to scan something” (Chào bạn, hãy bắt đầu quét một thứ gì đó).
4. Đối với đối tượng thứ hai, đó là đối tượng máy quét, được thể hiện bằng một nút. Khi người dùng nhấp vào nút này, ứng dụng sẽ gọi camera của điện thoại để hoạt động như một máy quét. Tôi đặt tên nó là “scanner_button” và đặt nhãn là “Scan” (Quét).
5. Đối tượng thứ ba, chúng tôi sẽ sử dụng đối tượng KeyValue để hiển thị thông tin kho hàng. Tôi đặt tên nó là “KeyValue_data”. Đối với thuộc tính Data, chúng tôi sẽ cần liên kết nó với một nguồn dữ liệu sau này.
6. Cuối cùng, hãy tạo nhãn văn bản cuối cùng. Tôi gọi nó là “text_firstscan_flag” và đặt nó ở trạng thái ẩn, với giá trị mặc định là “0”. Bạn có thể tự hỏi mục đích của cờ này là gì. Tôi sẽ giải thích ngay bây giờ.
   • Vấn đề: Tôi không chắc tại sao, nhưng ngay khi màn hình khởi chạy, API REST sẽ được kích hoạt và gây ra thông báo lỗi. Điều này xảy ra vì chưa có gì được quét khi ứng dụng vừa khởi chạy.
   • Giải pháp tạm thời: Sử dụng một cờ để cho ứng dụng biết đây là lần khởi chạy đầu tiên. Đừng hiển thị bất kỳ thông báo lỗi nào ngay lập tức.
   • Câu hỏi: Tại sao tôi không sử dụng trạng thái tạm thời của Retool? Thật không may, nó không hoạt động tốt trong trường hợp của tôi. Điều này khá lạ, có thể là do giai đoạn beta.
7. Có một đối tượng truy vấn mặc định được tạo. Tôi đặt tên nó là “query_api” và chuyển “Resource” (Tài nguyên) thành “RESTQuery (restapi)”. Dưới đây là những gì tôi cấu hình cài đặt API REST cho thử nghiệm ban đầu:
   • Action endpoint: Điểm cuối NocoDB, với một ID hàng hợp lệ phía sau.
   • Headers’ parameters: “xc-token” và đặt “accept” thành “application/json”. Điều này giúp tôi nhận dữ liệu trả về ở định dạng JSON.

   Nếu bạn không nhớ cách lấy các cài đặt này, vui lòng truy cập bài viết trước.

8. Bây giờ, đối với đối tượng KeyValue mà chúng tôi đã tạo ở bước 5, hãy đặt nguồn dữ liệu của nó thành “query_api”. Kết quả trả về từ API REST này sẽ được ánh xạ và hiển thị trên đối tượng KeyValue.
9. Khi bạn đã sẵn sàng, hãy nhấp vào nút “Save & Run” (Lưu & Chạy). Vì chúng tôi đã nhập ID hàng hợp lệ vào điểm cuối, nó sẽ hoạt động tốt và hiển thị kết quả trên đối tượng “KeyValue_data”.
10. Bạn sẽ thấy dưới phần Items (Mục), tất cả các mục từ kết quả được hiển thị. Bạn có thể ẩn một số trong số chúng, vì không phải tất cả đều cần hiển thị trên ứng dụng di động.
11. Bây giờ, hãy chạy lại truy vấn. Lần này, hãy thay thế ID hàng hợp lệ của điểm cuối bằng tham số sau: {{scanner_button.data[0]}}. Có hai mục đích khi làm điều này:
    • Thứ nhất: Để API REST trả về lỗi (vì không tìm thấy sản phẩm) tạm thời. Bạn có thể thấy lỗi cũng được ánh xạ tới đối tượng KeyValue_data. Tại thời điểm này, chỉ cần ẩn tất cả các mục lỗi. Loại lỗi này không thân thiện và sẽ khiến người dùng hoảng sợ, điều này sẽ gây ra nhiều vấn đề hơn cho bạn sau này.
    • Thứ hai: Mã này chỉ ra rằng dữ liệu được lấy từ máy quét mã QR. Chúng tôi truyền dữ liệu này như một phần của tham số trên URL.
12. Bây giờ, chúng tôi đã thiết lập nguồn dữ liệu và đảm bảo rằng nó hoạt động với trường hợp thành công và trường hợp lỗi. Tại thời điểm này, đã đến lúc đưa “text_firstscan_flag” vào sử dụng thực tế. Logic rất đơn giản:
    • Nếu “text_firstscan_flag” là “0”: Đây là lần đầu tiên ứng dụng khởi chạy. Do đó, bất kỳ lỗi API REST nào cũng là báo động giả.
    • Nếu “text_firstscan_flag” là “1”: Bất kỳ lỗi nào vào thời điểm này đều là lỗi thật. Vui lòng hiển thị thông báo để thông báo cho người dùng.

    Dưới đối tượng truy vấn, có hai trình xử lý sự kiện: Success (Thành công) và Failure (Thất bại). Chúng tôi sẽ tận dụng chúng để kiểm soát “text_firstscan_flag”.

    Dưới trình xử lý Success:

    • Ứng dụng di động đã quét lần đầu tiên và trả về dữ liệu thành công. Chúng ta có thể đặt “text_firstscan_flag” thành “1”.
    • Sau khi “text_firstscan_flag” được đặt thành “1”, bất kỳ lỗi API REST nào cũng là lỗi thực tế.
13. Đối với trình xử lý Failure, chúng ta cần đặt hai hành động: hiển thị thông báo lỗi và cài đặt cờ. Vui lòng lưu ý trình tự của hai hành động này: thông báo lỗi hiển thị trước, sau đó là cài đặt cờ.Hãy xem xét thông báo lỗi hiển thị:
    • Action được đặt thành “Alert”. Điều này tương tự như lệnh alert trong JavaScript.
    • Title được đặt thành “Error” (Lỗi). Bạn có thể nhập bất kỳ tiêu đề nào bạn thích.
    • Description được đặt thành “Invalid product” (Sản phẩm không hợp lệ). Không có gì phức tạp nhưng tốt hơn là lỗi API REST đáng sợ.
    • Đối với “Actions”, đó thực chất là các nút. Chúng ta chỉ cần một nút “OK”. Do đó, tôi đã xóa nút “Cancel”.
    • Đối với “Only run when” (Chỉ chạy khi), đây là phần thú vị. Thông báo chỉ hiển thị khi “text_firstscan_flag” là “1”. Điều này có nghĩa là nếu “text_firstscan_flag” là “0”, ứng dụng di động sẽ không hiển thị lỗi vì đó là báo động giả. Mã rất đơn giản: {{text_firstscan_flag.value === "1"}}.
14. Hành động thứ hai cho xử lý lỗi là đặt “text_firstscan_flag” thành “1”. Lý do là, trong lần báo động giả đầu tiên, trình xử lý sự kiện Failure sẽ được kích hoạt. Do đó, chúng ta phải đặt “text_firstscan_flag” thành “1” để chỉ ra rằng: báo động giả đã kết thúc, lỗi tiếp theo sẽ là lỗi thật.
15. Khi màn hình được tải, luôn là một thực hành tốt để đặt “text_firstscan_flag” thành “0”. Trong thuật ngữ lập trình, chúng ta gọi đây là “khởi tạo” biến.
16. Chúng ta đã đi một chặng đường dài với API REST và cài đặt cờ. Đây là cách thiết lập API REST cuối cùng sẽ trông như thế nào.

Kiểm tra ứng dụng di động

1. Để chạy ứng dụng di động bằng Retool, bạn cần tải xuống ứng dụng di động Retool. Ứng dụng này có sẵn trên iOS AppStore và Google Playstore.
2. Khi đăng nhập vào ứng dụng di động Retool, bạn sẽ thấy ứng dụng di động mà bạn vừa tạo.
3. Đây sẽ là màn hình đầu tiên của ứng dụng của bạn, mà chúng tôi vừa xây dựng.
4. Hãy quét một thứ gì đó, bắt đầu với một ID hàng hợp lệ. Chúng ta có thể đăng nhập vào NocoDB để quét một số mã QR.
5. Nếu bạn đang quét ID hàng hợp lệ, bạn sẽ thấy một cái gì đó như dưới đây.
6. Hãy thử một mã QR không hợp lệ. Chúng ta có thể tạo một số mã QR bằng cách sử dụng Trình tạo mã QR. Có rất nhiều công cụ trực tuyến miễn phí. Tôi đang sử dụng công cụ này.
7. Vì đây là một mã QR không hợp lệ và sẽ không trả về bất kỳ sản phẩm nào, do đó bạn sẽ thấy như dưới đây.
8. Chúng ta thực sự vừa hoàn thành một Hệ thống Quản lý Kho hàng đơn giản cho phần phụ trợ và giao diện người dùng ứng dụng di động với low-code! Thật tuyệt vời phải không?

Các chức năng chúng ta đã hoàn thành là:

• Lưu trữ thông tin kho hàng.
• Tạo mã QR tự động.
• Thiết lập API REST từ phần phụ trợ.
• Tạo một ứng dụng di động cho nhân viên bán hàng để quét và lấy thông tin qua API REST.

Ứng dụng di động được xây dựng bằng Retool yêu cầu ứng dụng di động Retool để chạy như một máy chủ. Nó chưa phù hợp để xây dựng một ứng dụng di động cho công chúng và xuất bản trên iOS AppStore hoặc Google Playstore, ít nhất là chưa. Trong mọi trường hợp, nó vẫn là một công cụ nội bộ tuyệt vời và là một trong những trình xây dựng ứng dụng di động low-code dễ nhất mà tôi từng thử.

Vui lòng lưu ý, tại thời điểm này (khi bài viết này được xuất bản), ứng dụng di động Retool vẫn đang trong giai đoạn beta.

Nguồn: NocoDB: Simple Inventory Management System with QR Code generator

Mobile App for Inventory Management System with Low Code