DEV Community: Prathap Reddy

Oracle WebLogic Server 14c to 15c Upgrade: Practical Lab Migration Guide

Prathap Reddy — Thu, 24 Sep 2026 08:38:05 +0000

I recently tested a WebLogic Server 14c → 15c migration in a local Windows environment.

This article documents the actual lab approach I followed: backing up the existing Oracle Home, installing WebLogic 15c separately, moving the existing user_projects, and validating that the existing domain starts successfully on WebLogic 15c.

Environment used

Source: WebLogic Server 14.1.2.0.0
Target: WebLogic Server 15.1.1.0.0
OS: Windows
Domain: base_domain
Installation type: WebLogic Server only
No Forms, Reports, or other Fusion Middleware products

Oracle documents 14.1.2.0.0 → 15.1.1.0.0 as a supported WebLogic Server upgrade path.

Check the Existing WebLogic Version

Before starting the migration, verify the current WebLogic installation.

For example:

cd C:\Oracle\Middleware\Oracle_Home\wlserver\server\bin

java -cp ..\lib\weblogic.jar weblogic.version

The source environment should show:

WebLogic Server 14.1.2.0.0

Also verify the JDK:

java -version

Document the current:

WebLogic version
JDK version
Oracle Home
Domain Home
AdminServer
Managed Servers
Node Manager
Applications

This gives you a baseline before the upgrade.

Stop the Existing WebLogic Environment

Before taking the backup, stop:

Node Manager
AdminServer
Managed Servers

Make sure no WebLogic/Java processes are still using the Oracle Home.

On Windows:

tasklist | findstr /I "java"

This is important because running processes can lock files and prevent you from renaming or backing up the Oracle Home.

Take a Backup of the Existing Oracle Home

I kept the existing 14c installation as a backup.

For example:

C:\Oracle\Middleware\Oracle_Home

was backed up as:

C:\Oracle\Middleware\Oracle_Home_14c_BKP

The backup gives you a rollback point if something goes wrong during testing.

Take a Backup of user_projects

The WebLogic domain contains environment-specific configuration.

For example:

Oracle_Home_14c
└── user_projects
└── domains
└── base_domain

I also preserved the existing user_projects directory.

This is important because the Oracle Home contains the WebLogic software, while user_projects contains the domain and its environment-specific configuration.

Install WebLogic Server 15c

Next, install WebLogic Server 15.1.1.0.0 into a new Oracle Home.

For example:

C:\Oracle\Middleware\
│
├── Oracle_Home_14c_BKP
│
└── Oracle_Home

The new Oracle_Home contains WebLogic 15c, while Oracle_Home_14c_BKP preserves the previous environment.

For the generic installer, Oracle provides:

fmw_15.1.1.0.0_wls_generic.jar

The WebLogic 15.1.1 installation documentation should be checked for the currently supported JDK and installation requirements.

Verify WebLogic 15c

After installation, verify the new WebLogic version:

cd C:\Oracle\Middleware\Oracle_Home\wlserver\server\bin

java -cp ..\lib\weblogic.jar weblogic.version

Expected result:

WebLogic Server 15.1.1.0.0

Also check:

java -version

At this point, we have:

14c
│
└── Oracle_Home_14c_BKP

15c
│
└── Oracle_Home

Move the Existing user_projects

For my lab test, I copied the existing user_projects from the 14c backup into the new WebLogic 15c Oracle Home.

Source:

C:\Oracle\Middleware\Oracle_Home_14c_BKP\user_projects

Destination:

C:\Oracle\Middleware\Oracle_Home\user_projects

Using ROBOCOPY:

robocopy "C:\Oracle\Middleware\Oracle_Home_14c_BKP\user_projects" "C:\Oracle\Middleware\Oracle_Home\user_projects" /E

After the copy, verify:

dir C:\Oracle\Middleware\Oracle_Home\user_projects\domains

You should see:

base_domain

Then:

dir C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain

Start WebLogic Using the 15c Installation

Now use the domain under the new Oracle Home.

For example:

cd C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain\bin

startWebLogic.cmd

Monitor the AdminServer log.

The important confirmation is:

Server state changed to RUNNING

Once AdminServer reaches RUNNING, the WebLogic 15c domain is successfully starting in the lab environment.

Verify the AdminServer

Check the configured listen address and port.

For example:

AdminServer
|
└── 10.250.109.98:7001

You can test the server with:

http://localhost:7001

or:

http://:7001

Start the Managed Servers

After AdminServer is running, start the Managed Servers.

Example:

AdminServer
|
├── ManagedServer1
├── ManagedServer2
└── ManagedServer3

Verify that each server reaches:

RUNNING

Check the server logs for:

Startup errors
Data Source failures
JMS failures
Security errors
Deployment failures

Validate the Existing Applications

After the servers are running, validate the applications that existed in the 14c environment.

Check:

✓ Application state
✓ WAR/EAR deployments
✓ Context roots
✓ JDBC Data Sources
✓ JMS
✓ Security
✓ SSL
✓ REST/SOAP services
✓ External integrations

Don't assume application compatibility simply because the WebLogic server starts successfully.

WebLogic Server 15.1.1 uses Jakarta EE 9.1, so applications from earlier environments should be evaluated for compatibility and may require modification/recompilation.

An Important Observation From My Lab

In this particular lab test, I did not run the Reconfiguration Wizard.

My test flow was:

WebLogic 14c
↓
Backup Oracle Home
↓
Install WebLogic 15c
↓
Copy user_projects
↓
Start WebLogic
↓
AdminServer → RUNNING
↓
Validate environment

The existing domain was able to start successfully using the new WebLogic 15c installation.

However, this lab observation should not be interpreted as saying that reconfiguration is universally unnecessary.

Oracle's documented WebLogic 15.1.1 upgrade procedure includes domain upgrade/reconfiguration considerations, so production environments should be evaluated against the official upgrade documentation before choosing to omit that step.

This distinction is important:

A successful server startup in a lab does not by itself establish that every documented production upgrade step can be skipped.

Domain Upgrade vs Application Upgrade

These are two separate areas.

WebLogic Domain
↓
Domain upgrade / configuration
↓
WebLogic 15c

and:

WAR / EAR Application
↓
Jakarta EE compatibility
↓
Modification / recompilation if required
↓
Deploy to WebLogic 15c

WebLogic 15.1.1 introduces the Jakarta EE 9.1 application environment, so application compatibility should be tested separately.

WebLogic Remote Console

Another major administration change is the use of WebLogic Remote Console.

For modern WebLogic environments, administrators can use Remote Console to manage:

Servers
Deployments
Data Sources
JMS
Security
Domain configuration

WebLogic Remote Console can be downloaded from the official Oracle repository:

Oracle WebLogic Remote Console Releases

For example:

WebLogic 15c
↓
AdminServer
↓
WebLogic Remote Console
↓
Domain Administration

I also documented the Remote Console setup separately:

How to Access Oracle WebLogic Remote Console in WebLogic 14c

Final Architecture

The lab migration can be represented as:

          WEBLOGIC 14c
          14.1.2.0.0
               │
               ▼
        BACKUP ORACLE HOME
               │
               ▼
      INSTALL WEBLOGIC 15c
          15.1.1.0.0
               │
               ▼
        COPY USER_PROJECTS
               │
               ▼
         START DOMAIN
               │
      ┌────────┴────────┐
      ▼                 ▼
  AdminServer       Managed Servers
      │                 │
      └────────┬────────┘
               ▼
        APPLICATION TEST
               │
               ▼
         VALIDATION

Conclusion

My WebLogic 14c → 15c lab migration demonstrated that an existing WebLogic domain can be tested against a new WebLogic 15c Oracle Home by:

Backup → Install 15c → Copy user_projects → Start → Validate

The most important lesson is to keep the Oracle Home, domain, and applications as separate upgrade considerations.

For production migrations, always compare your environment with Oracle's official 15.1.1 upgrade documentation, particularly around domain reconfiguration and application compatibility.

References

Oracle WebLogic Server 15.1.1 Upgrade Guide

Oracle WebLogic Server 15.1.1 Installation Guide

Oracle WebLogic Remote Console Releases

Oracle #WebLogic #WebLogicServer #WebLogic15c #WebLogic14c #OracleMiddleware #WebLogicUpgrade #Java #JakartaEE #RemoteConsole #DevOps #Middleware #ApplicationServer

How to Access Oracle WebLogic Remote Console in WebLogic 14c

Prathap Reddy — Thu, 24 Sep 2026 08:22:49 +0000

How to Access Oracle WebLogic Remote Console in WebLogic 14c

After upgrading from Oracle WebLogic Server 12c to 14c, one of the important administration changes is how we access the WebLogic management interface.

In WebLogic Server 14.1.2, the traditional WebLogic Administration Console (/console) is no longer available. WebLogic Remote Console can be used to administer the WebLogic domain instead.

Download WebLogic Remote Console---https://github.com/oracle/weblogic-remote-console/releases

Download the Remote Console from the official Oracle GitHub releases page:

Oracle WebLogic Remote Console Releases

Select the installer appropriate for your operating system and install it.

Start WebLogic Server

Before connecting Remote Console, make sure the WebLogic AdminServer is running.

For example:

AdminServer
|
└── Listen Address: 10.250.109.98
Listen Port: 7001

You can verify the server log for:

Server state changed to RUNNING

Launch WebLogic Remote Console

Open WebLogic Remote Console after installation.

Create a connection/provider for your WebLogic domain.

For a local environment, the management endpoint will typically be based on:

http://:7001

For example:

http://10.250.109.98:7001

Use the appropriate hostname/IP and port configured for your AdminServer.

Enter WebLogic Administrator Credentials

Provide the administrator username and password configured when the WebLogic domain was created.

Remote Console will connect to the AdminServer and retrieve the domain configuration.

Access the Domain

After successfully connecting, you can manage the WebLogic environment from Remote Console.

Typical administration areas include:

Domain
├── Servers
├── Deployments
├── Data Sources
├── JMS
├── Security
└── Other Domain Configuration

For application deployment, navigate to:

Edit Tree
↓
Deployments
↓
App Deployments

From there you can create and manage WAR/EAR deployments.

Remote Console vs WebLogic 12c Console

The administration workflow changes after the upgrade:

WebLogic 12c
|
└── http://hostname:7001/console
|
| Upgrade
↓
WebLogic 14c
|
└── WebLogic Remote Console

This is an important change to document when performing a 12c → 14c WebLogic upgrade.

Conclusion

When moving to WebLogic Server 14.1.2, administrators should plan for the change from the traditional Administration Console to WebLogic Remote Console.

The basic workflow is:

Download → Install → Start AdminServer → Connect Remote Console → Authenticate → Manage Domain

Oracle WebLogic Remote Console Documentation

Oracle #WebLogic #WebLogic14c #WebLogicServer #OracleMiddleware #RemoteConsole #WebLogicUpgrade #OracleTechnology #Java #Middleware

🚀 Oracle WebLogic Server 12c to 14c Upgrade — Practical Migration Guide

Prathap Reddy — Thu, 24 Sep 2026 08:18:44 +0000

🚀 Oracle WebLogic Server 12c to 14c Upgrade — Practical Migration Guide

I recently worked through a WebLogic Server upgrade scenario from

🔹 WebLogic Server 12.2.1.4—jdk 8 or 11 supported
➡️ WebLogic Server 14.1.2.0.0—jdk 17 or 21 is supported

This migration is more than simply installing a new WebLogic version. The existing domain configuration, applications, Node Manager, JDK, Oracle Home, and environment-specific customizations all need to be considered.

🔹 High-Level Upgrade Approach

1️⃣ Analyze the existing environment.

Before starting the upgrade:

• Verify WebLogic version
• Identify Oracle Home / Middleware Home
• Identify JDK version
• Review AdminServer and Managed Servers
• Check Node Manager configuration
• Review deployed applications
• Check JDBC data sources and JMS resources
• Take a complete domain backup
• Document custom startup scripts and environment variables

2️⃣ Install WebLogic Server 14c

Install the new WebLogic/Fusion Middleware software into a separate Oracle Home.

Example:

C:\Oracle\Middleware\Oracle_Home_BKP
        ↓
Existing 12c environment

C:\Oracle\Middleware\Oracle_Home
        ↓
New 14c environment

Keeping the old Oracle Home available provides a useful rollback point during testing.

3️⃣ Move/prepare the existing domain

The existing ``/domain configuration needs to be handled carefully.

Example:

`text
Oracle_Home_BKP
└── user_projects
└── domains
└── base_domain

↓

Oracle_Home
└── user_projects
└── domains
└── base_domain
`

Do not blindly copy the entire old Oracle Home over the new installation.

4️⃣ Reconfigure the domain

When the Oracle Home or JDK location changes, the WebLogic domain may need to be reconfigured using the Fusion Middleware Reconfiguration Wizard or WLST.

The reconfiguration updates the domain so that it is compatible with the newer WebLogic Server release.

⚠️ Always back up the domain before reconfiguration because Oracle states that the domain reconfiguration process is irreversible.

5️⃣ Validate Node Manager

Node Manager is another important area during the migration.

Verify:

• nodemanager.properties
• nodemanager.domains
• ListenPort
• JavaHome
• DomainsFile
• SecureListener configuration

Oracle's 14.1.2 documentation provides specific Node Manager steps for the upgrade.

6️⃣ Start the upgraded environment

Start:

`text Node Manager ↓ AdminServer ↓ Managed Servers `

Then verify:

`text Server State = RUNNING `

7️⃣ Validate applications

After the domain is running:

✅ Verify deployments
✅ Verify application status
✅ Test application URLs
✅ Test JDBC connections
✅ Test JMS
✅ Check authentication/security
✅ Check logs
✅ Verify integrations
✅ Check SSL certificates
✅ Validate external connections

🔹 Important Oracle Recommendation

Oracle officially documents the upgrade path:

WebLogic Server 12.2.1.4 → WebLogic Server 14.1.2.0.0

If the source environment is older than 12.2.1.4, it must first be brought to a supported starting point.

🔹 Key Lesson

A WebLogic upgrade should be treated as an environment migration, not simply a software installation.

The most important areas are:

Oracle Home + JDK + Domain + Node Manager + Applications + Middleware components + Customizations

A proper backup and rollback strategy should be prepared before modifying the existing domain.

📌 Oracle Upgrade Documentation:
https://docs.oracle.com/en/middleware/fusion-middleware/weblogic-server/14.1.2/upgrade.html

Oracle #WebLogic #OracleMiddleware #WebLogicServer #FusionMiddleware #Java #Middleware #ApplicationServer #DevOps #SystemAdministration #Cloud #OracleTechnology

Technical post idea: WebLogic — High CPU Troubleshooting

Prathap Reddy — Wed, 16 Sep 2026 03:05:48 +0000

🚨 Oracle WebLogic Server: How I Approach a High CPU Issue

A high CPU alert on a WebLogic server doesn't always mean the JVM itself is the problem.

A structured troubleshooting approach can help identify the actual source.

🔹 1. Check OS-level CPU

Start by identifying which process is consuming CPU:

top

ps -ef | grep java

Don't immediately restart the server. First identify the process and PID.

🔹 2. Identify the WebLogic JVM

Once the Java PID is identified, verify:

• Which Managed Server is using the JVM
• JVM heap configuration
• Number of threads
• GC activity
• Application workload

🔹 3. Check WebLogic Thread Activity

Look for:

• Stuck threads
• Excessive thread usage
• Long-running requests
• Connection pool issues
• Repeated application requests

The WebLogic Administration Console and server logs can provide useful clues.

🔹 4. Take Thread Dumps

For CPU-related issues, thread dumps can help identify what the JVM threads are actually doing.

Take multiple thread dumps at intervals rather than relying on a single snapshot.

Example:

jstack <PID> > threaddump1.txt

Then compare the dumps to identify threads that remain active.

🔹 5. Check Garbage Collection

High CPU can also be associated with excessive GC activity.

Review:

• Young GC
• Full GC
• Heap utilization
• GC frequency
• Pause times

🔹 6. Check Application-Level Processes

Sometimes the WebLogic JVM is only where the symptom appears.

The underlying cause may be:

➡️ Application code
➡️ Infinite/repeated processing
➡️ Database calls
➡️ External service calls
➡️ Incorrect configuration
➡️ Memory/GC pressure

🔹 7. Don't Treat Restart as the Root-Cause Fix

Restarting the Managed Server may temporarily reduce CPU, but it doesn't explain why the CPU increased.

A better approach is:

Alert → Identify PID → Analyze threads → Check GC → Review logs → Identify root cause → Apply fix → Monitor

This approach helps convert a production incident from a "restart and recover" activity into a proper troubleshooting exercise.

💡 Key takeaway:

High CPU is a symptom. The goal is to identify the workload or thread causing it.

What other WebLogic troubleshooting topics would you like to see?

Oracle #WebLogic #OracleWebLogic #Middleware #Java #JVM #Troubleshooting #ProductionSupport #OracleTechnology #DevOps

Oracle Forms & Reports 12.2.1.4 to 12.2.1.19 Upgrade: Post-Upgrade Issues, Missing Files, and Troubleshooting Lessons

Prathap Reddy — Sun, 06 Sep 2026 14:22:04 +0000

Introduction

Oracle Forms and Reports upgrades are often considered complete once the new Oracle Home, WebLogic configuration, Forms services, and Reports services are successfully installed and started.

However, in a real enterprise environment, the upgrade does not end when the servers come up successfully.

The real challenge often begins during post-upgrade validation.

Recently, while working on an Oracle Forms & Reports upgrade from 12.2.1.4 to 12.2.1.19, we encountered several issues after the upgrade:

Forms application icons/images were missing.
Some Reports were not accessible or were failing to run.
OS-level and kernel compatibility issues required validation.
Some supporting files and custom configurations were not available in the upgraded environment.
Existing customizations from the previous environment needed to be compared and restored.

The interesting part was that the core Forms and Reports services were running. The issue was not simply that the application was down.

The problem was in the post-upgrade configuration, customizations, supporting files, and environment differences.

This blog explains our troubleshooting approach and the key lessons learned.

The Upgrade Scenario

The environment was upgraded from:

Oracle Forms & Reports 12.2.1.4

to:

Oracle Forms & Reports 12.2.1.19

At first, the upgraded environment appeared healthy:

WebLogic was running.
Forms services were running.
Reports services were running.
Application access was available.
Basic functionality was working.

But during application validation, we identified issues that were not immediately visible from the server startup status.

This is an important lesson:

A successful middleware startup does not necessarily mean a successful application upgrade.

Issue #1 – Forms Icons and Images Were Missing

One of the first issues noticed after the upgrade was that some Forms application icons/images were not displayed correctly.

The Forms application itself could be accessed, but certain visual resources were missing.

This immediately raised several questions:

Were the application resources migrated?
Were custom JAR files copied?
Was formsweb.cfg migrated correctly?
Was Registry.dat customized?
Were image/resource directories available?
Were the correct paths configured?
Were the required files available under the new Oracle Home or application deployment?

Instead of assuming that the Forms installation was corrupted, we started comparing the old and new environments.

Comparing the Old and New Environments

One of the most useful troubleshooting techniques during an upgrade is:

Compare the working 12.2.1.4 environment with the upgraded 12.2.1.19 environment.

Rather than looking only at the new environment, we treated the old environment as a reference point.

We reviewed:

Forms configuration
formsweb.cfg
default.env
Registry.dat
Application resources
*.jar
images
icons
custom resources
application-specific files
Forms directories

We also reviewed the relevant Forms configuration and application directories to identify differences.

This comparison helped us identify files and customizations that needed to be restored or merged into the upgraded environment.

Important Lesson – Do Not Blindly Copy Configuration Files

One of the biggest lessons from the troubleshooting process is that an upgrade should not be treated as:

Old Oracle Home
↓
Copy everything
↓
New Oracle Home

That approach can introduce new problems.

Instead, the better approach is:

12.2.1.4 Environment
↓
Identify customizations
↓
Compare with 12.2.1.19
↓
Validate compatibility
↓
Merge required configurations
↓
Test

The goal is to migrate required customizations, not blindly overwrite the new configuration.

Issue #2 – Reports Were Not Accessible

The second major issue was related to Oracle Reports.

Some reports that were previously accessible were no longer working correctly after the upgrade.

We therefore started investigating the Reports environment separately from Forms.

The following areas became important:

rwserver.conf
rwnetwork.conf
REPORTS_PATH
Environment variables
Reports Server configuration
Reports Tools configuration
Printer configuration
Font configuration
Report files
TNS configuration
Custom directories

Reports Configuration Validation

The Reports Server configuration was compared between the old and new environments.

Particular attention was given to:

rwserver.conf
rwnetwork.conf

We also reviewed the environment variables used by Reports.

For example:

echo $ORACLE_HOME
echo $PATH
echo $TNS_ADMIN
echo $REPORTS_PATH

The objective was to determine whether the upgraded Reports Server had access to the same required resources as the previous environment.

.prt Files – An Easily Overlooked Area

Another important area during our investigation was the Reports printer configuration.

We found differences in the available .prt files between the environments.

For example, the environment contained directories such as:

$ORACLE_HOME/reports/printer

and:

$ORACLE_HOME/reports/printers

We compared the files available in these directories between the old and new environments.

For example:

find $OLD_ORACLE_HOME/reports/printer -type f -name "*.prt" | sort

and:

find $NEW_ORACLE_HOME/reports/printer -type f -name "*.prt" | sort

The same comparison can be performed for:

$ORACLE_HOME/reports/printers

This type of comparison is useful because printer-related configuration can be overlooked when focusing only on WebLogic, Forms and Reports server startup.

OS and Kernel Compatibility

Another area that should not be ignored during a Forms & Reports upgrade is the underlying operating system.

Even if the middleware configuration looks correct, differences at the OS level can affect application behavior.

We reviewed areas such as:

OS version
Kernel version
Installed patches
Shared libraries
System dependencies
Environment variables
File permissions
Services
System-level configuration

For example:

uname -r

can be used to identify the running kernel version.

Additional OS package and library validation may also be required depending on the platform and Oracle certification requirements.

The key point is:

Middleware compatibility should always be evaluated together with the underlying OS and system libraries.

Finding the Missing Files

At this stage, the most effective method was not to guess which file was missing.

We followed a simple approach:

Step 1 – Identify the failed functionality

For example:

Missing Forms icon

or:

Report cannot be accessed
Step 2 – Identify the resource required

Determine which configuration, JAR, image, report, printer definition, environment variable, or system dependency is involved.

Step 3 – Compare old and new environments
12.2.1.4 → Working
12.2.1.19 → Not working
Step 4 – Identify the difference

Look for:

Missing file
Different configuration
Different path
Missing customization
Different permissions
Missing library
Different OS dependency
Step 5 – Restore the required customization

Only after validating the difference should the required file or configuration be added to the new environment.

Resolution

After identifying the missing files/configurations, we restored the required resources into the upgraded environment.

The environment was then restarted and application functionality was tested again.

The result was positive:

✅ Forms icons/images were displayed correctly.

✅ Previously affected Reports became accessible.

✅ The application functionality was restored.

This demonstrated an important point:

The upgrade itself was not necessarily the problem. The problem was the gap between the old customized environment and the new upgraded environment.

Recommended Post-Upgrade Validation Checklist

After completing a Forms & Reports upgrade, I recommend validating the following areas.

Forms
✓ formsweb.cfg
✓ default.env
✓ Registry.dat
✓ Custom JAR files
✓ Application images/icons
✓ Application resource directories
✓ Forms templates
✓ Environment variables
✓ Application-specific configurations
Reports
✓ rwserver.conf
✓ rwnetwork.conf
✓ REPORTS_PATH
✓ Reports Server configuration
✓ Reports Tools configuration
✓ RDF/REP/XML report locations
✓ Printer configuration
✓ .prt files
✓ Font configuration
✓ Destination configuration
✓ Database connectivity
✓ TNS configuration
Operating System
✓ OS version
✓ Kernel version
✓ Required patches
✓ Shared libraries
✓ System packages
✓ File permissions
✓ Mount points
✓ Environment variables
✓ System services
✓ OS-level compatibility
Application
✓ Forms login
✓ Forms navigation
✓ Icons/images
✓ LOVs
✓ Attachments
✓ Reports invocation
✓ Report output
✓ PDF generation
✓ Printer functionality
✓ Database connectivity
✓ Custom integrations

Old vs New Environment Comparison

One of the best practices we took from this experience is to create an explicit comparison checklist before declaring the upgrade complete.

Area 12.2.1.4 12.2.1.19 Validation
Forms configuration Available Compare Required
formsweb.cfg Customized Compare Required
default.env Customized Compare Required
Registry.dat Customized Compare Required
Custom JARs Available Verify Required
Images/icons Available Verify Required
Reports configuration Available Compare Required
rwserver.conf Customized Compare Required
.prt files Available Verify Required
REPORTS_PATH Configured Verify Required
OS kernel Existing Verify Required
Libraries Existing Verify Required
Customizations Existing Verify Required

This gives the upgrade team a much more reliable way to validate the environment.

Key Lessons Learned
Installation success ≠ application success

WebLogic, Forms and Reports services can all be running while application-level issues still exist.

Customizations are critical

Enterprise Forms & Reports environments often contain years of custom configuration, JARs, images, printer definitions, environment variables and supporting files.

These need to be identified before the upgrade.

Compare, don't guess

The working environment is one of the most valuable troubleshooting references.

A structured old-vs-new comparison can quickly reveal what changed.

Don't overwrite the new configuration blindly

The new Oracle version may contain important default configuration changes.

Custom settings should be reviewed and merged carefully.

OS-level validation matters

Kernel versions, libraries, packages and system configuration can influence middleware behavior.

Post-upgrade testing must be functional

Don't stop at:

WebLogic = RUNNING
Forms = RUNNING
Reports = RUNNING

Also test:

Application → Forms → Icons → Navigation → Reports → Output → Printing
Conclusion

The upgrade from Oracle Forms & Reports 12.2.1.4 to 12.2.1.19 gave us an important practical lesson.

A successful upgrade is not simply about installing the new Oracle version and starting the services.

The real success criteria are:

Configuration + Customizations + Application Resources + Reports + OS Compatibility + Functional Testing

In our case, some required files and configurations were missing after the upgrade. By comparing the old and new environments, identifying the differences, and restoring the required resources, the affected Forms icons and Reports functionality started working again.

For anyone planning a similar upgrade, I strongly recommend creating an old-vs-new configuration and file comparison checklist before and after the upgrade.

That small step can save significant troubleshooting time.

What has been your experience?

Have you encountered any of these issues during an Oracle Forms & Reports upgrade?

Missing Forms icons/images?
Reports not accessible?
Missing .prt files?
Configuration/customization gaps?
OS kernel or library compatibility issues?
Missing JARs or application resources?

I would love to hear your experience and learn what other commonly overlooked files or configurations should be included in a Forms & Reports upgrade checklist.

Connecting Google Gemini AI with Oracle APEX: My Hands-On Experience

Prathap Reddy — Wed, 19 Aug 2026 12:18:16 +0000

Recently, I started exploring the Generative AI capabilities available in Oracle APEX. As part of my learning, I wanted to see how easily I could connect an external AI model to APEX and test it in a real environment.

For this experiment, I chose Google Gemini and configured it through the Generative AI Services available in Oracle APEX.

The setup was quite straightforward, and I wanted to document the steps I followed and a few things I learned along the way.

Why I Tried This

I've been working with Oracle APEX and wanted to understand how AI can be brought into low-code application development.

Instead of building a separate application or writing a custom integration from scratch, APEX provides configuration options for connecting to generative AI services.

That made it a good opportunity for me to try the integration myself and understand what happens behind the scenes.

What I Used

For my setup, I used:

Oracle APEX

Google Gemini

Gemini API key

APEX Generative AI Services

APEX Workspace Administrator access

I also used my own APEX environment to test the configuration.

Configuring Gemini in Oracle APEX

I started by navigating to:

Workspace Utilities → Generative AI Services → Create/Edit

From there, I created a new Generative AI Service and selected Google Gemini as the AI provider.

I gave the configuration a meaningful name so that it would be easy to identify later.

Configuring the API Details

The next step was configuring the Gemini API details.

For the API endpoint, I used:

https://generativelanguage.googleapis.com/v1beta

I then provided the required model information and configured the credentials.

One thing I found useful here was that APEX provides the configuration directly from the UI, so I didn't have to write a separate REST integration just to establish the connection.

Adding the Gemini API Key

The next part was adding the Gemini API key.

I enabled the option to create credentials and entered the API key generated for my Gemini environment.

I also made sure that the API key had the required access for the Generative Language API.

For security reasons, I would recommend never publishing your actual API key in screenshots, blog posts, GitHub repositories, or other public places.

Enabling Gemini for APEX

After configuring the credentials, I looked at the APEX settings.

There are options such as:

Used by App Builder

Default for New Apps

For my testing, I enabled the appropriate option so that the configured AI service could be used by APEX App Builder.

This was one of the interesting parts of the setup because the integration is handled through the APEX configuration rather than requiring me to build the entire connection manually.

Testing the Connection

Before considering the configuration complete, I used the Test Connection option.

I think this is an important step because it immediately tells you whether the basic configuration is working.

If something goes wrong, I would first check:

API key

Model ID

Base URL

Endpoint URL

Credentials configuration

Network/connectivity

Whether the selected model is supported by the configured APEX integration

My Configuration Screen

This is the configuration screen from my APEX environment:

The screenshot shows the Gemini provider, API configuration, model information, credentials, and the App Builder settings.

What I Learned

The biggest takeaway for me was that connecting an AI service to APEX doesn't necessarily require a large amount of custom development.

The configuration is largely handled through the APEX interface, which makes it easier to experiment with generative AI capabilities while continuing to work within a low-code environment.

I also learned that small configuration details matter. The API key, model ID, endpoint, and credential settings all need to match the AI service being used.

Where This Could Be Useful

There are several areas where I think this type of integration could be useful in APEX applications:

Generating application content

Assisting developers during application development

Natural-language interactions

Generating SQL or application-related suggestions

AI-assisted application development

Building smarter business applications

The actual use case will depend on the application and the AI capabilities being enabled.

A Small Lesson From My Experiment

One thing I would recommend to anyone trying this for the first time is don't immediately start troubleshooting the entire application when something doesn't work.

Start with the connection itself.

Check the API key, model, endpoint, credentials, and then use Test Connection.

Once the basic connection works, move on to testing the AI features inside APEX.

That approach makes troubleshooting much easier.

Final Thoughts

This was a useful hands-on experiment for me because it helped me understand how Oracle APEX and Generative AI can work together.

I'm still exploring what can be built with this integration, but I think the combination of low-code development and AI has a lot of potential.

My next step is to move beyond the configuration and build an actual business use case with APEX and Gemini rather than just testing the connection.

Have you tried integrating Gemini, OpenAI, or another LLM with Oracle APEX? I'd be interested to hear about your experience and what you built.

OracleAPEX #GeminiAI #Oracle #GenerativeAI #LowCode #AI #AppDevelopment

Connecting Oracle APEX to Google Gemini AI: A Step-by-Step Guide

Prathap Reddy — Wed, 19 Aug 2026 11:47:00 +0000

Introduction

Oracle APEX has quietly made adding generative AI to low-code apps as simple as filling out a form. No middleware, no custom REST wrappers, no separate AI service to host. In this post, I'll walk through exactly how I connected Google Gemini to my APEX workspace using APEX's native Generative AI Services, and what it unlocks once it's set up.

Why this matters

Most teams assume "adding AI" means weeks of integration work and a dedicated ML engineer. Oracle APEX flips that: plugging in a foundation model is now a configuration task, not an engineering project. Once connected, AI capabilities like Builder AI, natural language search, and AI-assisted page generation work automatically — across every app in your workspace.

Prerequisites
An Oracle APEX workspace ( tested on 26.1)
A Google Gemini API key (Google AI Studio)
Workspace admin access to configure Generative AI Services
Step-by-step setup

Navigate to Generative AI Services
From Workspace Utilities → Generative AI Services → Create/Edit.
Set the AI Provider
Choose Google Gemini from the AI Provider dropdown, and give it a name (e.g. "Gemini API Key").
Configure the Base URL and Endpoint URL
Both point to Gemini's API:

https://generativelanguage.googleapis.com/v1beta

Add credentials
Toggle "Create Credentials" on, and paste in your Gemini API key. APEX stores this securely — you won't need to manage it in code anywhere.
Enable it for App Builder
Toggle Used by App Builder and, optionally, Default for New Apps, so every new app in the workspace automatically uses Gemini.
Test the connection
Click Test Connection to confirm APEX can reach Gemini before saving.

What this unlocks

Once configured, several AI-powered features become available immediately:

Builder AI — generate pages, forms, and reports from natural language descriptions
AI-assisted natural language search in Interactive Reports
AI-generated data models and content during app creation

**Model version compatibility

Not every Gemini model works out of the box with APEX's Generative AI Services. I found that Gemini Flash 3 and onward is what you need — earlier model versions either failed to respond correctly or weren't supported by APEX's integration layer. If you're setting this up and things aren't working, check your Model ID first before troubleshooting anything else.

API key scope
Make sure the API key you generate in Google AI Studio has access to the Generative Language API specifically — a key created for a different Google Cloud service won't authenticate correctly here.

Test Connection is your friend

Don't skip the Test Connection button before saving. It catches URL/endpoint mismatches and auth issues immediately, rather than surfacing as a vague error later inside Builder AI or natural language search.

Takeaway

Low-code and generative AI are converging faster than most people realize. If you're building on Oracle APEX and haven't tried wiring in a foundation model yet, it's a 10-minute setup that changes what your app builder can do.

Have you connected an LLM into APEX or another low-code platform? I'd love to hear what you built.