About Configuring JD Edwards Disaster Recovery by Using OCI Full Stack Disaster Recovery

JD Edwards Architecture

This illustration outlines the JD Edwards application's deployment architecture, featuring both primary and secondary regions.

Description of the illustration jdr-dr-fsdr.png

jde-dr-fsdr-oracle.zip

Primary Region

In the primary region, the JDE environment is deployed within a Virtual Cloud Network (VCN) that is segmented into three dedicated subnets, which are segregated by application resources functionality, as described below.

Load balancer tier
The load balancer tier hosts the OCI load balancer, which provides access to JDE web services for end users.
Application tier
The application tier contains the core application components, including the enterprise server, the web server, and the Application Interface Services (AIS) server
Management tier
The management tier includes tools and services for JDE management and administration, such as the deployment server and the Server Manager Console server
Database tier
In the database layer, the JDE database is deployed on Autonomous Transaction Processing–Shared (ATP-S). Application servers connect to the database using endpoints. Oracle Autonomous Data Guard is enabled, creating a standby database in the secondary region and ensuring real-time data replication for high availability and disaster recovery.
Storage and data protection
The block volume groups used by compute instances are protected by cross-region volume group replication, with the secondary region configured as the replication target.

Secondary Region

The secondary region serves as the disaster recovery site and mirrors critical components from the primary region.It contains:

A replicated VCN structure that matches the primary region’s network layout.
A replica load balancer to ensure continuity of access during failover.
A standby ATP-S database that is kept in sync with the primary by using Autonomous Data Guard.
Replicas of volume groups, which ensures data availability in the event of a primary region failure.

Understand JD Edwards Configuration-related Files

JDE relies on multiple configuration files to manage connectivity between its components and other participating tiers, such as databases and authentication services. These files play a critical role in defining connection parameters, runtime settings, and integration behavior. Having a proper understanding of these files and its contents is essential while configuring Disaster Recovery (DR) scenario to ensure seamless application functionality.

Below is a summary of key configuration files:

sqlnet.ora

Purpose: Stores Oracle Wallet configuration used by the application to securely connect to the database.

Location: JDE Enterprise/Batch servers. DR

Consideration: Ensure the wallet path points to the valid wallet location of the DR database.

File path: Oracle_ClientHome/network/admin

tnsnames.ora

Purpose: Stores Net Service Names, which act as aliases for database network addresses.

Location: JDE Enterprise, Batch, and Web servers.

DR Consideration: Update with the correct network address (FQDN/IP) of the DR database.

File path on Enterprise/Batch Servers: Oracle_ClientHome/network/admin

File path on Web Servers: SM_Agent_Home/SCFHA/Target/Managed Instance/config

jde.ini

Purpose: Stores runtime configuration for the JDE application, including database connection details and security settings.

Location: JDE Enterprise and Batch servers.

DR Consideration: Update the DB SYSTEM SETTINGS section with the correct server name for the DR environment.

File path: JDE_HOME/e920/ini

jdbj.ini

Purpose: Contains JDBj driver settings and database connection parameters for JDE applications.

Location: JDE Web and AIS servers.

DR Consideration: Ensure the correct server name is specified in the JDBj-BOOTSTRAP DATA SOURCE section.

File path: SM_Agent_Home/SCFHA/Target/Managed Instance/config

jas.ini

Purpose: Stores configuration for the HTML Server component of EnterpriseOne web clients.

Location: JDE Web servers.

DR Consideration: Update the following:

FORMSERVICE section with the correct AIS host and port.
Security section with the appropriate OracleAccessSSOSignOffURL if SSO is enabled.

File path:

SM_Agent_Home/SCFHA/Target/Managed
                                                  Instance/config

rest.ini

Purpose: Holds configuration for the AIS Server, including REST API paths, authentication settings, and JAS server links.

Location: JDE AIS servers.

DR Consideration: Update the following:

BASIC CONFIG section with the correct JAS host and port.
Security section with the updated IDCSSSOSignOffURL if SSO is enabled.

File path:

SM_Agent_Home/SCFHA/Target/Managed
                                                  Instance/config

management-console.xml

Purpose: This XML file has information about the different servers, their configurations, and user access permissions.

Location: Server Manager Server

DR Consideration: Ensure the correct hostname is specified in the management-console.xml

File path:SM_Console_Home/SCFMC/targets/home

agent. properties

Purpose: Configuration file that has settings for the Management Agent, a component that interacts with the Management Console and manages EnterpriseOne servers

Location: Server Manager Server

DR Consideration: Ensure the correct server name is specified in the agent.properties section.

File path: SM_Console_Home/ SCFMC/config

Additional System-Level Updates

In addition to application configuration files, the following system files should also be reviewed and updated during a DR implementation:

Linux hosts and fstab files: Ensure valid IP addresses and FQDNs are defined.
Windows hosts file: Update with current IP and FQDN mappings as required.
WebLogic wallet files: Must be updated to reflect DR-specific database wallet to ensure connectivity if database is Autonomous.

Properly maintaining and updating these configuration files ensures that JDE continues to function correctly in a Disaster Recovery environment, minimizing downtime and maintaining secure, consistent application connectivity.

Understand Full Stack Disaster Recovery Concepts

When configuring and implementing FSDR, you will need to understand the following concepts and terminologies.

DR Protection Group
- Definition: A DR protection group includes all the necessary OCI resources such as compute instances, volume groups, load balancers and databases that together form a complete application stack.
- Advantage: A DR protection group is treated as a single unit for failover, failback, and in testing scenarios. It ensures that all resources are recovered together, which minimizes downtime and data loss.
DR plan
A DR plan is an automated runbook created by FSDR to perform disaster recovery for all the resources in the primary DR protection group. It consists of steps that define how all the resources in a primary DR protection group region are transitioned to its peer secondary DR protection group region. These are the various types of DR plans:
- Failover (unplanned): Use a failover plan when you want to perform an immediate transition by bringing up the application stack in the standby region, without attempting to shutdown service in the primary region. Failover plans are generally used to perform DR transitions when an outage or disaster affects the primary region.
- Switchover (planned): Use a switchover plan when you want to perform an orderly transition by shutting down the application stack in the primary region and then bringing it up in the standby region. Switchover plans are typically used for the purposes of planned site maintenance, software patching, DR testing, and validation.
- Start drill: A start drill generates a plan to perform the DR drill without interrupting the primary DR protection group resources. It creates a replica of resources in the standby DR protection group.
- Stop drill: This DR plan stops the DR drill by removing the replica of resources created by the start drill.
Moving Instance
- Definition: Instances deployed only in the primary region.
- Use Case: Common in cold DR topologies, wherein very few or none of the components of an application or service need to be pre-deployed in the standby region in preparation for a future DR transition.
- Behavior: During a disaster event, moving instances are moved from the primary region’s DR protection group to the standby region’s DR protection group.
- Advantage: Cost-efficiency, as resources in the standby region are not continuously running.
- Consideration: This method requires longer recovery times due to the need to provision and start instances in the standby region.
Non-Moving Instance
- Definition: Instances pre-deployed in both primary and standby regions.
- Use Case: Common in active-passive DR topologies, wherein some or all of the components of an application or service are pre-deployed in the standby region to prepare for a future DR transition..
- Behavior: During DR operations, these instances are started or stopped as needed to transition service between regions.
- Advantage: This method provides faster recovery due to pre-existing infrastructure in the standby region.
- Consideration: This can result in higher cost because infrastructure needs to be maintained in both regions.

Full Stack Disaster Recovery Prerequisites

Before you can proceed with he FSDR process, you need to complete the following prerequisites:

Provision a VCN, subnets, route tables, security lists, and network gateways in the DR region. To support failover functionality and connectivity, ensure the network configurations mirror those in the primary region .
Define a dynamic group to allow policies that grant administrator privileges to instances created as part of the DR environment.
You need administrator rights to run scripts on compute instances. The Run Command plug-in uses the ocarun user to execute these scripts. Ensure that this user has appropriate permissions.
1. Open oracle-cloud-agent-run-command for editing:
```
 vi ./101-oracle-cloud-agent-run-command
```
2. Add the following lines in the configuration file:
```
ocarun ALL=(ALL) 
NOPASSWD:ALL
```
3. Then run:
```
vi sudo -cf ./101-oracle-cloud-agent-run-command
```
4. Add the configuration file to /etc/sudoers.d:
```
sudo cp ./101-oracle-cloud-agent-run-command /etc/sudoers.d/
```
Activate cross-region backup functionality for volume groups.
Deploy a load balancer in the secondary region. As part of FSDR configuration, only the backend set (instances) will be moved from the primary to the standby region; the load balancer itself must be created manually on the standby region in advance.
Set up a corresponding (peer) database instance in the DR region to support application failover.
Create an object storage bucket for logs in primary region. This bucket will store DR logs and artifacts specific to the environment.
Create an additional object storage bucket in the standby region. This bucket will be used for replication or logging purposes to ensure DR readiness in the standby region.
Place the following custom scripts in the proper location.

Apply Custom Scripts

These custom scripts are executed during the FSDR process.

update_rest

Applicable server: AIS

#Define the old and new file names
old_file1="rest_dr.ini"
new_file1="rest.ini"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"
 # Copy the new second file back to the original name, preserving attributes
 cp -p "$new_file1" "$old_file1"
 echo "Copied $new_file1 back to $old_file1 (preserving attributes)"

else
 echo "One or both of the old files do not exist in the folder."
fi

update_tnsnames_jdbj

Applicable servers: JAS, AIS

#Define the old and new file names
old_file1="tnsnames_dr.ora"
old_file2="jdbj_dr.ini"
old_file3="jas_dr.ini"
new_file1="tnsnames.ora"
new_file2="jdbj.ini"
new_file3="jas.ini"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"

 # Rename the second file
 mv "$old_file2" "$new_file2"
 echo "Renamed $old_file2 to $new_file2"

 # Rename the third file
 mv "$old_file3" "$new_file3"
 echo "Renamed $old_file3 to $new_file3"

else
 echo "One or both of the old files do not exist in the folder."
fi

update_wallet

Applicable servers: All JDE Servers (Enterprise, AIS, JAS, Fatclient, Integrations, and so on)

# Define old and new wallet folder names
old_wallet="Wallet_jdeorcl_hyderabad"
new_wallet="Wallet_jdeorcl"

# Check if the old wallet directory exists
if [ -d "$old_wallet" ]; then
  # Remove any existing new_wallet directory to avoid conflict
  if [ -d "$new_wallet" ]; then
    echo "Removing existing $new_wallet directory..."
    rm -rf "$new_wallet"
  fi

  # Rename the old wallet to the new name
  mv "$old_wallet" "$new_wallet"
  echo "Renamed $old_wallet to $new_wallet"

  # Copy the new wallet back to the old wallet directory for reuse
  cp -r "$new_wallet" "$old_wallet"
  echo "Copied $new_wallet back to $old_wallet for reuse"

else
  echo "Directory $old_wallet does not exist. Aborting operation."
fi

update_ini

Applicable server: Enterprise

# Define the old and new file names
old_file2="JDE_DR.INI"
old_file3="jdbj_dr.ini"
new_file2="JDE.INI"
new_file3="jdbj.ini"

# Check if the old files exist in the folder
if [ -e "$old_file2" ] && [ -e "$old_file3" ] ; then
    # Rename the second file
    mv "$old_file2" "$new_file2"
    echo "Renamed $old_file2 to $new_file2"

    # Rename the third file
    mv "$old_file3" "$new_file3"
    echo "Renamed $old_file3 to $new_file3"
else
    echo "Old files do not exist in the folder."
fi

update_tnsnames_sqlnet

Applicable servers: Enterprise, Deployment, Fatclients

#Define the old and new file names
old_file1="tnsnames_dr.ora"
old_file2="sqlnet_dr.ora"
new_file1="tnsnames.ora"
new_file2="sqlnet.ora"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"

 # Rename the second file
 mv "$old_file2" "$new_file2"
 echo "Renamed $old_file2 to $new_file2"
else
 echo "One or both of the old files do not exist in the folder."
fi

update_agent_properties

Applicable servers: All servers managed by Server Manager

# Define the old and new file names
old_file1="agent.properties"
new_file1="agent_dr.properties"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
# Rename the first file
mv "$old_file1" "$new_file1"
echo "Renamed $old_file1 to $new_file1"
else
echo "One or both of the old files do not exist in the folder."
fi

update_management_console

Applicable server: Sever Manager

# Define the old and new file names
old_file1="management-console_dr.xml"
new_file1="management-console.xml"

# Check if the old files exist in the folder
if [ -e "$old_file1" ]; then
# Rename the first file
mv "$old_file1" "$new_file1"
echo "Renamed $old_file1 to $new_file1"
else
echo "One or both of the old files do not exist in the folder."
fi