Oracle E-Business Suite 12.2 Next Generation Technology Stack: Understanding the Special Online Patching Cycle

In my previous article, I introduced Oracle's 𝗡𝗘𝗫𝗧 𝗚𝗘𝗡𝗘𝗥𝗔𝗧𝗜𝗢𝗡 𝗧𝗘𝗖𝗛𝗡𝗢𝗟𝗢𝗚𝗬 𝗦𝗧𝗔𝗖𝗞 for Oracle E-Business Suite Release 12.2 and discussed the move to modern components such as WebLogic 14c, Oracle Fusion Middleware 14c, and Java 17.

While reviewing Oracle's documentation, I came across another interesting enhancement—not to the technology itself, but to the upgrade process.

Oracle has introduced a Special Online Patching Cycle that is used exclusively for upgrading to the Next Generation Technology Stack.

A Special Online Patching Cycle

It's important to clarify that Oracle has not changed the standard Online Patching (ADOP) cycle used for everyday patching and maintenance.

The familiar workflow remains:

Prepare → Apply → Finalize → Cutover → Cleanup

However, when upgrading from the Classic Technology Stack to the Next Generation Technology Stack, Oracle provides a dedicated online patching workflow.

In this special upgrade cycle, the traditional Apply phase is replaced by Technology Stack Update Assistant (TSUA).

The workflow becomes:

Prepare → TSUA → Finalize → Cutover → Cleanup → Synch

This workflow is designed specifically for the one-time migration to the Next Generation Technology Stack.

What is TSUA?

The Technology Stack Update Assistant (TSUA) is a new Oracle utility introduced specifically to simplify the migration from the Classic Technology Stack to the Next Generation Technology Stack.

Instead of using the standard Apply phase during this one-time migration, Oracle leverages TSUA as part of the Special Online Patching Cycle to automate and orchestrate the technology stack upgrade.

Behind the scenes, TSUA performs several critical tasks that would otherwise require significant manual effort, including:

• Validates the environment by performing prerequisite checks and ensuring the system is ready for the upgrade.
• Creates backups and installs the Next Generation Technology Stack software from the staged media.
• Updates the application tier directory structure to align with the new technology stack.
• Reconfigures the EBS middleware environment, including:
  • Updating the Oracle WebLogic Server (WLS) domain
  • Creating the Oracle HTTP Server (OHS) domain
  • Configuring the required Node Managers
• Applies the migration patch along with any required co-requisite patches.
• Regenerates Oracle Forms and Reports to ensure compatibility with the upgraded technology stack.

After TSUA completes successfully, the remaining online patching phases continue with:

• Finalize
• Cutover
• Cleanup
• Synch

Why Did Oracle Introduce This?

According to Oracle, this special online patching cycle is intended to make the technology stack migration:

• Less disruptive
• More streamlined
• Capable of keeping users productive for most of the upgrade process
• Simpler than performing a traditional EBS technology stack upgrade

Because the update leverages Online Patching, organizations can migrate to the Next Generation Technology Stack without requiring a major EBS upgrade.

Final Thoughts

One important point to remember is that TSUA does not replace the standard Apply phase for normal Oracle E-Business Suite patching.

Instead, it is part of a special online patching workflow introduced exclusively for migrating to the Next Generation Technology Stack.

This distinction is important for EBS administrators. Your regular ADOP patching process remains unchanged. TSUA comes into play only when performing the one-time transition from the Classic Technology Stack to Oracle's Next Generation Technology Stack.

As Oracle continues to modernize EBS 12.2, understanding this new upgrade workflow will help administrators plan and execute their technology stack migration with confidence.

Understanding the Oracle E-Business Suite 12.2 Technology Stack

 Oracle E-Business Suite (EBS) is one of the most widely deployed enterprise applications across industries. Behind every EBS environment is a collection of technology components that work together to deliver business functionality, manage user requests, and communicate with the database tier. This collection of components is known as the Oracle E-Business Suite Application Technology Stack.

What is the EBS Application Technology Stack?

The Application Technology Stack consists of the software components installed on the EBS application tier. These components are responsible for processing business logic, serving web pages, running forms and reports, and enabling communication between end users and the database.

For Oracle E-Business Suite Release 12.2, the technology stack includes:

• Oracle Fusion Middleware (FMW)

• Oracle WebLogic Server (WLS)

• Oracle HTTP Server (OHS)

• Oracle Developer (Forms and Reports)

• Java Development Kit (JDK)

Together, these components provide the foundation required to run EBS applications efficiently and securely.

The Classic Technology Stack

Since the release of EBS 12.2, most environments have been running on what Oracle refers to as the Classic Technology Stack. This stack is built on Oracle Fusion Middleware 11g and Java 7.

The certified component versions are:

Component	Certified Release
Oracle Fusion Middleware (FMW)	11.1.1.9
Oracle WebLogic Server (WLS)	10.3.6
Oracle HTTP Server (OHS)	11.1.1.9
Oracle Developer (Forms and Reports)	10.1.2
Java Development Kit (JDK)	7

For many years, this technology stack has provided a stable and reliable platform for Oracle E-Business Suite deployments worldwide.

The Next Generation Technology Stack

As technology evolves, Oracle is modernizing the EBS application tier with a newer and more secure technology foundation known as the Next Generation Technology Stack.

The planned certified releases include:

Component	Planned Certified Release
Oracle Fusion Middleware (FMW)	14.1.2
Oracle WebLogic Server (WLS)	14.1.2
Oracle HTTP Server (OHS)	14.1.2
Oracle Developer (Forms and Reports)	14.1.2
Java Development Kit (JDK)	17

This modernization introduces newer middleware and Java versions that align with current enterprise standards, helping organizations improve security, maintainability, and long-term supportability.

Why Does This Matter?

Many EBS customers continue to run mission-critical workloads on Release 12.2. Understanding the differences between the Classic and Next Generation Technology Stacks is important when planning upgrades, security initiatives, and future platform strategies.

Moving to the Next Generation Technology Stack provides organizations with:

• Modern middleware architecture

• Support for Java 17

• Enhanced security capabilities

• Improved compatibility with current infrastructure standards

• Better long-term support from Oracle

What About Support for the Classic Technology Stack?

One of the most common questions among Oracle E-Business Suite administrators is whether upgrading to the Next Generation Technology Stack is mandatory.

The answer is yes—if organizations want to remain aligned with Oracle's long-term support strategy.

Oracle has indicated that EBS Release 12.2 production environments are expected to move to the Next Generation Technology Stack to ensure continued supportability in the future. Once the Next Generation Technology Stack becomes generally available, Oracle will publish a detailed support timeline outlining key milestones and support dates.

How Long Will the Classic Technology Stack Be Supported?

At the time of writing, Oracle has not announced an end date for error correction support for the Classic Technology Stack. However, Oracle has stated that an updated support roadmap will be provided following the general availability of the Next Generation Technology Stack.

For organizations currently running the Classic Technology Stack, this means there is no immediate deadline to migrate. However, IT teams should begin evaluating the impact of the upgrade, reviewing infrastructure requirements, and planning their modernization roadmap to avoid future support challenges.

Planning Ahead

While the Classic Technology Stack remains fully functional today, the introduction of the Next Generation Technology Stack signals Oracle's strategic direction for EBS 12.2. Organizations that proactively prepare for the transition will be better positioned to:

• Maintain Oracle support eligibility

• Benefit from newer middleware and Java technologies

• Improve security and compliance posture

• Reduce technical debt

• Simplify future upgrades and maintenance

The move to the Next Generation Technology Stack should therefore be viewed not only as a technology upgrade, but as an important step in ensuring the long-term sustainability of Oracle E-Business Suite environments.

Final Thoughts

The Oracle E-Business Suite 12.2 Application Technology Stack is the foundation that powers the application tier of EBS environments. While the Classic Technology Stack has served organizations well for years, Oracle's Next Generation Technology Stack represents the future direction of EBS technology.

Organizations running EBS 12.2 should begin evaluating their technology stack roadmap and prepare for the transition to the newer platform to take advantage of modern security, performance, and support capabilities.

Strengthening Oracle Autonomous AI Database Security with Multi-Factor Authentication

 As organizations continue moving mission-critical workloads to the cloud, database security has become more important than ever. Password-based authentication alone is no longer sufficient to protect sensitive enterprise data from evolving cyber threats. To address this challenge, Oracle Autonomous AI Database now supports Multi-Factor Authentication (MFA), providing an additional layer of protection for database access and SQL execution.

What is MFA in Autonomous AI Database?

Multi-Factor Authentication enhances database security by requiring users to verify their identity using two separate authentication factors:

• Something the user knows — typically a username and password
• Something the user has — such as a one-time token, authenticator app, push notification, or secure verification mechanism

With MFA enabled, even if database credentials are compromised, unauthorized access becomes significantly more difficult.

Key MFA Capabilities

Oracle Autonomous AI Database provides flexible MFA options designed for modern enterprise environments:

1. MFA for Database Logins

Administrators can enforce MFA during user authentication to ensure only verified users can establish database sessions.

2. MFA for SQL Access

Organizations can require additional verification before executing sensitive SQL operations, adding another layer of protection for critical workloads.

3. Multiple Verification Methods

Oracle supports different MFA delivery channels, including:

• Email-based verification
• Authenticator applications
• Push notifications
• Slack-based token delivery

This flexibility allows enterprises to align MFA with their operational and security standards.

How Oracle Implements MFA

Oracle provides the DBMS_MFA_ADMIN package to simplify MFA administration. Database administrators can:

• Register users for MFA
• Configure token delivery channels
• Enable or disable MFA policies
• Manage token attributes and session validation

This package enables centralized MFA governance while maintaining operational simplicity.

Why MFA Matters for Cloud Databases

Cloud databases are constantly exposed to risks such as:

• Credential theft
• Password reuse attacks
• Unauthorized privileged access
• Insider threats

By introducing MFA, organizations can significantly reduce the attack surface and strengthen compliance with modern security frameworks and regulatory standards.

For enterprises hosting critical ERP, financial, healthcare, or customer data in Oracle Autonomous AI Database, MFA becomes an essential component of a defense-in-depth security strategy.

Additional Security Benefits in Oracle AI Database

Oracle continues to strengthen its database security portfolio with features such as:

• TLS 1.3 support
• SQL Firewall
• Enhanced auditing
• Stronger password policies
• Improved encryption capabilities
• IAM integration for centralized access control

Optimizing OCI IAM Policies Across Compartment Hierarchies

Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) enables organizations to securely control access to cloud resources. A critical aspect of IAM in OCI is how policies behave within a compartment hierarchy, particularly in large-scale enterprise environments.

As OCI deployments grow, managing IAM policies effectively becomes essential to ensure scalability, compliance, and operational efficiency.

Understanding Policy Evaluation in a Hierarchy

OCI evaluates IAM policies from the root compartment down through each level of the compartment structure. Every policy statement attached to the root or to intermediate compartments contributes to the total number of statements evaluated along a path from the root to a specific leaf compartment.

Key implications of this model include:

• Policies defined at the root compartment apply broadly and affect all child compartments.

• Policies defined in lower-level compartments impact only their respective branches.

• OCI enforces a limit of 500 policy statements per compartment hierarchy path.

If the accumulated policy statements along a path exceed this limit, operations such as creating, updating, or deleting policies may fail.

Why Policy Limits Matter

As organizations introduce additional compartments to segregate workloads, teams often create policies independently to meet their operational needs. Over time, this leads to:

• Redundant policy statements

• Overlapping access grants

• Excessively granular permissions

• Increased administrative complexity

When the total evaluated statements exceed the allowed limit, policy changes can fail unexpectedly, impacting governance and agility.

Best Practices for Managing IAM Policies

To maintain a scalable and efficient IAM framework, consider the following structured approach:

1. Eliminate Redundant or Unused Policies

Review existing policies for overlapping permissions. For example:

• Avoid defining both read and manage permissions separately when manage already includes read.

• Consolidate multiple statements granting similar permissions to the same group.

Periodic cleanup significantly reduces policy statement count.

---

2. Define Policies at the Appropriate Compartment Level

Root-level policies affect every branch of the hierarchy. Where possible:

• Move policies closer to the target compartments.

• Restrict scope to the minimum required hierarchy path.

This reduces unnecessary inheritance and keeps the evaluation path efficient.

3. Consolidate and Simplify Policy Statements

Instead of writing multiple narrowly scoped permissions, use broader resource families where appropriate. For example:

• Replace multiple individual resource permissions with a single family-level permission.

• Standardize policy patterns across business units.

Simplification improves both maintainability and scalability.

4. Leverage Tag-Based Access Control

Attribute-based access control using defined tags can significantly reduce policy sprawl. By applying consistent tagging strategies:

• Policies can reference tags instead of compartments.

• Access can scale without creating additional compartment-specific statements.

This approach supports large, dynamic environments effectively.

Conclusion

IAM policy management in OCI is not merely a configuration activity — it is a governance discipline. Understanding how policies accumulate within a compartment hierarchy is crucial to preventing operational constraints.

By removing redundancy, scoping policies appropriately, simplifying statements, and leveraging tag-based access control, organizations can maintain a secure, scalable, and efficient IAM framework.

Proactive policy governance today prevents scalability challenges tomorrow.

Understanding the OCI Policy Analysis Tool: An Overview

Managing identity and access in large Oracle Cloud Infrastructure (OCI) environments can be complex. As organizations scale, so does the number of compartments, groups, dynamic groups, and policy statements. Assessing who can do what—across thousands of permissions—can quickly become challenging, especially for administrators tasked with strengthening security and reducing risk.

To address these challenges, the OCI Policy Analysis Tool has emerged as an essential utility for OCI administrators and security practitioners. Designed to help visualize, interpret, and analyze OCI Identity and Access Management (IAM) policies, this tool provides clarity and insight into effective permissions across your cloud tenancy. 

---

What Is the OCI Policy Analysis Tool?

The OCI Policy Analysis Tool is an unofficial, open-source application targeted at users who need a deeper understanding of their OCI IAM posture. It goes beyond simple policy listing by loading all relevant identity and policy data and organizing it into a cohesive, searchable format. This empowers administrators to answer questions such as:

• Which principals have excessive privileges in sensitive compartments?

• Why is a particular service unable to perform an expected action?

• How have policies changed over time? 

Built entirely with Python and leveraging the OCI Python SDK, the tool demonstrates how custom scripts and utilities can be authored to fill functional gaps and make cloud security operations more manageable. 

---

Key Capabilities and Features

Once loaded with the necessary data from your tenancy or a compliance extract, the OCI Policy Analysis Tool provides several analytical and visibility features:

• Policy Browser: Explore and search policy statements across all compartments.

• Policy Analysis: Filter and inspect parsed IAM policies, including subjects, actions, resources, and conditions.

• Dynamic Group Insights: Review dynamic group matching rules to identify misconfigurations or unused groups.

• User & Resource Principal Analysis: Determine effective permissions for users and resources based on group memberships.

• Cross-Tenancy View: Analyze global policy statements such as Define, Admit, and Endorse.

• Historical Comparison: Compare policy sets at different points in time to detect changes or anomalies.

These features are accessible through an intuitive, tabbed interface that helps administrators quickly locate information and understand complex relationships within IAM configurations. 

---

Additional Utility Functions

Beyond policy inspection, the tool offers usability enhancements that improve flexibility and extend analysis capabilities:

• Caching: Load and save OCI policy and identity data locally for offline analysis.

• Export / Import: Export analysis results to CSV or JSON for reporting or auditing.

• Compliance Script Integration: Import data from standard compliance scripts to enrich policy insights.

• AI-Assisted Insights: Receive natural-language explanations and risk annotations for policy statements.

• Contextual Help: Each view provides embedded help to explain the relevance of data fields or features.

---

Advanced Analysis & Simulation

For deeper investigations, the tool also incorporates powerful extensions:

• API Simulation: Test hypothetical API calls as specific principals to determine allowed or denied actions.

• Policy Recommendations: Generate suggested remediation steps based on detected misconfigurations or over-privileged access patterns.

• MCP Server Integration: Expose your OCI tenancy data to tools such as VS Code or generative AI systems for interactive analysis.

---

Getting Started

There are two main ways to run the OCI Policy Analysis Tool:

1. Direct Python Execution:

   • Ensure Python 3.12 or newer is installed.

   • Create and activate a virtual environment.

   • Install the tool dependencies and run the UI program through Python.

   • Load your OCI configuration or authenticate using an instance principal. 

2. Packaged Executable:

   • Download the binaries from the project’s GitHub releases.

   • Launch the platform-specific executable and follow on-screen prompts.

Once started, you can import tenancy data and begin exploring policies, dynamic groups, and user permissions from a consolidated view.

---

Conclusion

In complex OCI deployments, maintaining an accurate understanding of IAM policies and the effective permissions they grant is essential for security and compliance. The OCI Policy Analysis Tool provides administrators with a comprehensive way to visualize, analyze and assess policy configurations across an entire tenancy. Whether it’s identifying over-privileged users or tracking changes over time, this tool transforms raw policy data into actionable insights. 

Part 1 of this series focuses on the tool and how to get started; an upcoming Part 2 will explore the development journey and strategy behind the tool’s creation.

Bring Your Own Certificate Authority (BYOCA) in OCI

Security and trust are foundational requirements for modern enterprise IT environments. Many organizations have invested heavily in mature Public Key Infrastructure (PKI) systems to support thousands of applications, meet regulatory mandates, and uphold long-standing trust chains. Rebuilding these systems for cloud deployments can be costly, complex, and disrupt established governance models.

To address this challenge, Oracle has introduced Bring Your Own Certificate Authority (BYOCA) for Oracle Cloud Infrastructure (OCI) Certificates. This feature enables enterprises to integrate their existing Certificate Authority (CA) infrastructure directly with OCI without relinquishing control of sensitive private keys. 

Why Bring Your Own CA Matters

Traditionally, OCI Certificates allowed customers to build PKI hierarchies in the cloud, create CAs, and manage certificate lifecycles with automation. However, many enterprises already operate trusted root CAs that are deeply embedded in internal and external systems. Migrating or recreating these root hierarchies in the cloud can pose operational, compliance, and risk management challenges—especially for organizations in highly regulated industries. 

With BYOCA, OCI now provides a mechanism to retain existing trust chains while leveraging cloud automation and lifecycle management. Enterprises can extend their on-premises PKI into the cloud in a secure and controlled manner, preserving compliance and ensuring uninterrupted trust continuity. 

How It Works

BYOCA allows you to import an existing root CA certificate into OCI Certificates simply by providing the PEM-encoded certificate. Importantly:

• Private keys remain under your exclusive control and are never uploaded to OCI.

• OCI registers the imported certificate as an externally managed root CA while maintaining trust relationships with existing PKI infrastructure.

• You can generate subordinate Certificate Authorities (sub-CAs) in OCI by signing certificate signing requests (CSRs) externally and then uploading the signed subordinate certificates to OCI.

• Once activated, these sub-CAs can issue certificates using secure, OCI-managed keys protected within OCI Vault and HSM infrastructure. 

This model bridges existing enterprise PKI investments with cloud automation and lifecycle management capabilities. It enhances interoperability across hybrid and multi-cloud deployments, enabling consistent certificate issuance and trust configurations across environments. 

Enterprise Benefits

The BYOCA approach delivers several advantages:

• Leverage Existing Investments – Continue using established PKI policies, trust anchors, and governance frameworks without redesigning root hierarchies for the cloud. 

• Improved Compliance and Governance – Maintain strict separation of duties, regulatory compliance, and audit requirements while integrating with OCI’s certificate lifecycle automation. 

• Hybrid and Distributed Workloads – Easily support hybrid infrastructure, multi-cloud architectures, and distributed systems with consistent trust configurations. 

• Operational Efficiency – Delegate the operational burden of subordinate CA lifecycle management to OCI while controlling root trust policies internally.

Getting Started

Importing and using BYOCA in OCI Certificates involves a few key steps:

1. Import your external root CA certificate (PEM format) into OCI Certificates without exposing private keys. 

2. Create subordinate CAs in OCI by generating CSRs and signing them with your root CA. 

3. Upload the signed subordinate CA certificates to OCI and activate them for certificate issuance. 

Once configured, OCI Certificates can issue and manage certificates from these subordinate CAs, bringing the best of cloud automation together with trusted enterprise PKI. 

Beyond Allow Policies: How OCI IAM Deny Policies Enhance Access Control and Risk Management

Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) traditionally follows an implicit deny model, where access is denied unless explicitly allowed. While this approach is effective, modern cloud governance often requires explicit guardrails to prevent sensitive actions—even when broad permissions exist. To address this need, OCI introduced IAM Deny Policies, enabling administrators to explicitly block specific actions and enforce stronger security controls.

---

What Are IAM Deny Policies?

IAM deny policies allow organizations to explicitly prohibit actions, overriding any existing allow policies. If a deny policy matches a request, the action is blocked regardless of other permissions. This capability is particularly valuable for enforcing governance standards, regulatory compliance, and operational safety in critical environments.

Deny policies are especially useful in large tenancies with multiple teams, compartments, and environments where broad access is necessary but unrestricted permissions could lead to accidental or unauthorized changes.

---

Key Characteristics

Explicit Opt-In

Deny policies are disabled by default and must be explicitly enabled by a tenancy administrator. Once enabled, the feature cannot be disabled, highlighting the need for careful planning before activation.

Administrator Protection

To prevent accidental lockouts, the default Administrators group in the default identity domain is exempt from deny policies. This ensures that core administrative access remains available even if restrictive deny rules are configured.

Policy Evaluation Order

During policy evaluation, deny policies take precedence over allow policies. If both apply to the same request, the deny rule always wins.

---

Policy Syntax Overview

Deny policies use the same structure as standard IAM policies, replacing allow with deny. This consistency makes them easy to understand and manage.

Example:

deny group DevTeam to manage bucket-family in compartment Prod
where request.operation = 'DeleteBucket'

This statement prevents the DevTeam group from deleting buckets in the production compartment, even if they have broader storage permissions.

---

Common Use Cases

Protecting Production Environments

Deny policies are ideal for preventing destructive actions such as deleting VCNs, databases, or object storage in production compartments.

Enforcing Separation of Duties

Organizations can restrict sensitive operations to specific teams by explicitly denying them to others, reinforcing clear responsibility boundaries.

---

Best Practices

• Enable deny policies only after governance review and testing.

• Keep deny statements narrow and condition-based to avoid unintended impact.

• Regularly review deny policies as environments and teams evolve.

• Document deny policies clearly to support audits and operational transparency.

---

Conclusion

OCI IAM Deny Policies add a powerful layer of control to cloud access management. When used thoughtfully, they help organizations protect critical resources, reduce operational risk, and enforce governance without sacrificing flexibility. As OCI environments grow in scale and complexity, deny policies become an essential tool for secure and disciplined cloud operations.

Oracle AI Database 26ai – What It Means for Oracle E-Business Suite

At Oracle AI World 2025 in Las Vegas, Larry Ellison announced the launch of Oracle AI Database 26ai (26ai) — the next evolution of Oracle Database, bringing AI-driven capabilities into the core database engine. This announcement marks a key milestone for both the Oracle Database and Oracle E-Business Suite (EBS) communities.

---

🔑 Key Highlights from the Announcement

• New Naming Convention: Oracle Database is now officially referred to as the Oracle AI Database.

• 26ai Replaces 23ai: Oracle AI Database 26ai supersedes Oracle Database 23ai, becoming the latest long-term release.

• No Architectural Changes: DB 26ai builds on 23ai with no changes to the internal architecture or APIs.

• Smooth Transition:

  • If you’re on Oracle Database 23ai, simply apply the October 2025 Database Release Update (DBRU).

  • If you’re on 19c or earlier, a standard upgrade is required to move to 26ai.

• Updated Documentation: Oracle’s database documentation and release materials now reference DB 26ai instead of DB 23ai.

• New Release Numbering: Oracle has updated its database release numbering with the introduction of 26ai.

For detailed platform availability, refer to:
📘 Release Schedule of Current Database Releases (Doc ID 742060.1)

---

💡 Impact on Oracle E-Business Suite

For Oracle E-Business Suite (EBS) customers:

• All EBS documentation will be updated to replace mentions of “Oracle Database 23ai” with “Oracle AI Database 26ai.”

• During this transition, you may see references to both names in parallel, but once updates are complete, only Oracle AI Database 26ai will appear across official documentation.

---

Oracle AI Database 26ai represents the next step in integrating AI-driven performance, automation, and insight into Oracle’s enterprise database platform—ensuring that EBS customers can continue to innovate with a future-ready, AI-enhanced foundation.

---

📅 Quarterly Upgrade Highlights: EBS August 2025

Oracle’s August 2025 update provides key recommendations for EBS environments and accompanying technology components. (Oracle Blogs)

✅ Core Platform Guidance

• EBS 12.2 remains in Premier Support through at least December 2036. 

• Older versions (EBS 12.1, 12.0, 11.5.10) are in sustaining support and no new patches will be released—migration to 12.2 is strongly recommended. 

🔧 Patching & Baselines

• Minimum patch baseline for EBS 12.2 should be Patch 24690690 (or equivalent) as of July 1 2024. 

• Apply the latest suite-wide Release Update Pack (RUP)—version 12.2.14 (Sept 2024) or 12.2.13 (Nov 2023). 

🧰 Technology Stack & Tools

Ensure these components are up to date:

• AD/TXK Delta version 16 (July 2024)

• OAF Bundle releases (ex: 12.2.14 OAF Bundle 3 as of Aug 2025)

• Deploy the latest desktop/client tier components: JRE 1.8.0_461, certified browsers, transition from IE 11 to Edge.

---

📝 Why This Matters

Adhering to these recommendations keeps your EBS environment secure, supported, and optimized. Lower patching risk means better stability, stronger compatibility, and clearer upgrade paths. For older EBS versions, the message is clear: migrate to 12.2 now to avoid unsupported environments.

---

🔗 For full details and the complete list of stack-specific recommendations, you can read the original blog here: https://blogs.oracle.com/ebstech/post/quarterly-ebs-upgrade-recommendations-august-2025

Schedule an In-Place Upgrade to Oracle Database 23ai on Autonomous Database

 

Oracle Autonomous Database now supports in-place upgrades from Oracle Database 19c to 23ai using scheduled upgrades—a seamless, automated process tailored for modern cloud environments.

Upgrade Options Available:

• Scheduled Upgrade
  Define your preferred time, and the upgrade process runs automatically—no manual steps needed.

• Full Clone Upgrade
  Create a full clone of your 19c database and select 23ai during the clone setup to instantiate a new, upgraded instance.

• Refreshable Clone Upgrade
  Similar to a full clone but allows ongoing synchronization between the 19c source and 23ai clone—ideal for ensuring minimal downtime and continuous updates.

---

At a Glance

Upgrade Method	Description
Scheduled Upgrade	Automated upgrade of an existing 19c Autonomous DB.
Full Clone	Creates a brand-new 23ai clone from 19c.
Refreshable Clone	Creates a 23ai clone that syncs with the source 19c DB.

---

Upgrading to Oracle Database 23ai on Autonomous Database has never been more straightforward. Whether you choose a scheduled upgrade or cloning, you control the transition timing and method with minimal disruption.

OCI File Storage with Lustre: High-Performance, Managed File System for AI

Oracle Cloud Infrastructure (OCI) offers File Storage with Lustre—a fully managed, high-performance file system tailored for demanding workloads such as AI, machine learning, and high-performance computing (HPC).

Key Highlights:

• Fully Managed Infrastructure
  OCI handles deployment, maintenance, scaling, and management of Lustre components—including metadata servers, management servers, and storage servers—letting you focus on your applications, not infrastructure. 

• Parallel and Distributed Architecture
  Designed for massive data volumes, this system delivers high aggregate throughput by distributing I/O workload across server components. 

• Performance Tiers for Flexibility
  Choose from different bandwidth configurations:

  • 125 MB/s per TiB (1 Gbps)

  • 250 MB/s per TiB (2 Gbps)

  • 500 MB/s per TiB (4 Gbps)

  • 1000 MB/s per TiB (8 Gbps)
    Administrators can also tweak performance using Lustre's lfs tools, including features like file striping and Progressive File Layout (PFL). 

• Client Compatibility
  OCI supports Lustre version 2.15.5. Compatible client environments include:

  • Ubuntu 22.04 (kernel 5.15.x)

  • Oracle Linux 8 (RHCK 4.18)

• Global Availability
  This service is available across multiple OCI regions (at the time of writing this blog) —such as Sydney, Frankfurt, São Paulo, Montréal, Tokyo, Amsterdam, and more—ensuring localized access and compliance. 

---

Bottom Line:

OCI File Storage with Lustre provides a scalable, high-throughput file system custom-built for data-intensive workloads. With its fully managed infrastructure and multiple performance configurations, it’s an ideal fit for running AI training jobs which needs high performance computing needs.

EBS 12.2.14: Key Enhancements by Product Family

 Financial Management

• ECC: GL, AR, iReceivables, iReceipts, Assets, Cash Management, Lease Contracts, Leases & Finance

• Equipment Leasing for IFRS 16/ASC 842/SFFAS 54

• GL & AP Approval Flexibility & Automation

• AR: New Cash Receipt Application Methods

• Enhanced Credit Scoring & Collections

• Lease & Finance: Increased Throughput Across Processes

---

Procurement

• Modern Shopping Minimizing Non-Catalog Spend

• ECC: Procurement, Project Procurement, CLM

• Procurement & Contract Efficiencies

• Supplier Portal: Advanced Configurability

• Supplier Management & Assessments

• Services Procurement: Invoicing & Complex Payments

• Project Procurement

• Sourcing Streamlined Flows

• Proc/Proj: G-Invoicing for US Federal Program Agencies

---

Projects

• ECC Projects

• Labor Costing with Actual Costs

• Budgetary Control for Labor & Non-Labor Transactions

• Enhanced Cost Accounting Adjustment Options

• Enhanced Billing including Federal Billing & Bill Groups

• Enhanced Revenue Recognition for IFRS 15 / ASC 606

• Scheduled % of Work Completed Based Structure

• Enhanced Project Planning & Controls

• Proc/Proj: G-Invoicing for US Federal Program Agencies

---

Applications Technology

• ECC Dashboards

• EBS on Oracle Cloud Infrastructure (OCI): EBS Cloud Manager

• Enterprise Command Center Framework

• Enhanced UX with OAF & WebADI

• Enhanced Oracle APEX Integration for EBS Customizations

• Oracle Guided Learning (OGL) Integration with EBS

• Customer Driven Enhancements

---

Order Management

• ECC: Order Management, Advanced Pricing, iStore, CHRM, OIC

• New HTML UIs

• Enhanced Subscription & Service Ordering

• Advanced Scheduling, Milestone, Usage Based

• Enhanced Returns (ISO) Processing

• Improved Cancellations, Performance, & Archival

• Enhanced Quoting Creation, Validation & Approval

• Enhanced Flexible Volume Pricing, Enhanced Financial Control

---

Logistics

• ECC: Inventory Mgmt, Landed Cost Mgmt

• UX: New HTML UIs

• ECC for Android and iOS enhancements

• Material Flow Mapping & Physical Inventory

• Enhanced Material Tracking

• Bin Optimization, Backorders, & Inter-Org Transfer (IOT)

• On Time In Full (OTIF)

• ECC: Receiving Efficiencies, Pick by More Docs, Yard Mgmt

• WMS/MSCA: Activity Tracking incl User-Defined Activities

---

Manufacturing

• ECC: Discrete Mfg, Process Mfg, Project Mfg, Outsourced Mfg

• ECC: Cost Mgt, OPM Analytics, Quality, BOM

• Discrete Mfg: Rework Work Orders, Dual UOM for Mfg, MES, Internet of Things, E-Kanban, Serialization

• Project Mfg: Procurement Availability Mgmt, Outsourced Mfg, MES, Item Genealogy

• Process Mfg: Equipment Availability & Utilization, Asset Integration, Serialization, Batch Genealogy, Lab Mgmt

• Quality: Enhanced Quality Collection & ECC Control

---

Asset Lifecycle Management

• ECC: EAM, Asset Tracking

• Mobile Maintenance App

• EAM: Linear Asset Management

• EAM Map Visualization for Assets & Work; Indoor Maps

• EAM: Central Maintenance Technician Assignment

• EAM: Functional Asset Hierarchy

• EAM: Enhanced Work Task Functionality & Productivity

• Installed Base & Asset Tracking Enhanced Flows

---

Service

• ECC: Service Contracts, Service, Field Service, Depot

• New HTML UIs

• Service Contracts: Enhanced Usage Billing w/Group Plans

• ECC: Improved MOAC & Inventory Org Security

• Enhanced SR Definition: Multiple Products on 1 SR, more

• Field Service Integration w/Projects; Enhanced DTL Integration

• Depot: Warranty, Waste Mgt, Outsourced Repair, Prescriptive Recommendations

---

Human Capital Management

• ECC: Human Resources, Payroll

• Mobile Apps: SSHR, OTL

• Time & Labor: Enhanced Entry & Processing

• Payroll: Enhanced Administration & Processing

• SSHR: Mass Update by Mgmt, Surrogate Approvers

• HTML Dashboards for Payroll & SSHR Admin

• Person Data Removal Tool (PDRT)

Recover Accidentally Deleted APEX Components Using Flashback Export

Deleting a page or shared component in Oracle APEX by mistake can be frustrating—but recovery is possible if you act quickly.

Why Flashback?

• Instead of relying on full database recovery (which is time-consuming and resource-intensive), APEX offers a Flashback Export option that utilizes Oracle’s Flashback Query technology via the Undo tablespace.

• How It Works:

  • Flashback Export is available for applications, pages, and components.

  • To recover a deleted page, create a dummy page with the same number, then export it using the Flashback Time setting.

  • Import the exported file—APEX will prompt to overwrite the dummy with the restored original.

• For Shared Components:
  If shared components were also deleted, export the entire application using the Flashback option and import it:

  • With the same App ID (overwrites the original app).

  • Or with a new App ID (lets you manually copy components from the flashback version).

• Best Practice:
  Schedule regular exports and store them in source control (e.g., Git), ensuring long-term recovery options—even for changes lost days or weeks ago.

Reference:

https://apex.oracle.com/pls/apex/germancommunities/apexcommunity/tipp/5921/index-en.html

Configuring Oracle Enterprise Manager for Active Directory Authentication

 This post outlines the steps to integrate Oracle Enterprise Manager (OEM) with Microsoft Active Directory (AD) for centralized user authentication. By enabling LDAP-based authentication, administrators can manage user access through AD without creating separate users in OEM.

Key Highlights:

• OEM and AD Integration: Leverages Oracle WebLogic Server’s security providers to authenticate users against Active Directory.

• Configuration Steps:

  • Update the WebLogic security realm to add a new LDAP authenticator for AD.

  • Specify connection details such as host, port, and base DN.

  • Set control flag and user/group attribute mappings.

• Testing: Validate the integration by logging in to OEM using AD credentials.

• Fallback Access: Keep the default weblogic or local OEM user credentials active for administrative access in case of integration issues.

Reference:

https://blogs.oracle.com/ateam/post/configure-oracle-enterprise-manager-for-active-directory-authentication