Oracle Cloud Infrastructure Documentation

Enterprise Performance Management

Oracle Hyperion is an Enterprise Performance Management( EPM) platform used by finance teams for financial close, consolidation, planning, budgeting, forecasting, and profitability analysis. Core Hyperion modules such as HFM (Hyperion Financial Management), Planning, Oracle Essbase, and Financial Reporting rely on a highly available Oracle AI Database backend to store metadata, transactional data, and calculation results.

This documentation describes the reference architecture for running Oracle Hyperion in Microsoft Azure, using Oracle AI Database@Azure for the database layer and Azure virtual machines for the Hyperion web, application, and Oracle Essbase tiers. This architecture provides a low-latency configuration because Oracle AI Database services are deployed within the same Azure data center, supporting optimal performance for financial close, planning, and consolidation workloads.

Currently, Oracle Exadata Database Service on Dedicated Infrastructure, Oracle Exadata Database Service on Exascale Infrastructure, and Oracle Base Database Service are supported with Oracle AI Database@Azure. You can check regional availability matrix to determine supported services by OCI and Azure regions.

This document is intended for cloud architects, infrastructure administrators, and Oracle Enterprise Performance Management administrators responsible for designing, deploying, and operating Hyperion environments. Familiarity with Oracle Hyperion applications, Oracle AI Database(s), Oracle Cloud Infrastructure (OCI), and Microsoft Azure is recommended.

Architecture

This architecture demonstrates the deployment of Oracle Hyperion applications within a single Azure region. For disaster recovery (DR) deployments, a similar architecture can be implemented across multiple Azure regions to support business continuity requirements. The database tier can be configured using Oracle Active Data Guard with Oracle Database@Azure. The Oracle Hyperion application stack including web, application, and Essbase components can use file synchronization mechanisms such as rsync to replicate application artifacts, configuration files, and shared file systems across regions.

For more information on designing and implementing disaster recovery architectures, see Oracle Maximum Availability Architecture for Oracle AI Database@Azure.

This screenshot shows the architecture diagram.

This architecture deploys all components within a single Azure region and highlights important design considerations for Oracle Hyperion on Azure with Oracle AI Database@Azure.

Networking Tier

This architecture shows a single Azure region deployment of a Oracle Hyperion environment designed to ensure low-latency connectivity. The networking layout consists of an Azure Virtual Network (VNet) with dedicated subnets for Azure Bastion, load balancer, Oracle Hyperion web servers, application servers, and the database tier.

The database layer uses Oracle AI Database@Azure, which must be deployed in an Azure delegated subnet. Oracle AI Database@Azure services can be provisioned only in delegated subnets assigned to Oracle. Connectivity to on-premises environments can be established using Azure ExpressRoute for private, low-latency access.

The Azure Bastion host is deployed in a subnet with a public IP address, while all other Oracle Hyperion and database components reside in subnets without public IP addresses. Public IP addresses can be attached to specific instances based on business or operational requirements. Secure access to private instances is provided over port 22 (SSH) through Azure Bastion or via Azure ExpressRoute when direct connectivity to on-premises data centers is configured.

Oracle Hyperion application components are deployed across single Availability Zone to ensure low latency connectivity. The database is deployed in a single Availability Zone with Oracle RAC enabled by default. For regional redundancy, the database can be deployed in a second Availability Zone using Oracle Data Guard, providing high availability and disaster recovery at the regional level.

Networking Design Considerations
  • When planning IP address space, account for Oracle AI Database@Azure subnet requirements and address space consumption scenarios.
  • Plan DNS configuration carefully, especially when using custom DNS resolvers, to support Oracle AI Database@Azure DNS resolution requirements.
  • For multi-region disaster recovery architectures, consider detailed network connectivity patterns and inter-region routing for Oracle AI Database@Azure.
  • Review backup and recovery prerequisites early in the design phase to ensure network access requirements are met.
  • Use Network Security Groups (NSGs) to restrict access to database virtual machines:
    • Allow SSH (port 22) access only through Azure Bastion.
    • Allow database traffic (port 1521) exclusively from approved Oracle Hyperion application subnets and authorized on-premises networks.

Bastion Host

Azure Bastion is a fully managed service that provides a secure and controlled administrative access point to the Azure virtual network hosting Oracle Hyperion workloads.

Azure Bastion is deployed in a dedicated subnet (AzureBastionSubnet) and provides secure, private access to virtual machines in subnets without public IP addresses, ensuring they are not directly exposed to the public internet. By using Azure Bastion, the architecture maintains a single, known access point that can be centrally monitored and audited, while avoiding the need to expose public IP addresses or open inbound ports on individual virtual machines.

In this architecture, Azure Bastion does not require a public IP address on the target virtual machines. Administrative access is established over TLS (port 443) through the Azure portal or supported native clients. Network Security Groups on the target subnets do not require inbound SSH or RDP rules, which reduces the attack surface. Access to Azure Bastion can be restricted and managed using Azure role-based access control (RBAC) and Azure Active Directory authentication.

Azure Bastion enables administrators to connect to virtual machines without public IP address in subnets using SSH for Linux and RDP for Windows. Connections are initiated from the administrator’s local workstation and proxied through the Bastion service, ensuring that credentials and sessions are not exposed to the public network.

By centralizing administrative access and eliminating direct VM exposure, Azure Bastion enhances security while maintaining operational access to private workloads.

Oracle Hyperion Application Tier

All components in the Oracle Hyperion application tier are configured to connect to active Oracle Database instances deployed on Oracle Database@Azure. The application tier hosts the core Oracle Hyperion EPM services responsible for financial consolidation, planning, analytics, data integration, and financial close management. These components are distributed across multiple virtual machines to support high availability, scalability, and security.

The Hyperion application tier includes the following core components:
  • Core Hyperion EPM Components
    • Foundation Services:

      Provides the shared infrastructure layer for Hyperion EPM, including user provisioning, security, authentication, metadata management, and lifecycle management. Foundation Services enables centralized governance across all Hyperion applications.

    • Hyperion Financial Management (HFM):

      A web-based application used for financial consolidation, statutory reporting, and financial analysis. HFM supports complex ownership structures, currency translation, inter-company eliminations, and audit controls.

    • Hyperion Planning:

      Supportsenterprise budgeting, forecasting, and driver-based planning. Planning applications enable scenario modeling, workflow approvals, and integration with calculation rules for what-if analysis.

    • Oracle Essbase:

      A high-performance multidimensional analytic server that enables fast aggregations, calculations, and ad-hoc analysis. Essbase underpins many planning, forecasting, and reporting use cases.

    • Financial Data Quality Management, Enterprise Edition (FDMEE):

      Manages data integration and data quality, including mapping, validation, and loading of financial data from source systems into Hyperion applications.

    • Profitability and Cost Management:

      Enables cost allocation, profitability analysis, and performance measurement across products, customers, channels, and business units.

    • Financial Close Management (FCM):

      Financial Close Management orchestrates and monitors the end-to-end financial close process by managing tasks, dependencies, approvals, and reconciliations. It provides real-time visibility into close status, enforces standardized close procedures, and supports audit-ability across entities and reporting periods.

    • Tax Management:

      Hyperion Tax Management supports tax provisioning, compliance, and reporting by centralizing tax calculations and data collection. It enables organizations to manage current and deferred tax positions, comply with regulatory requirements, and reduce manual effort through automated work-flows and controls.

    • Financial Reporting:

      Hyperion Financial Reporting delivers highly formatted, production-quality financial statements, management reports, and disclosures. It supports statutory, regulatory, and management reporting requirements, with reusable report definitions and secure access across finance stakeholders.

  • Web and Application Server Components
    • Oracle HTTP Server (OHS):

      Acts as the web entry point for Hyperion EPM applications, handling incoming HTTP/HTTPS requests and typically fronted by an Azure Load Balancer.

    • Oracle WebLogic Server:

      Hosts Hyperion EPM web applications and services, including Foundation, Planning, HFM, FDMEE, and Workspace components. WebLogic domains are commonly deployed across multiple nodes for high availability.

  • Azure File Storage:

    It is used to host shared Hyperion software binaries, configuration files, logs, and application artifacts. A centralized file system can be mounted across Hyperion web, application, and Oracle Essbase servers to ensure consistency and simplify software maintenance. Azure Files Premium is recommended instead of Azure Files Standard to deliver higher throughput and lower latency.

Database Tier

For high availability requirements, we recommend using one of the following Oracle AI Database@Azure options to set up Oracle Hyperion database instances:
  • Oracle Exadata Database Service on Dedicated Infrastructure
  • Oracle Exadata Database Service on Exascale Infrastructure
  • Oracle Base Database Service
    Note

    Oracle Base Database Service is only recommended for development or sandbox instances.

The database instances are configured for high availability with Oracle Real Application Clusters (RAC) enabled. To achieve availability zone redundancy for the database, use Oracle Active Data Guard in synchronous mode to replicate the database across availability zones.

A prerequisite for Active Data Guard is to establish a private networking path between availability zones, either through:
  • Azure backbone connectivity using VNet peering, or
  • OCI backbone connectivity using VCN peering with Local Peering Gateways

Port 1521 is used for database connectivity and for Oracle Active Data Guard redo transport services, which transmit redo logs between primary and standby databases. For detailed networking design considerations, see Maximum Availability Architecture (MAA).

Backup and Recovery

Automated database backups can be configured using Oracle Autonomous Recovery Service or OCI Object Storage, depending on the selected database service and recovery requirements.

Data Encryption

For data in transit, Oracle AI Database@Azure services are accessible only through encrypted communication channels. By default, the Oracle Net client is configured to use encrypted sessions, ensuring that all database connections are protected in transit.

Oracle AI Database@Azure protects data at rest using Transparent Data Encryption (TDE), which is enabled by default with no customer configuration required. TDE automatically encrypts database files, redo and undo logs, backups, and other persistent data when written to storage, and transparently decrypts the data when accessed by authorized processes. Encryption is managed using a hierarchical key model, where a master encryption key protects tablespace keys that in turn encrypt the data.

Oracle AI Database@Azure supports both Oracle-managed and customer-managed key options for TDE. With Oracle-managed keys, encryption keys are generated, stored, and managed automatically by Oracle. With customer-managed keys, customers can centrally control key lifecycle management, rotation, and auditing by integrating with OCI Vault, Oracle Key Vault, or Azure Key Vault (AKV).

Note

Cross-region Oracle Data Guard is not supported when customer-managed encryption keys are stored in Azure Key VaultAzure Key Vault (AKV)

Migration to Oracle AI Database@Azure

Oracle Zero Downtime Migration (ZDM) provides multiple migration work-flows for moving Hyperion databases to Oracle AI Database@Azure.

Migration to Exadata Database, Exascale Database, and Base Database
  • Physical Online Migration:

    The physical online migration work-flow supports migrations between the same database versions and platforms. This approach uses direct data transfer and the restore from service method to create the target database, avoiding the use of intermediate backup storage. Oracle Data Guard is used to keep the source and target databases synchronized, enabling minimal-downtime migration.

  • Physical Offline Migration:

    The physical offline migration work-flow supports migrations between the same database versions and platforms. The target database is created using Recovery Manager (RMAN) backup and restore. Azure Files is used to provide an NFS file share for storing RMAN backup files during the migration process.

  • Logical Online Migration:

    The logical online migration work-flow supports migrations between the same or different database versions and platforms. This work-flow uses Oracle Data Pump export and import to create the target database. Azure Files provides an NFS file share to store the Data Pump dump files. Oracle GoldenGate is used to synchronize the source and target databases, enabling minimal-downtime migration.

  • Physical Online Migration:

    The logical offline migration work-flow supports migrations between the same or different database versions and platforms. The target database is created using Oracle Data Pump export and import. Azure Files provides an NFS file share to store the Data Pump dump files used during the migration.

Components Overview

Component Purpose
Oracle AI Database@Azure Oracle AI Database@Azure provides Oracle Exadata Database deployed and operated in Azure with native Azure integration. It combines Oracle Exadata Database performance and Oracle AI Database capabilities with Azure networking, security, and consumption models. The offering includes Oracle Exadata Database, Oracle Exadata Database Service on Exascale Infrastructure and Oracle Base Database Service for hosting database layer for Oracle Hyperion.
Azure Load Balancer Azure Load Balancer distributes incoming traffic across web or application servers and continuously monitors back-end health probes to send traffic only to healthy instances. This ensures even traffic distribution, high availability, and automatic failover without application.
Azure Bastion Azure Bastion enables secure RDP and SSH access to virtual machines over HTTPS without requiring public IP addresses. It improves security by centralizing administrative access and reducing exposure to inbound internet threats.
Autonomous Recovery Service Autonomous Recovery Service provides automated backup, continuous data protection, and fast recovery for Oracle AI Database(s). It reduces data loss and recovery time by autonomously managing backups, validation, and restore operations.
Object Storage Object Storage provides durable, scalable storage for unstructured data using a bucket-and-object model. It is commonly used for backups, archival, and data sharing with built-in security and lifecycle controls.
OCI Vault OCI Vault provides centralized management of encryption keys and secrets using Oracle-managed HSMs. It enables strong security, key rotation, and access control for protecting data across OCI services.
Azure Files Azure Files provides fully managed, shared file storage using standard SMB and NFS protocols. It enables applications to access scalable, highly available file shares without managing underlying storage systems.
Azure Key Vault Azure Key Vault is a managed service that provides secure storage and lifecycle management for sensitive information such as secrets, encryption keys, and certificates used by enterprise applications.

Learn more