1. Learn about deploying JD Edwards EnterpriseOne on Oracle Cloud Infrastructure
  2. Learn about Deploying JD Edwards EnterpriseOne on Oracle Cloud Infrastructure

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 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.

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 subnet. 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 connects your on-premise networks to your cloud network. To enable communication between the DRG and the customer on-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 Region

You can deploy JD Edwards EnterpriseOne in a single availability domain while ensuring high availability.

You can achieve high availability by placing the application instances inside multiple fault domains. Use this architecture when you want to ensure that your application is available even when an application instance goes down in one fault domain. The other available application instances inside the other fault 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.

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 a single subnet 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 on-premises equipment, use IPSec VPN or Oracle Cloud Infrastructure FastConnect.

The Server Manager in the Administration tier communicates with Presentation tier, Middle tier, and Database tier to provide code deployment, configuration management, runtime metrics access, and log access. The Deployment Server in the Administration tier communicates with the Middle tier and the Database tier to build and deploy code. The Development Client communicates with the Middle tier and the Database tier. Application Development Framework (ADF) and Oracle Business Intelligence Publisher communicate with the HTML server in the Presentation 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. The load balancer receives requests from users, and then routes these requests to instances in the presentation 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 a problem occurs within an application instance, then the load balancer will route 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.

    • 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.

  • 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:

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

    • Standard Java Application Servers (Standard JAS): It receives requests from the load balancer and executes simple business logic. For tasks that require complicated business logic, Standard JAS passes the requests to the logic server. It also passes requests to the AIS server in some cases. However, it's not configured with the AIS server for the AIS runtime.

    • Dedicated Java Application Servers (Dedicated JAS): It receives requests from the AIS Server. It passes requests to the logic server to execute tasks that require complicated business logic. It is configured with the AIS server for the AIS runtime.

    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 logic servers and batch servers. They are not directly load balanced but they have one-to-one mapping with servers in presentation tier. You can host the logic server and the batch server on the same enterprise server instance. However, 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 presentation tier. After processing the requests, it forwards the requests to the database servers. 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.

    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 with Disaster Recovery

This architecture shows the deployment of JD Edwards EnterpriseOne application servers with disaster recovery. It shows a VCN with the bastion in a public subnet and all other servers in a private subnet.

Production servers are placed in two different regions. Servers in one region are in active mode and servers in the second region (Disaster Recovery region) are in the standby mode.

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.

In this architecture, multiple application instances are deployed in multiple fault domains to ensure high availability. 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 both the regions are active and can serve SSH requests to both regions at all time. The on-premises DNS or external DNS service receives request for JD Edwards EnterpriseOne application. These requests are round-robin load balanced the load balancer in the active region. The load balancer then routes the request to instances in the presentation tier and the middle tier. The instances in the middle tier route the request to active database instances 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 the primary region is not available, you must manually switch over to the database server running in Disaster Recovery region and start using the bastion host or the load balancer running in the Disaster Recovery region.

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 region to act as a jump host to access application and database instances. Bastion hosts in both the regions are in the active state.

  • Load balancer instance: Oracle Cloud Infrastructure Load Balancing instances distribute traffic across the application servers. The load balancer instance in the active/primary region is active. Requests received at the JD Edwards EnterpriseOne URL are sent to the load balancer in active region by an on-premises or an external DNS service.

  • Presentation tier: The presentation tier contains redundant instances of Application Interface Services (AIS) and Java Application Servers (JAS) 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.

  • Middle Tier: The middle tier contains logic servers and batch servers. They are not directly load balanced but they have one-to-one mapping with servers in the presentation tier.

  • Database tier: Set up highly-available database instances in both regions. The database server running in the active/primary region is in active state. In each region, at least two database instances are set up to ensure high availability within a region. If a database instance is not available in the active/primary region, then switch over to the database instance in Disaster Recovery region and start using the load balancer in the Disaster Recovery region to access the environment.

    Use Oracle Active Data Guard in synchronous mode to replicate the database across regions.

About Network Security Groups

In Oracle Cloud Infrastructure, firewall rules are configured through network security groups. A separate network security group is created for each tier.

Use security lists to permit traffic between different tiers and between the bastion host and external hosts. Security rules contain ingress and egress rules to filter traffic at the tier 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 network security group line in the architecture diagrams.

Each network security group is enforced at the VNIC level. 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 network security group, 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 network security group 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.

Network Security Group for the Bastion Host

The bastion network security group 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 network security group based on your requirements. Additionally, specify the ports over which you want to access Java application servers and Application Interface Services servers.

Network Security Group 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: Source CIDR block of the VCN on TCP, source port = all, destination port = 445, 5985, 14501-14510, 3000, 8998–8999, 5150

  • Stateful egress: Allow all traffic.

Network Security Group 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.

Network Security Group 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 = 14501–14510, 5150, Weblogic Admin Server port, Web Server ports

  • 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.

Network Security Group 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-14510, 5150

  • 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–14510, 5150

  • 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