Learn about Deploying JD Edwards EnterpriseOne on Oracle Cloud Infrastructure

If you want to provision JD Edwards EnterpriseOne on Oracle Cloud Infrastructure or migrate JD Edwards EnterpriseOne environments from your data center to Oracle Cloud Infrastructure, you can plan a multihost, secure, high-availability topology.

Before You Begin

Oracle Cloud Infrastructure supports JD Edwards EnterpriseOne application release 8.12, 9.0, 9.1, and 9.2. Before you begin planning to deploy or migrate your JD Edwards EnterpriseOne application, identify if Oracle Cloud Infrastructure supports the combination of JD Edwards EnterpriseOne application release, JD Edwards EnterpriseOne tools release, and the operating system on which you want to run your applications.

  • JD Edwards EnterpriseOne application release 9.2 with JD Edwards EnterpriseOne Tools release 9.2.x. It supports manual and automated installation of JD Edwards EnterpriseOne components on Oracle Linux and Windows operating systems.

  • JD Edwards EnterpriseOne application release 9.1 with JD Edwards EnterpriseOne Tools release 9.1.x or 9.2.x. It supports only manual installation of JD Edwards EnterpriseOne components on Oracle Linux and Windows operating systems.

  • JD Edwards EnterpriseOne application release 8.12 with JD Edwards EnterpriseOne Tools release 8.98.4. It supports only manual installation of JD Edwards EnterpriseOne components on Windows operating system.

For information about earlier versions of the JD Edwards EnterpriseOne application, contact Oracle Advanced Consulting Services.

Refer to My Oracle Support for the definitive certifications information.

Considerations for Deployment on Oracle Cloud Infrastructure

Oracle recommends creating separate subnets for your instances, such as bastion host, database, application, and load balancer instances to ensure that appropriate security requirements can be implemented across the different subnets.

Private or Public Subnets

You can create instances in a private or a public subnet based on whether you want to permit access to the instances from the internet. Instances that you create in a public subnet are assigned a public IP address and you can access these instances from the Internet. You can’t assign a public IP address to instances created in a private subnet. Therefore you can’t access these instances over the internet.

The following image shows a virtual cloud network (VCN) with public and private subnets. The VCN contains two availability domains, and each availability domain contains a public and private subinet. The web servers are placed in the public subnet in this image, so the web server instances have a public IP address attached to it. You can access these Oracle Cloud instances in the public subnet from the internet by enabling communication through the internet gateway (IGW). You’ll have to update the route table to enable traffic to and from the IGW. To permit traffic to the web servers from the internet, you must create load balancers in the public subnet. To access your instances from the internet, you also need to create bastion host in public subnet and access the bastion host from the IGW.

The database servers are placed in the private subnet in this image. You can access Oracle Cloud instances in the private subnet from your data centers by connecting through the dynamic routing gateway (DRG). The DRG is the gateway that connects your on-premises network to your cloud network. To enable communication between the DRG and the customer-premises equipment, use IPSec VPN or Oracle Cloud Infrastructure FastConnect. You’ll also have to update the route table to enable traffic to and from the DRG.


Description of public_private_subnets_jde.png follows
Description of the illustration public_private_subnets_jde.png
Scenario 1: Deploy All Instances in Private Subnets

Oracle recommends deploying all instances in private subnets for production environments where there are no internet-facing endpoints. This type of deployment is useful when you want to have a hybrid deployment with the cloud as an extension to your existing data centers.

In this deployment, all the instances including application and database servers are deployed in a private subnet. A public IP address can’t be assigned to instances created in a private subnet, so you can’t access these instances over the internet. To access your application servers from your on-premises environment in this configuration, you can:

  • Configure an IPSec VPN tunnel between your data center and Oracle Cloud Infrastructure DRG before provisioning the application servers.

  • Create a bastion host in this configuration, and then access all the servers in private subnet from the bastion host.

Scenario 2: Deploy Instances in Public and Private Subnets

You can deploy a few instances in a public subnet and a few instances in a private subnet. This type of deployment is useful when the deployment includes internet-facing and non-internet facing endpoints.

In this configuration, some application instances are placed in a public subnet, and others are placed in a private subnet. For example, you may have application instances serving internal users and another set of application instances serving external users. In this scenario, place the application instances that serve internal traffic in a private subnet, and place the application servers that serve external traffic in a public subnet. You can also set up a public load balancer on the internet-facing application instances, instead of placing the application servers that serve external traffic in a public subnet. If you place the bastion host in a public subnet, then the bastion host is assigned a public IP address, and you can access it over the internet. You can access your instances in the private subnet through the bastion server.

Scenario 3: Deploy All Instances in Public Subnets

Oracle recommends this deployment for quick demonstrations or for production-grade deployments with no internal endpoints. This deployment is suitable only if you don’t have your own data center, or you can’t access instances over VPN, and you want to access the infrastructure over the internet.

In this deployment, all the instances including the application and database instances are deployed in public subnets.

Every instance in the public subnet has a public IP address attached to it. Although instances with public IP addresses can be accessed over the internet, you can restrict access by using security lists and security rules. For performing administration tasks, Oracle recommends that you place a bastion host in this configuration. In this scenario, you would not open administration ports to the public internet, but rather open the administration ports only to the bastion host and setup security lists and security rules to ensure that the instance can be accessed only from the bastion host.

Anti-Affinity

While creating multiple instances for high availability in an availability domain on Oracle Cloud Infrastructure, the anti-affinity for instances can be achieved by using fault domains.

A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain contains three fault domains. Fault domains let you distribute your instances so that they are not on the same physical hardware within a single availability domain. So, a hardware failure or Oracle Compute hardware maintenance that affects one fault domain does not affect instances in other fault domains. By using fault domains, you can protect your instances against unexpected hardware failures and planned outages.

For high availability of databases, you can create 2-node Oracle Real Application Clusters (Oracle RAC) database systems. The two nodes of Oracle RAC are always created in separate fault domains by default. So, the database nodes are neither on the same physical host nor on the same physical rack. This protects the database instances against the underlying physical host and top of the rack switch failures.

Architecture for Deploying JD Edwards EnterpriseOne in a Single Availability Domain

You can deploy JD Edwards EnterpriseOne in a single availability domain while ensuring high availability. Use this architecture when you want to ensure that your application is available even when an application instance goes down. The other available application instances in the availability domain continue to process the requests. You can deploy JD Edwards EnterpriseOne manually or by using the JD Edwards EnterpriseOne automation tools on Oracle Cloud Infrastructure. Oracle recommends that you use a single availability domain architecture for non-production, demo, and training environments.

This architecture shows that redundant instances are deployed in the presentation tier and middle tier in an availability domain to ensure high availability within the availability domain. All instances in the availability domain are active. This high availability of an application within an availability domain can be achieved by placing application instances in separate fault domains. Fault domains let you distribute your instances so that they are not on the same physical hardware within a single availability domain. A hardware failure or Oracle Cloud Infrastructure Compute hardware maintenance that affects one fault domain does not affect instances in other fault domains. If an instance fails, then the traffic is diverted to other instances in the availability domain that continue to process the requests. However, if your connection to the availability domain fails or the entire availability domain goes down, then the instances are not available to process the requests.

Instances in the private subnet require outbound connection to the Internet to download patches as well as to apply operating system and application updates. For this purpose, use a Network Address Translation (NAT) gateway in your VCN. With a NAT gateway, the hosts in private subnet can initiate connections to the Internet and receive responses, but won’t receive inbound connections initiated from the Internet.

Oracle recommends that the database and the applications deployed on Oracle Cloud Infrastructure should have a robust backup of recovery strategy. It is recommended to store backup of databases and application instances in the Oracle Cloud Infrastructure Object Storage. The databases and application instances in private subnets can be backed up to Oracle Cloud Infrastructure Object Storage by using a service gateway. A service gateway provides access to Oracle Cloud Infrastructure Object Storage without traversing the Internet.

The automatic and on-demand database backups to Oracle Cloud Infrastructure Object Storage can be configured using the Oracle Cloud Infrastructure console. This requires connectivity to Oracle Cloud Infrastructure Object Storage using a Swift endpoint. All database backups on Oracle Cloud Infrastructure Object Storage are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption. The automatic database backup service uses weekly incremental backup strategy to backup databases with a 30-day retention policy. It is also possible to perform an on-demand full backup of databases for ad-hoc requirements.

The backup of application can be configured by using the policy-based backup feature of Oracle Cloud Infrastructure Block Volumes. Oracle Cloud Infrastructure Block Volumes provides you with the capability to perform volume backups automatically based on a schedule and retain them based on the selected backup policy. This allows you to adhere to your data compliance and regulatory requirements. There are three predefined backup policies: Bronze, Silver, and Gold. Each backup policy has a predefined backup frequency and retention period.

The architecture consists of a virtual cloud network (VCN) with the bastion host, load balancer tier, presentation tier, middle tier, administration tier, and database tier. The tiers are placed in separate subnets of the VCN in a single availability domain.

In the following architecture diagram, the bastion host is deployed in a public subnet, and all the other instances are placed in private subnets. Depending on your business requirements, you can place instances in public or private subnets. You can access the instances that are in private subnets over port 22 through the bastion host or the dynamic routing gateway (DRG). To enable communication between the DRG and the customer-premises equipment, use IPSec VPN or Oracle Cloud Infrastructure FastConnect.

The presentation tier and the middle tier communicate with each other and also with the database tier.


Description of single_availability_domain_jd_edwards_deployment.png follows
Description of the illustration single_availability_domain_jd_edwards_deployment.png
This architecture is divided into these tiers:
  • Bastion host: The bastion host is an optional component that can be used as a jump server to access instances in the private subnet. A bastion host is an Oracle Cloud Infrastructure Compute instance that uses Linux as its operating system. Place the bastion host in a public subnet and assign it a public IP address to access it from the Internet.

    To provide an additional level of security, you can set up security lists to access the bastion host only from the public IP address of your on-premises network. You can access Oracle Cloud Infrastructure instances in the private subnet through the bastion host. To do this, enable ssh-agent forwarding, which allows you to connect to the bastion host, and then access the next server by forwarding the credentials from your computer. You can also access the instances in the private subnet by using dynamic SSH tunneling. SSH tunneling is a way to access a web application or other listening service. The dynamic tunnel provides a SOCKS proxy on the local port, but the connections originate from the remote host.

  • Load Balancer tier: The load balancer tier contains the Oracle Cloud Infrastructure Load Balancing instances that load balances the traffic to all instances in the presentation tier and the middle tier. The load balancer receives requests from users, and then routes these requests to instances in the presentation tier and middle tier.

    Use Oracle Cloud Infrastructure Load Balancing to distribute traffic to your application instances within a VCN. This service provides a primary and a standby instance of the load balancer to ensure that if the primary load balancer becomes unavailable, the standby load balancer forwards the requests. The load balancer ensures that requests are routed to the healthy application instances. If there’s a problem with an application instance, then the load balancer removes that instance and starts routing requests to the remaining healthy application instances.

    Based on your requirements, you can place load balancers in a public or private subnet.
    • For internal endpoints, that aren’t accessible from the Internet, use a private load balancer. A private load balancer has a private IP address, and it isn’t accessible from the Internet. Both the primary and the standby instances of a load balancer reside in the same private subnet. You can access private load balancers in the VCN or in your data center over the IPSec VPN through a DRG. The private load balancer accepts traffic from your data center, and distributes the traffic to underlying application instances.

    • For Internet-facing endpoints, use a public load balancer. A public load balancer has a public IP address, and it’s accessible from the Internet. You can access the public load balancers from the Internet through the Internet gateway.

    • For accessing internal endpoints and Internet-facing endpoints, set up private load balancers and public load balancers. Set up private load balancers to serve the internal traffic, and set up public load balancers to serve the traffic from the Internet.

    Register the public or private IP address of Oracle Cloud Infrastructure Load Balancing instances in your on-premises or public domain name server (DNS) for domain resolution of your application endpoint.

    The ports provided in the architecture diagram are only an example. You can use any port that’s available.

  • Administration tier: The administration tier contains a single instance of the following servers. You don’t require a redundant instance of these servers to ensure high availability.

    • Provisioning server: Use this server to automate end-to-end deployment of JD Edwards EnterpriseOne components on Oracle Cloud Infrastructure. It communicates with all the instances in the other tiers, including the instances in the database tier, over port 22. It hosts the JD Edwards EnterpriseOne One-Click Provisioning Console and JD Edwards EnterpriseOne Server Manager Console.

    • Deployment Server: During the installation process, this server acts as the central repository of all the required files and installation packages. The software is distributed or deployed to all other servers and clients from this server.

    • Development client: The JD Edwards EnterpriseOne Development client contains components that run as standard Microsoft Windows applications (for example, Active Console, Forms Design Aid (FDA), and Report Design Aid (RDA)) and components that run in a web browser.

  • Presentation tier: The presentation tier contains redundant instances of Application Interface Services and Java Application Servers to provide high availability. These servers communicate with servers in the middle tier. All instances are active and they receive traffic from the load balancer. Each instance is associated with a block storage volume. This tier also contains components that you can use to create integration between JD Edwards EnterpriseOne and an external system. Your implementation can include one or more of these components.

    This tier contains the following servers:

    • Java Application Servers (JAS): Java Application server receives requests from the load balancer and executes simple business logic. It passes requests to the logic server to execute tasks that require complicated business logic.

    • Application Interface Services (AIS) Server: Application Interface Service server provides the communication interface between JD Edwards EnterpriseOne mobile enterprise applications and JD Edwards EnterpriseOne.

    • Application Development Framework (ADF) Server: JD Edwards EnterpriseOne ADF Server is a web application that is deployed on an Oracle WebLogic server with ADF runtime. It is used to run JD Edwards EnterpriseOne applications developed with Oracle ADF.

    • Oracle Business Intelligence Publisher: Oracle Business Intelligence Publisher presents the data collected by JD Edwards EnterpriseOne in the form of reports. Use Oracle Business Intelligence Publisher to present reports using different templates based on your business requirements. You can design and control how the report outputs are presented by using template files.

    • Real-Time Events server: A real-time event (RTE) is a notification to a third-party system that a business transaction has occurred in the JD Edwards EnterpriseOne system. Third-party systems can subscribe to the JD Edwards EnterpriseOne system to receive a notification when a specific transaction occurs. You can use any JD Edwards EnterpriseOne interface, such as HTML, WIN32, and terminal servers to generate real-time events. To load balance requests to both the Real-Time Events servers, ensure that the servers are in a cluster.

    • Business Services servers: Business services are objects that enable interoperability between JD Edwards EnterpriseOne and other Oracle applications or third-party applications and systems. Business services enable software applications that are written in various programming languages and are running on various platforms to exchange information.

    To ensure high availability within an availability domain, deploy redundant instances of every component. All instances are active and they receive traffic from the load balancer and middle tier.

  • Middle Tier: The middle tier contains redundant instances of logic servers and batch servers to ensure high availability.

    In a single availability domain architecture, you can host the logic server and the batch server on the same enterprise server instance. However, in a multiple availability domain architecture where you are deploying production instances, it is recommended that you set up the logic server and the batch server on separate enterprise server instances.

    The middle tier receives requests from the load balancer and presentation tier. After processing the requests, it forwards the requests to the database servers. You must deploy redundant instances of logic servers and batch servers in an availability domain to ensure high availability. All instances of the servers are active and process requests.

    This tier contains the following servers:

    • Logic servers or enterprise servers: These servers contain the business logic or business functions.

    • Batch servers: These servers are used for batch processing.

  • Database tier: The database tier contains JD Edwards EnterpriseOne database server instances. For high availability requirements, Oracle recommends that you use two-node, Oracle Real Application Clusters (Oracle RAC) database systems or an Oracle Database Exadata Cloud Service system in Oracle Cloud Infrastructure to set up JD Edwards EnterpriseOne database server instances.

    Place database systems in a separate subnet. You can set up redundant database instances to provide high availability. For Oracle RAC and Oracle Database Exadata Cloud Service database systems, requests that are received from the application subnet are load balanced across the database servers. If one database instance becomes unavailable, the other database instance processes the requests. You can use Oracle Cloud Infrastructure Object Storage to back up the JD Edwards EnterpriseOne database by using Oracle Recovery Manager (RMAN). To back up or patch the JD Edwards EnterpriseOne database to Oracle Cloud Infrastructure Object Storage, the DB system's VCN must be configured with either a service gateway or an Internet gateway. It is recommended that you use a service gateway rather than an Internet gateway for backup and patching.

    Use security lists to restrict access to the database servers only from the bastion host, application tier, and on-premises servers. You can set up security lists to ensure that communication occurs only over port 22, through the bastion host, and over port 1521. Also ensure that the database systems can’t be accessed over the Internet.

You can use Oracle Cloud Infrastructure Object Storage to back up the instances in the presentation tier and the middle tier.

Architecture for Deploying JD Edwards EnterpriseOne in Multiple Availability Domains

This architecture shows the deployment of JD Edwards EnterpriseOne application servers in multiple availability domains. It shows a VCN with the bastion, load balancer, application, and database hosts placed in separate subnets across two availability domains. Oracle recommends that you use the multiple availability domain architecture for production environments.

In the architecture diagram, the bastion host is deployed in a public subnet, and all other instances are deployed in private subnets. You can place the instances in public or private subnets based on your business requirements. You can access the instances in private subnets over port 22 through the bastion host or the DRG. To enable communication between the DRG and the customer-premises equipment, use IPSec VPN or Oracle Cloud Infrastructure FastConnect. All instances are active in the two availability domains. The only passive components in the architecture are the database hosts in Availability Domain 2.

In this architecture, multiple application instances are deployed across availability domains to ensure high availability across the availability domains. This ensures that your application is available even when an one of the availability domain is not available. The available application instances in other availability domain continue to process the requests.

The bastion hosts in Availability Domain 1 and Availability Domain 2 are active and can serve SSH requests to instances in both availability domains at all times. The on-premises DNS or external DNS service receives request for JD Edwards EnterpriseOne application. These requests are round-robin load balanced to one of the load balancers in Availability Domain 1 or 2. The load balancer then routes the request to instances in the presentation tier and the middle tier in Availability Domains 1 and 2. The instances in the middle tier route the request to active database instances in Availability Domain 1 for processing. The development client in the administration tier also communicates with the database. The provisioning server in the administration tier communicates with instances in all the tiers.

If Availability Domain 1 is not available, you must manually remove the entry of Availability Domain 1 load balancer from the DNS service and switch over the database to the database instances in Availability Domain 2. Requests received from DNS service are now routed to the load balancer in Availability Domain 2, and then finally to the database in Availability Domain 2 for processing.

The databases and application instances in private subnets can be backed up to Oracle Cloud Infrastructure object storage by using a service gateway. A service gateway provides access to the object storage without traversing the Internet.


Description of jde2.png follows
Description of the illustration jde2.png
  • Bastion host: A bastion host is an optional component that you can provision in each availability domain to act as a jump host to access application and database instances. Bastion hosts in both Availability Domain 1 and Availability Domain 2 are in the active state.

  • Load balancer instances: Oracle Cloud Infrastructure Load Balancing instances distribute traffic across the application servers in both of the availability domains. Load balancer instances in both Availability Domain 1 and 2 are active. Requests received at the JD Edwards EnterpriseOne URL are round-robin load balanced to a load balancer in Availability Domain 1 or 2 by an on-premises or an external DNS service.

  • Presentation tier and middle tier: Redundant instances are deployed in the presentation tier and the middle tier across both Availability Domain 1 and Availability Domain 2 to ensure high availability. All instances across the two availability domains are in the active state.

  • Database tier: Set up highly-available database instances in both availability domains. Availability Domain 1 hosts the primary database instances. Availability Domain 2 hosts the standby database instances. In each availability domain, at least two database instances are set up to ensure high availability. If a database instance is not available in Availability Domain 1, then the second database instance in Availability Domain 1 continues processing requests.

    Use Oracle Active Data Guard in synchronous mode to replicate the database across availability domains in a region.

About the Security Lists

In Oracle Cloud Infrastructure, firewall rules are configured through security lists. A separate security list is created for each subnet.

Oracle recommends that you create separate subnets for the database, application, load balancer, and bastion hosts to ensure that the appropriate security list is assigned to the instances in each subnet. Use security lists to permit traffic between different tiers and between the bastion host and external hosts. Security lists contain ingress and egress rules to filter traffic at the subnet level. They also contain information about communication ports through which data transfer is permitted. Those ports (or in some cases, the protocols that will need open ports in the security rules) are shown on each security rule line in the architecture diagrams.

Each security list is enforced at the instance level. However, when you configure your security lists at the subnet level, all instances in a particular subnet are subject to the same set of rules. Each subnet can have multiple security lists associated with it, and each list can have multiple rules. The transfer of a data packet is permitted if a rule in any of the lists allows traffic (or if the traffic is part of an existing connection that’s being tracked). In addition to security lists, use iptables to implement another layer of security at the instance level.

For deployments in a public subnet, you can provide an additional level of security by preventing access to the application and database instances from the internet. Use a custom security list to prevent access to the application and database instances from the internet, and permit access to the database and application hosts over port 22 from the bastion host for administration purposes. Don’t enable SSH access to the application and database instances from the internet, but you can permit SSH access to these instances from the subnet that contains the bastion host.

You can access your instances in the private subnet through the bastion server.

Security List for the Bastion Host

The bastion security list allows the bastion host to be accessible from the public Internet over port 22.

  • To permit SSH traffic from the on-premises network to the bastion host over Internet:

    Stateful ingress: Allow TCP traffic from source CIDR 0.0.0.0/0 and all source ports to the destination port 22 (SSH).

    Source Type = CIDR, Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

    You can also restrict the bastion host to be accessible over internet on port 22 only from your data center instead of public Internet (0.0.0.0/0). To achieve this, use your edge router IP instead of source CIDR as 0.0.0.0/0 in the stateful ingress rule.

  • To permit all traffic from the bastion host to Oracle Cloud Infrastructure:

    Stateful egress: Allow TCP traffic to destination CIDR 0.0.0.0/0 from all source ports to all destination ports.

    Destination Type = CIDR, Destination CIDR = <CIDR block of VCN>, IP Protocol = TCP, Source Port Range = All, Destination port range = All

You can add or remove rules from the security list based on your requirements. Additionally, specify the ports over which you want to access Java application servers and Application Interface Services servers.

Security List for the Administration Tier

  • Stateful ingress: Allow TCP traffic on destination port 22 (SSH) from source CIDR block of the VCN and any source port.

  • Stateful ingress: Allow TCP traffic on destination port 3389 (RDP) from source CIDR block of the VCN and any source port.

  • Stateful ingress: Source CIDR block of the VCN on TCP, source port = all, destination port = 6017, 445, 5985, 14501-14503, 3000, 8998–8999

  • Stateful egress: Allow all traffic.

Security List for the Load Balancer Tier

The architecture contains private load balancers, which are placed in private subnets. If you place the load balancer instances in a public subnet, then you’re permitting traffic from the internet to the load balancer instances.

  • Stateful ingress: Source CIDR block of VCN and on-premises network on TCP, source port = all, destination port = ports on which you have created listener in the load balancer instances

  • Stateful egress: Allow all traffic.

Security List for the Presentation Tier

  • To permit traffic from the on-premises environment and the VCN to the presentation tier subnet:

    Stateful ingress: Source CIDR block of the VCN and on-premises network on TCP, source port = all, destination port = 6017-6023, 14501–14507

  • Stateful ingress: Source CIDR block of the VCN on TCP, source port = all, destination port = 22 (SSH)

  • To permit traffic from the presentation tier subnet to the middle tier subnet:

    Stateful egress: Source 0.0.0.0/0 on TCP, source port = all, destination port = all

Additionally, specify the ports over which you want to access Java Application servers and Application Interface Services servers and the ports over which you want to access Oracle Business Intelligence Publisher servers, Real-Time Events servers, and Business Services servers.

Security List for the Middle Tier

  • To permit traffic from the on-premises environment and VCN to the middle tier subnet:

    Stateful ingress: Source CIDR block of VCN and on-premises network on TCP, source port = all, destination port = 6017-6023, 14502-14503

  • Stateful ingress: Source CIDR block of the VCN on TCP, source port = all, destination port = 22 (SSH)

  • To permit traffic from the middle tier subnet to the presentation tier subnet:

    Stateful egress: Source 0.0.0.0/0 on TCP, source port = all, destination port = all

Security List for the Database Tier

  • To permit traffic from the bastion host to the database tier:

    Stateful ingress: Source CIDR block of the bastion host on TCP, source port = all, destination port = 22

  • To permit traffic from the middle tier to the database tier:

    Stateful ingress: Source CIDR block of the middle tiers on TCP, source port = all, destination port = 1521

  • To permit traffic from the on-premises environment and the VCN to the presentation tier subnet:

    Stateful ingress: Source CIDR block of the VCN on TCP, source port = all, destination port = 14502–14503

  • To permit traffic from the database tier to the middle tier:

    Stateful egress: Destination 0.0.0.0/0 on TCP, source port = all, destination port = all