Tôi đã làm việc với Oracle EBS hơn 18 năm, trải qua quá trình phát triển hoàn chỉnh từ 11i đến R12. Trong suốt sự nghiệp dài này, phát triển báo cáo tùy chỉnh luôn là một trách nhiệm cốt lõi không thể tránh khỏi. Xung quanh công việc này, một số vấn đề xuất hiện năm này qua năm khác mà chưa bao giờ được giải quyết một cách căn bản.
Tôi đã làm việc với Oracle EBS hơn 18 năm, trải qua quá trình phát triển hoàn chỉnh từ 11i đến R12. Trong suốt sự nghiệp dài này, phát triển báo cáo tùy chỉnh luôn là một trách nhiệm cốt lõi không thể tránh khỏi. Xung quanh công việc này, một số vấn đề xuất hiện năm này qua năm khác mà chưa bao giờ được giải quyết một cách căn bản.
Bài viết này không nhằm mục đích kể một câu chuyện. Nó chỉ đơn giản nhằm ghi lại một cách trung thực những vấn đề tôi đã quan sát và trải nghiệm qua nhiều năm, cùng với những nỗ lực tôi đã thực hiện để giải quyết chúng. Tôi hy vọng nó có thể là tài liệu tham khảo cho các đồng nghiệp đang đối mặt với những thách thức tương tự.
Trong hệ sinh thái EBS, có một quy trình cố định giữa lúc hoàn thành việc viết SQL và thời điểm báo cáo có thể được người dùng cuối thực thi. Quy trình này là hợp lý và cần thiết trong khuôn khổ thiết kế của EBS—nó đảm bảo tính bảo mật, cách ly đa tổ chức, xác thực tham số và lập lịch yêu cầu. Tuy nhiên, từ góc độ hiệu quả phát triển, chi phí của nó thực sự cao.
Cụ thể, sau khi hoàn thành việc viết và kiểm thử SQL, các nhà phát triển phải thực hiện tuần tự các thao tác sau:
Các bước này không liên quan đến logic nghiệp vụ phức tạp—chúng đơn thuần là các tác vụ cấu hình. Nhưng đối với một báo cáo đơn giản, có thể chỉ sử dụng một lần, chi phí khởi động của quy trình này là quá cao. Một báo cáo mà SQL chỉ mất 20 phút để viết thường cần hơn một giờ để hoàn thành toàn bộ quy trình, phần lớn thời gian bị tiêu tốn vào việc điều hướng menu, điền trường và chờ phản hồi trang.
Quan trọng hơn, nếu báo cáo cần điều chỉnh logic SQL hoặc định nghĩa tham số sau khi kiểm thử, một phần đáng kể của các bước trên phải được lặp lại. Điều này đại diện cho một nút thắt cổ chai đáng kể đối với các kịch bản phát triển yêu cầu lặp lại nhanh.
Đây là vấn đề tôi coi là cốt lõi nhất và ảnh hưởng nhiều nhất đến trải nghiệm người dùng.
Định dạng đầu ra gốc của Chương trình đồng thời EBS là một tệp văn bản (thường là .out hoặc .txt). Dù là báo cáo .rdf được phát triển với Report Builder hay đầu ra từ một thủ tục lưu trữ PL/SQL, những gì cuối cùng được giao cho người dùng về bản chất là một tệp văn bản có độ rộng cố định hoặc được phân tách bằng dấu phân cách.
Tuy nhiên, những gì người dùng nghiệp vụ thực sự cần trong công việc hàng ngày của họ, gần như không có ngoại lệ, là các tệp dữ liệu ở định dạng Excel. Điều này tạo ra một "bước trung gian" tồn tại từ lâu: người dùng phải sao chép và dán nội dung của tệp văn bản vào Excel, sau đó sử dụng chức năng "Chia cột" để tách nó thành nhiều cột.
Bước này liên quan đến một số vấn đề kỹ thuật cụ thể:
Thứ nhất, vấn đề độ rộng trường. Nhà phát triển báo cáo phải xác định trước độ rộng hiển thị cho mỗi trường đầu ra. Nếu độ dài dữ liệu thực tế của một trường vượt quá độ rộng được xác định trước này (ví dụ: các trường văn bản tự do như mô tả vật tư hoặc tên nhà cung cấp), EBS xử lý bằng cách tự động xuống dòng, chèn một ký tự xuống dòng vào tệp văn bản. Ký tự xuống dòng này trông bình thường trong trình xem văn bản—nội dung chỉ được hiển thị trên một dòng mới. Nhưng khi người dùng sao chép toàn bộ văn bản vào Excel và thực hiện Chia cột, Excel nhận diện ký tự xuống dòng này làm dấu kết thúc dòng, khiến một bản ghi duy nhất bị chia tách không chính xác thành hai hoặc nhiều dòng. Sự căn chỉnh cột của tất cả các bản ghi tiếp theo bị phá vỡ hoàn toàn. Người dùng phải tự định vị và sửa các lỗi này, hoặc điều chỉnh lại độ rộng trường báo cáo và gửi lại yêu cầu.
Thứ hai, vấn đề mã hóa ký tự. Định dạng mã hóa mặc định của tệp văn bản thường không khớp với mã hóa mặc định của Excel khi mở tệp. Điều này đặc biệt có vấn đề khi xử lý các ký tự đa byte như tiếng Trung hoặc tiếng Nhật, thường dẫn đến văn bản bị lỗi hiển thị. Người dùng phải chọn thủ công mã hóa chính xác khi mở tệp văn bản, hoặc chỉ định định dạng mã hóa khi nhập vào Excel. Đối với người dùng nghiệp vụ không có nền tảng kỹ thuật, đây là một gánh nặng bổ sung và không cần thiết.
Thứ ba, xử lý định dạng số và ngày tháng. Các số và ngày tháng được xuất trong tệp văn bản thường ở định dạng văn bản thuần. Sau khi dán vào Excel, người dùng phải thiết lập thủ công định dạng ô trước khi có thể thực hiện các phép tính như tổng hoặc trung bình. Khi liên quan đến dấu phân cách hàng nghìn, độ chính xác thập phân hoặc định dạng hiển thị ngày tháng, cần thêm các bước điều chỉnh thủ công.
Thứ tư, hiệu quả xử lý với khối lượng dữ liệu lớn. Khi báo cáo trả về khối lượng dữ liệu lớn (ví dụ: trên 10.000 dòng), thao tác sao chép-dán cộng với chia cột thủ công trở nên rất tốn thời gian. Hơn nữa, hiệu suất của Excel khi dán lượng lớn văn bản không phải lúc nào cũng ổn định, thường gây ra tình trạng giật lag hoặc không phản hồi.
Những vấn đề này phổ biến ở cả báo cáo chuẩn của EBS và báo cáo tùy chỉnh. Nói một cách chính xác, đây không phải là một "lỗi"—đó là một lựa chọn thiết kế từ thời kỳ EBS ra đời, khi đầu ra văn bản là phương thức chủ đạo để trao đổi dữ liệu đa nền tảng. Nhưng trong môi trường kinh doanh ngày nay, lựa chọn thiết kế này đã lạc hậu so với các kịch bản sử dụng thực tế của người dùng.
Các bộ phận nghiệp vụ thường phát sinh các nhu cầu phân tích dữ liệu không theo chu kỳ trong hoạt động hàng ngày của họ. Ví dụ:
Đặc điểm của các yêu cầu này là: logic SQL tương đối rõ ràng, phạm vi dữ liệu giới hạn, yêu cầu về tính kịp thời cao và khả năng cao chỉ được sử dụng một lần mà không lặp lại.
Theo con đường phát triển chuẩn của EBS, ngay cả một báo cáo tạm thời sử dụng một lần cũng phải trải qua quy trình đăng ký đầy đủ từ việc định nghĩa một Tệp thực thi đến gắn vào Nhóm yêu cầu. Điều này có nghĩa là các nhà phát triển phải lặp lại các tác vụ cấu hình không liên quan đến logic nghiệp vụ mỗi khi đáp ứng các yêu cầu tạm thời như vậy.
Một cách giải quyết phổ biến khác là các nhà phát triển thực thi SQL trực tiếp trong các công cụ cơ sở dữ liệu (như PL/SQL Developer hoặc Toad), sao chép kết quả và gửi cho người dùng trong Excel. Cách tiếp cận này bỏ qua quy trình đăng ký của EBS và nhanh hơn đáng kể, nhưng nó lách qua cơ chế kiểm soát truy cập đa tổ chức và phân quyền dữ liệu của EBS, tạo ra rủi ro bảo mật dữ liệu tiềm ẩn. Nó cũng không thể tận dụng Trình quản lý đồng thời để lập lịch và ghi nhật ký thống nhất.
Những vấn đề được mô tả ở trên không phải là mới. Trên thực tế, trong cộng đồng người dùng EBS và giới thực hành, những khó khăn này từ lâu đã là một bí mật công khai. Tuy nhiên, trong nhiều năm, các giải pháp trong ngành chủ yếu tập trung vào các cách tiếp cận sau, tất cả đều có hiệu quả hạn chế:
Không có cách tiếp cận nào thay đổi được mô hình phát triển báo cáo EBS một cách cơ bản. Các nhà phát triển vẫn cần đầu tư công sức ở cả hai cấp độ viết SQL và cấu hình hệ thống, và người dùng vẫn cần tốn thêm thời gian cho cả việc thu thập và làm sạch dữ liệu.
Dựa trên các vấn đề trên, tôi đã thử xây dựng một lớp công cụ báo cáo độc lập, đặt tên là SQLVantage. Vị trí của nó không phải là thay thế Trình quản lý đồng thời của EBS, mà là phục vụ như một lớp phản hồi nhanh bổ sung, bao phủ các kịch bản sau:
Triết lý thiết kế cốt lõi của công cụ này là: loại bỏ các công việc quy trình tốn thời gian nhất nhưng không liên quan đến logic nghiệp vụ trong phát triển báo cáo EBS, cho phép các nhà phát triển tập trung trực tiếp vào hai yếu tố cốt lõi—SQL và cấu hình tham số.
Cách tiếp cận cụ thể như sau:
Về phía phát triển, nhà phát triển chỉ cần điền tên báo cáo, viết câu lệnh SQL và định nghĩa các tham số truy vấn (tên tham số, loại dữ liệu, nhãn hiển thị, giá trị mặc định) trong công cụ. Sau khi lưu, báo cáo sẵn sàng để sử dụng ngay lập tức. Không cần định nghĩa Tệp thực thi, đăng ký Chương trình đồng thời, cấu hình Tập giá trị hay gắn Nhóm yêu cầu. Toàn bộ quá trình cấu hình có thể hoàn thành trong vòng 3 đến 5 phút.
Về mặt bảo mật dữ liệu, công cụ tái sử dụng cơ chế xác thực người dùng của EBS, đảm bảo chỉ những người dùng có trách nhiệm EBS phù hợp mới có thể truy cập và chạy báo cáo. Logic Kiểm soát truy cập đa tổ chức (MOAC) liên quan đến các truy vấn SQL vẫn nằm trong các câu lệnh SQL, do nhà phát triển kiểm soát theo yêu cầu nghiệp vụ thực tế.
Về mặt định dạng đầu ra, công cụ tạo trực tiếp các tệp Excel .xlsx. Mỗi trường kết quả truy vấn tương ứng với một cột Excel và mỗi dòng dữ liệu tương ứng với một dòng Excel. Độ rộng trường tự động thích ứng với nội dung và nội dung văn bản dài không gây ra ngắt dòng làm hỏng dữ liệu. Các loại dữ liệu như số, ngày tháng giữ nguyên thuộc tính loại dữ liệu gốc khi xuất, cho phép người dùng sắp xếp, lọc và thực hiện các phép tính ngay sau khi mở tệp Excel.
Về mặt mở rộng, ngoài Excel, công cụ còn hỗ trợ xuất định dạng JSON, tạo điều kiện tích hợp với các nền tảng dữ liệu bên ngoài hoặc hệ thống BI.
Sau một thời gian sử dụng nội bộ, công cụ này đã mang lại những cải thiện về hiệu quả trong các lĩnh vực sau:
Đồng thời, tôi cũng cần chỉ ra những hạn chế của công cụ này:
Trong 18 năm qua, EBS là một nền tảng ứng dụng cấp doanh nghiệp có tính ổn định và chặt chẽ về kiến trúc cốt lõi không thể bàn cãi. Nhưng chính vì sự ổn định này, một số lựa chọn thiết kế đã từng hợp lý vào thời của chúng lại trở nên chậm chạp và nặng nề trong các kịch bản sử dụng ngày nay.
Chi phí quy trình phát triển báo cáo, định dạng đầu ra dựa trên văn bản, con đường phản hồi cho các nhu cầu tạm thời—những vấn đề này không phải chỉ mới xuất hiện ngày hôm nay. Chỉ là trong môi trường ngày nay, chi phí của chúng đã trở nên rõ ràng hơn. Nhịp độ kinh doanh đang tăng tốc, yêu cầu của doanh nghiệp về khả năng đáp ứng dữ liệu đang tăng lên và các công cụ và quy trình chúng ta sử dụng vẫn bị kẹt lại ở một thời đại đã qua.
SQLVantage là một nỗ lực tôi đã thực hiện dựa trên những vấn đề này. Nó không thực sự là một sự đổi mới, mà là một sự đơn giản hóa và tái tổ chức các quy trình hiện có. Nếu bài viết này có thể gây được tiếng vang với một số đồng nghiệp hoặc cung cấp một góc nhìn tham khảo cho những người đang suy nghĩ về các vấn đề tương tự, thì nó đã đạt được mục đích của mình.
Viết đến đây, tôi không có ý định đóng gói nó như một "câu chuyện thành công". Nó chỉ đơn giản là một người đã bị những vấn đề cụ thể trong những kịch bản công việc cụ thể quấy nhiễu lặp đi lặp lại, cố gắng cải thiện những vấn đề đó theo cách riêng của mình. Con đường này có thể đi được bao xa, vẫn cần được kiểm nghiệm liên tục trong thực tiễn. Nhưng ít nhất, hướng đi là đúng—để các nhà phát triển trở lại với SQL, để người dùng trở lại với dữ liệu và để công cụ xử lý những thứ không cần thiết ở giữa.