I have been working with Oracle EBS for over 18 years, having experienced the full evolution from 11i to R12. Throughout this long career, custom report development has always been a core responsibility that cannot be avoided. Around this work, certain issues have emerged year after year without ever being fundamentally resolved.
I have been working with Oracle EBS for over 18 years, having experienced the full evolution from 11i to R12. Throughout this long career, custom report development has always been a core responsibility that cannot be avoided. Around this work, certain issues have emerged year after year without ever being fundamentally resolved.
This article is not meant to tell a story. It simply aims to honestly document the problems I have observed and experienced over the years, along with the attempts I have made to address them. I hope it can serve as a reference for fellow practitioners facing similar challenges.
In the EBS ecosystem, there is a fixed set of procedures between the completion of SQL writing and the moment a report becomes executable by end users. This process is reasonable and necessary within EBS's design framework—it ensures security, multi-organization isolation, parameter validation, and request scheduling. However, from a development efficiency perspective, its cost is indeed high.
Specifically, after developers complete SQL writing and testing, they must sequentially perform the following operations:
These steps do not involve complex business logic—they are purely configuration tasks. But for a simple, possibly one-time ad hoc report, the startup cost of this process is excessively high. A report whose SQL might take only 20 minutes to write often requires over an hour to go through the entire process, with most of the time consumed by menu navigation, field filling, and waiting for page responses.
More critically, if the report requires adjustments to SQL logic or parameter definitions after testing, a considerable portion of the above steps must be repeated. This represents a significant efficiency bottleneck for development scenarios that require rapid iteration.
This is what I consider to be the core issue, and the one that most impacts user experience.
The native output format of EBS Concurrent Programs is a text file (typically .out or .txt). Whether it is an .rdf report developed with Report Builder or the output from a PL/SQL stored procedure, what is ultimately delivered to users is essentially a fixed-width or delimiter-separated text file.
However, what business users actually need in their daily work is, almost without exception, data files in Excel format. This creates a long-standing "middle step": users must copy and paste the content of the text file into Excel, then use the "Text to Columns" function to split it into multiple columns.
This step involves several specific technical problems:
First, field width issues. Report developers must pre-specify a display width for each output field. If the actual data length of a field exceeds this preset width (for example, free-text fields like item descriptions or supplier names), EBS handles it by automatically wrapping the line, inserting a line break character into the text file. This line break appears normal in a text viewer—the content is simply displayed on a new line. But when users copy the entire text into Excel and perform Text to Columns, Excel recognizes this line break as a row terminator, causing a single record to be incorrectly split into two or more rows. The column alignment of all subsequent records becomes completely corrupted. Users must manually locate and fix these errors, or re-adjust the report field widths and resubmit the request.
Second, character encoding issues. The default encoding format of the text file often does not match Excel's default encoding for opening files. This is especially problematic when handling multi-byte characters such as Chinese or Japanese, frequently resulting in garbled text. Users must manually select the correct encoding when opening the text file, or specify the encoding format during Excel import. For non-technical business users, this is an additional and unnecessary burden.
Third, handling of number and date formats. Numbers and dates exported in text files are typically in plain text format. After pasting into Excel, users must manually set cell formats before they can perform calculations such as summation or averaging. When thousand separators, decimal precision, or date display formats are involved, additional manual adjustment steps are required.
Fourth, processing efficiency with large datasets. When a report returns a large volume of data (for example, over 10,000 rows), the copy-paste plus manual column-splitting operation itself becomes very time-consuming. Moreover, Excel's performance when pasting large amounts of text is not always stable, often resulting in lag or unresponsiveness.
These issues are prevalent in both EBS standard reports and custom reports. Strictly speaking, this is not a "bug"—it is a design choice from the era when EBS was created, when text output was the mainstream method for cross-platform data exchange. But when viewed in today's business environment, this design choice is severely disconnected from users' actual usage scenarios.
Business departments frequently generate non-periodic data analysis needs in their daily operations. For example:
The characteristics of such requirements are: relatively clear SQL logic, limited data scope, high timeliness requirements, and a high likelihood of being used only once without recurring.
Under EBS's standard development path, even a one-time ad hoc report must go through the complete registration process from defining an Executable to mounting it to a Request Group. This means that developers must repeat configuration tasks unrelated to business logic every time they respond to such ad hoc requests.
Another common workaround is for developers to execute SQL directly in database tools (such as PL/SQL Developer or Toad), copy the results, and send them to users in Excel. This approach bypasses EBS's registration process and is significantly faster, but it circumvents EBS's multi-organization access control and data permission validation, introducing potential data security risks. It also cannot leverage the Concurrent Manager for unified scheduling and logging.
The issues described above are not new. In fact, within the EBS user community and practitioner circles, these pain points have long been an open secret. However, over the years, industry solutions have mainly focused on the following approaches, all with limited effectiveness:
None of these approaches fundamentally change the EBS report development model. Developers still need to invest effort at both the SQL writing and system configuration levels, and users still need to expend extra time on both data acquisition and data cleansing.
Based on the above issues, I attempted to build an independent reporting tool layer, named SQLVantage. Its positioning is not to replace EBS's Concurrent Manager, but rather to serve as a complementary rapid-response layer covering the following scenarios:
The core design philosophy of this tool is: strip away the most time-consuming, business-logic-unrelated procedural work in EBS report development, allowing developers to focus directly on the two core elements—SQL and parameter configuration.
The specific approach is as follows:
On the development side, developers only need to fill in the report name, write the SQL statement, and define query parameters (parameter name, data type, display label, default value) in the tool. After saving, the report is immediately available for use. There is no need to define an Executable, register a Concurrent Program, configure Value Sets, or mount Request Groups. The entire configuration process can be completed within 3 to 5 minutes.
In terms of data security, the tool reuses EBS's user authentication mechanism, ensuring that only users with the appropriate EBS responsibilities can access and run reports. Multi-Organization Access Control (MOAC) logic involved in SQL queries remains in the SQL statements themselves, controlled by developers according to actual business requirements.
In terms of output format, the tool directly generates .xlsx Excel files. Each query result field corresponds to one Excel column, and each row of data corresponds to one Excel row. Field widths are automatically adapted to content, and long text content does not trigger line wrapping that would corrupt data. Numbers, dates, and other data types retain their original data type attributes during export, allowing users to sort, filter, and perform calculations directly upon opening the Excel file.
In terms of extensibility, in addition to Excel, the tool also supports JSON format output, facilitating integration with external data platforms or BI systems.
After a period of internal use, this tool has indeed delivered efficiency improvements in the following areas:
At the same time, I must also point out the limitations of this tool:
For 18 years, EBS has been an enterprise-grade application platform whose core architectural stability and rigor are beyond question. But precisely because of this stability, some design choices that were reasonable in their time appear slow and cumbersome in today's usage scenarios.
The process cost of report development, the text-based output format, the response path for ad hoc needs—these problems did not emerge only today. It is simply that in today's environment, their costs have become more pronounced. Business rhythms are accelerating, enterprise demands for data responsiveness are increasing, and the tools and processes we use remain stuck in a bygone era.
SQLVantage is an attempt I have made based on these problems. It is not really an innovation, but rather a simplification and reorganization of existing processes. If this article can resonate with some fellow practitioners, or provide a reference perspective for those thinking about similar issues, it will have achieved its purpose.
Writing this, I do not intend to package it as a "success story." It is simply someone who has been repeatedly troubled by specific problems in specific work scenarios, trying to improve those problems in their own way. As for how far this path can go, it still needs to be continuously tested in practice. But at the very least, the direction is right—let developers return to SQL itself, let users return to data itself, and let the tool handle the unnecessary things in between.