EBS Natural Language Query – Ask your E-Business Suite anything with AI

In December, Oracle released a great new feature for Oracle E-Business Suite: Natural Language Query with Oracle Generative AI (see the announcement by Nadia Bendjedou over there: https://blogs.oracle.com/ebstech/post/enabling-natural-language-query-of-ebs-122-using-oracle-generative-ai-now-available).

In the previous weeks, we looked into this with first customers, and the real-world results turned out at least as impressive as the demos that I've seen from Oracle's side.

In this series of blogs, I'll delve into this topic in more detail – I especially plan to cover:

• the high-level architecture of the solutions (in this episode),

• the in-depth steps to install the pre-built solution for Natural Language Query,

• of course, the (GenAI/LLM) costs that are applicable to the solution (spoiler: there are no additional licensing costs to Oracle; you just have to "pay" for the calls to the LLM),

• and – finally and probably the most important aspect –, how the blueprint from Oracle can be extended for customizations.

Oracle also documented this in great detail in the "MOS Note 3059877.1: Enabling Natural Language Query of Oracle E-Business Suite (EBS) Release 12.2, Leveraging Oracle Generative AI".

The basic idea of the solution is to allow end users to ask natural language questions to the E-Business Suite, which can then be answered in tabular form. Some samples I've run for this in real customer cases as well as the according Oracle samples may be:

• "Show employees with more than 25 years of experience along with their qualification"

• Q1: "Show me all the outstanding orders for customer XYZ." Q2: "Segment this by the item to be delivered". Q3: "give me the order volume for these orders"

• "Show the details of the workorders released in the last 2 weeks which are delayed"

Look and Feel of the "Ask Oracle E-Business Suite" Pre-Built APEX page; source: Oracle, see 3059877.1

The high-level architecture of the solution is depicted in the following picture:

High level architecture of the solution; source: Oracle, see 3059877.1

The user is presented with an APEX UI to ask questions. This APEX UI can (now) be easily integrated with E-Business Suite including SSO; but that is another story to be told in a separate blog.

This query is then sent to an Oracle 23ai database that knows (at least) the structure of the relevant database tables. Based on this table structure (including foreign keys, description on the relevant columns such as names, data types and comments, and eventually additional hints describing these tables), a "prompt" is prepared that brings this metadata and the actual "natural query" together with the task "craft a SQL statement for me that answers the question". Eventually, this prompt is extended by previous questions of a conversation, in order to allow the incremental refinement of the query.

Finally, this prompt (which just contains metadata; it never contains real data from your EBS tables) is sent to a large language model. We've had good experiences with the Meta Llama 3.1 model with 70b parameters (https://www.llama.com/) hosted on OCI, but that is not really the important part. The LLM then returns an SQL query, which is then executed against the "real" E-Business Suite database to hopefully answer the question answered.

As described above, this solution uses the following core components:

• Oracle APEX 24.1 as the UI to interact with the solution and visualize the results. I'd highly suggest using this to build extensions for your E-Business Suite independently from AI. Have a look at the new integration published in this blog post by Santiago Bastidas in November: https://blogs.oracle.com/ebstech/post/enhanced-integration-with-ebs-122-and-apex-now-available.

• An Oracle Database 23ai for building the SQL queries and having the pre-built profiles to talk to an LLM. Now you might say: “Wait, but 23ai is not yet available on-premise, so if I run on-premise or on OCI Compute, how can my E-Business Suite database be on the 23ai release?” Fortunately, as you can see in the architecture diagram above, this can be done in a separate database. In many cases, an Autonomous DB (ADB) 23ai "free edition" suffices for this purpose, since the database simply needs to know the metadata and has no "real data". This approach works even if your E-Business Suite hasn’t been updated to the latest and greatest functional and technical releases – while being updated to the latest ECC on 12.2.14 with APEX and a 19c, or even a 23ai Database makes things easier, this approach still works with older releases.

• A large language model supported by the DBMS_CLOUD_AI package of the 23ai Database; the pre-built solution and most of my tests were done using Meta Llama 3.1 70b running on OCI, but there is room for flexibility there.

• A bunch of pre-built packages and APEX pages that glues all these components together.

• And finally, 10 pre-defined "Business Domains" from Oracle that contain "secure" views, including descriptive metadata that allows you to ask your E-Business Suite in the following domains without any development: Discrete Costing, Discrete Manufacturing, Dispute (AR), Logistics, Maintenance, Order Management (OM), Payment (AP), People (HR), Process Manufacturing (GME), Project Manufacturing (PJM).

A key aspect when building such a solution is to maintain security. Of course, you don't want your users to be able to e.g.:

• tell the database to truncate the RA_CUSTOMER_TRX_ALL table;

• ask the system for the salary of the CEO;

• query sales details in a foreign legal entity.

To prevent such issues, the solution relies on the following basic principles

• The queries are executed as a user that just has READ privileges on dedicated NLQ views.

• Said views are secured with VPD policies that are in line with the regular access privileges given to the user. For this purpose, the Oracle pre-built domains/NLQ views rely on the Enterprise Command Center (ECC) views, which already have VPD policies in place that allow to only show "granted" records.

• Finally, the solution integrates the standard EBS function security.

As you can see in the above high-level architecture, no "real" data is stored within the "Autonomous DB 23ai on OCI" database. Furthermore, no such data is sent to the large language model. By using a model that is hosted within OCI (e.g. in Frankfurt), the "query" entered by the user is also under your control and does e.g. not just go to OpenAI with "whatever privacy" they guarantee.

The new EBS Natural Language Query functionality provides a very easy-to-setup and yet powerful way to ask your E-Business Suite anything without being an SQL developer. In the next blog post episode, we'll look into the detailed procedure to get this solution installed.

Feel free to tell me about your thoughts and your potential use cases with this great new tool!