![WebLogic 14c Clustered Domain Setup: AdminServer, NodeManager, JMS Bridges [d0lr]](/_next/image?url=https%3A%2F%2Fimages.unsplash.com%2Fphoto-1488590528505-98d2b5aba04b%3Fw%3D1200%26q%3D80&w=3840&q=75)
Overview: Architecting Resilient Messaging with WebLogic 14c Clustered Domains and JMS Bridges
In the dynamic landscape of enterprise applications, particularly within Oracle PeopleSoft ecosystems, robust and highly available middleware infrastructure is paramount. Oracle WebLogic Server 14c, the latest long-term support release, continues to be the cornerstone for deploying mission-critical applications, offering enhanced performance, security, and cloud-native capabilities. A well-architected WebLogic domain, featuring a clustered environment, an AdminServer for centralized management, NodeManagers for lifecycle automation, and critically, JMS bridges for inter-domain messaging, forms the backbone of many resilient PeopleSoft deployments and their integrations.
This article delves into the intricate process of setting up and configuring a WebLogic 14c clustered domain. We will explore the deployment of an AdminServer, the configuration and utilization of NodeManagers to manage Managed Servers within a cluster, and the strategic implementation of JMS bridges. JMS bridges are often overlooked but are vital components for enabling reliable, asynchronous communication between disparate JMS providers or even between different WebLogic domains, ensuring message delivery even across network partitions or during transient failures. For PeopleSoft environments, this often translates to reliable integration with external systems, legacy applications, or other PeopleSoft instances (e.g., HRMS to FSCM), where message queues facilitate loosely coupled communication patterns.
Our focus will be on a practical, step-by-step approach, providing real-world commands and configuration examples suitable for a production-grade setup. By the end of this guide, you will have a comprehensive understanding of how to build a resilient WebLogic 14c infrastructure capable of supporting demanding enterprise applications like PeopleSoft, with a particular emphasis on ensuring seamless message flow through JMS bridges.
Prerequisites
Before embarking on the WebLogic 14c domain configuration, ensure that your environment meets the following prerequisites. Adhering to these specifications will prevent common installation and configuration issues.
Operating System:
A supported 64-bit operating system. For enterprise deployments, Oracle Linux 7.x/8.x, Red Hat Enterprise Linux 7.x/8.x, or SUSE Linux Enterprise Server 12.x/15.x are commonly used. For this guide, we will assume an Oracle Linux 8 environment.
# Verify OS version cat /etc/oracle-release Oracle Linux Server release 8.8 # Ensure necessary packages are installed (e.g., for graphical installer or utilities) sudo dnf install -y unzip java-1.8.0-openjdk-develJava Development Kit (JDK):
Oracle WebLogic Server 14c (14.1.1.0.0) requires Oracle JDK 8 (update 202 or later) or Oracle JDK 11. It's crucial to use a certified JDK version. For this guide, we recommend Oracle JDK 8u381 or higher for compatibility with existing PeopleSoft deployments, or JDK 11 if your PeopleTools version supports it.
# Check Java version java -version openjdk version "1.8.0_382" OpenJDK Runtime Environment (build 1.8.0_382-b05) OpenJDK 64-Bit Server VM (build 25.382-b05, mixed mode) # Set JAVA_HOME environment variable export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.382.b05-1.el8_8.x86_64 export PATH=$JAVA_HOME/bin:$PATHOracle WebLogic Server 14c Software:
Download the Fusion Middleware Infrastructure Installer for 14.1.1.0.0 from the Oracle Technology Network (OTN) or Oracle Software Delivery Cloud (OSDC). This installer includes WebLogic Server and required Fusion Middleware components.
# Example of installer file fmw_14.1.1.0.0_infrastructure_generic.jarDatabase Connectivity:
While not strictly part of the WebLogic domain creation itself, for a PeopleSoft environment, you will need an Oracle Database. Ensure network connectivity and appropriate database credentials for configuring JDBC Data Sources later.
Network Configuration:
Static IP addresses for all servers hosting WebLogic components. Ensure DNS resolution is correctly configured or hosts files are updated. Open necessary firewall ports (e.g., 7001 for AdminServer, 8001/8002 for Managed Servers, 5556 for NodeManager).
# Example /etc/hosts entry on each server 192.168.1.101 weblogic-admin.example.com weblogic-admin 192.168.1.102 weblogic-node1.example.com weblogic-node1 192.168.1.103 weblogic-node2.example.com weblogic-node2User and Directory Structure:
A dedicated operating system user (e.g., `weblogic`) to own the WebLogic installation and domain directories. Create appropriate directories.
sudo useradd weblogic sudo passwd weblogic sudo mkdir -p /u01/app/oracle/product/fmw/14.1.1.0 sudo mkdir -p /u01/app/oracle/config/domains/peoplesoft_domain sudo chown -R weblogic:weblogic /u01
Step-by-Step Implementation
1. Oracle Fusion Middleware Infrastructure Installation
First, install the WebLogic Server 14c software. We'll use the generic installer in silent mode for consistency and automation.
# As the 'weblogic' user
cd /tmp
java -jar fmw_14.1.1.0.0_infrastructure_generic.jar -silent -responseFile /tmp/wls_install.rsp
Content of `/tmp/wls_install.rsp`:
[ENGINE]
#DO NOT CHANGE THIS.
Response File Version=1.0.0.0.0
[GENERIC]
#Specify a directory for the Oracle Home.
ORACLE_HOME=/u01/app/oracle/product/fmw/14.1.1.0
#Specify a directory for the Oracle Base. If not specified, it will be derived from the Oracle Home.
ORACLE_BASE=/u01/app/oracle
#Choose the installation type.
INSTALL_TYPE=Fusion Middleware Infrastructure
#Specify the password for the Oracle Configuration Manager registration (if applicable)
#MYORACLESUPPORT_PASSWORD=
#Choose whether to register for security updates.
SECURITY_UPDATES_VIA_MYORACLESUPPORT=false
#Specify if you wish to remain uninformed of security issues.
DECLINE_SECURITY_UPDATES=true
After installation, verify the `ORACLE_HOME`.
ls /u01/app/oracle/product/fmw/14.1.1.0
2. Creating a WebLogic 14c Clustered Domain
We'll use WebLogic Scripting Tool (WLST) in offline mode to create the domain. This provides a repeatable and automatable method.
# As the 'weblogic' user
cd /u01/app/oracle/product/fmw/14.1.1.0/oracle_common/common/bin
./wlst.sh create_peoplesoft_domain.py
Content of `create_peoplesoft_domain.py`:
# Define domain parameters
domain_name = "peoplesoft_domain"
domain_path = "/u01/app/oracle/config/domains/" + domain_name
admin_server_name = "AdminServer"
admin_server_listen_port = 7001
admin_server_ssl_port = 7002
cluster_name = "PeopleSoftCluster"
managed_server_base_name = "PS_SERVER"
managed_server_listen_port_start = 8001
managed_server_ssl_port_start = 8002
node_manager_name = "NodeManager"
node_manager_listen_port = 5556
admin_username = "weblogic"
admin_password = "MySecurePassword123" # CHANGE THIS FOR PRODUCTION!
# Create a new domain template
readTemplate("/u01/app/oracle/product/fmw/14.1.1.0/wlserver/common/templates/wls/wls.jar")
# Set the domain name
set('Name', domain_name)
# Configure the Admin Server
cd('/Servers/AdminServer')
set('Name', admin_server_name)
set('ListenPort', admin_server_listen_port)
set('ListenAddress', 'weblogic-admin.example.com') # Admin server host
create(admin_server_name, 'Server')
cd('/Servers/' + admin_server_name)
create('AdminServerListenPort', 'ListenPort')
cd('/Servers/' + admin_server_name + '/ListenPort/AdminServerListenPort')
set('ListenAddress', 'weblogic-admin.example.com')
set('ListenPort', admin_server_listen_port)
# Configure SSL for Admin Server (optional, but recommended)
create('AdminServerSSL', 'SSL')
cd('/Servers/' + admin_server_name + '/SSL/' + 'AdminServerSSL')
set('Enabled', 'true')
set('ListenPort', admin_server_ssl_port)
# Configure the Admin user
cd('/')
create(admin_username, 'User')
cd('User/' + admin_username)
set('Password', admin_password)
# Assign admin user to Administrators group
cd('/')
create('Administrators', 'Group')
cd('Group/Administrators')
assign('User', admin_username)
# Create a machine for the Admin Server
cd('/')
create('AdminMachine', 'Machine')
cd('Machine/AdminMachine')
create('NodeManager', 'NodeManager')
cd('NodeManager/NodeManager')
set('ListenAddress', 'weblogic-admin.example.com')
set('ListenPort', node_manager_listen_port)
# Assign AdminServer to the machine
cd('/Server/' + admin_server_name)
set('Machine', 'AdminMachine')
# Create a cluster
cd('/')
create(cluster_name, 'Cluster')
cd('Cluster/' + cluster_name)
set('ClusterMessagingMode', 'unicast') # or 'multicast' if your network supports it
# Create Managed Servers and assign to cluster and machines
# Example for two Managed Servers on two different machines
# Server 1 on weblogic-node1
cd('/')
create(managed_server_base_name + '1', 'Server')
cd('Server/' + managed_server_base_name + '1')
set('ListenAddress', 'weblogic-node1.example.com')
set('ListenPort', managed_server_listen_port_start)
create(managed_server_base_name + '1' + 'SSL', 'SSL')
cd('SSL/' + managed_server_base_name + '1' + 'SSL')
set('Enabled', 'true')
set('ListenPort', managed_server_ssl_port_start)
set('Cluster', cluster_name)
# Create machine for Managed Server 1
cd('/')
create('Machine1', 'Machine')
cd('Machine/Machine1')
create('NodeManager', 'NodeManager')
cd('NodeManager/NodeManager')
set('ListenAddress', 'weblogic-node1.example.com')
set('ListenPort', node_manager_listen_port)
cd('/Server/' + managed_server_base_name + '1')
set('Machine', 'Machine1')
# Server 2 on weblogic-node2
cd('/')
create(managed_server_base_name + '2', 'Server')
cd('Server/' + managed_server_base_name + '2')
set('ListenAddress', 'weblogic-node2.example.com')
set('ListenPort', managed_server_listen_port_start + 1)
create(managed_server_base_name + '2' + 'SSL', 'SSL')
cd('SSL/' + managed_server_base_name + '2' + 'SSL')
set('Enabled', 'true')
set('ListenPort', managed_server_ssl_port_start + 1)
set('Cluster', cluster_name)
# Create machine for Managed Server 2
cd('/')
create('Machine2', 'Machine')
cd('Machine/Machine2')
create('NodeManager', 'NodeManager')
cd('NodeManager/NodeManager')
set('ListenAddress', 'weblogic-node2.example.com')
set('ListenPort', node_manager_listen_port)
cd('/Server/' + managed_server_base_name + '2')
set('Machine', 'Machine2')
# Write the domain
writeDomain(domain_path)
closeTemplate()
exit()
3. Configuring and Starting NodeManager
NodeManager is essential for starting, stopping, and monitoring Managed Servers. It should run on each physical or virtual machine hosting WebLogic Servers.
3.1. NodeManager Configuration
Edit `nodemanager.properties` for security and listen address. This file is located in `DOMAIN_HOME/nodemanager/`.
# On weblogic-admin.example.com, weblogic-node1.example.com, weblogic-node2.example.com
# Edit /u01/app/oracle/config/domains/peoplesoft_domain/nodemanager/nodemanager.properties
# Ensure the following properties are set:
ListenAddress=weblogic-admin.example.com # or weblogic-node1.example.com, etc.
ListenPort=5556
SecureListener=true
LogLimit=50000
LogCount=10
DomainsFile=/u01/app/oracle/config/domains/peoplesoft_domain/nodemanager/nodemanager.domains
Create the `nodemanager.domains` file:
# On each server, create or modify
# /u01/app/oracle/config/domains/peoplesoft_domain/nodemanager/nodemanager.domains
peoplesoft_domain=/u01/app/oracle/config/domains/peoplesoft_domain
3.2. Starting NodeManager
Start NodeManager on each server that will host WebLogic instances (AdminServer, Managed Servers).
# On weblogic-admin.example.com (for AdminServer)
# On weblogic-node1.example.com (for PS_SERVER1)
# On weblogic-node2.example.com (for PS_SERVER2)
cd /u01/app/oracle/product/fmw/14.1.1.0/wlserver/server/bin
nohup ./startNodeManager.sh > /tmp/nodemanager.out 2>&1 &
4. Starting the AdminServer
The AdminServer is the central control point for the domain. Start it on `weblogic-admin.example.com`.
# On weblogic-admin.example.com
cd /u01/app/oracle/config/domains/peoplesoft_domain/bin
nohup ./startWebLogic.sh > /tmp/adminserver.out 2>&1 &
Verify the AdminServer is running and accessible via `http://weblogic-admin.example.com:7001/console`.
5. Starting Managed Servers via NodeManager
Once the AdminServer is up, use WLST (online mode) to connect to it and start the Managed Servers via NodeManager.
# On any machine with WLST installed, or on weblogic-admin.example.com
cd /u01/app/oracle/product/fmw/14.1.1.0/oracle_common/common/bin
./wlst.sh
WLST Commands:
connect('weblogic','MySecurePassword123','t3://weblogic-admin.example.com:7001')
# Start PS_SERVER1 via NodeManager on Machine1
start('PS_SERVER1', 'Server', block='true', timeout=60000, managedServerPort=8001, NodeManagerHome='/u01/app/oracle/config/domains/peoplesoft_domain/nodemanager', NodeManagerHost='weblogic-node1.example.com', NodeManagerPort='5556')
# Start PS_SERVER2 via NodeManager on Machine2
start('PS_SERVER2', 'Server', block='true', timeout=60000, managedServerPort=8002, NodeManagerHome='/u01/app/oracle/config/domains/peoplesoft_domain/nodemanager', NodeManagerHost='weblogic-node2.example.com', NodeManagerPort='5556')
disconnect()
exit()
Verify Managed Servers are running in the WebLogic console.
6. Configuring JMS Resources
JMS resources (JMS Servers, Modules, Connection Factories, Queues) are fundamental for messaging. We'll configure these using WLST online.
# Connect to AdminServer if not already connected
connect('weblogic','MySecurePassword123','t3://weblogic-admin.example.com:7001')
edit()
startEdit()
# Create a JMS Server and target it to a Managed Server (or cluster)
# For high availability, target to the cluster.
cd('/JMSServers')
cmo.createJMSServer('PeopleSoft_JMS_Server')
cd('/JMSServers/PeopleSoft_JMS_Server')
cmo.setTargets(jarray.array([ObjectName('com.bea:Name=PeopleSoftCluster,Type=Cluster')], ObjectName))
# Create a JMS System Module
cd('/')
cmo.createJMSSystemResource('PeopleSoft_JMS_Module')
cd('/JMSSystemResources/PeopleSoft_JMS_Module')
cmo.setTargets(jarray.array([ObjectName('com.bea:Name=PeopleSoftCluster,Type=Cluster')], ObjectName))
# Get the JMS System Module MBean
cd('/JMSSystemResources/PeopleSoft_JMS_Module/JMSResource/PeopleSoft_JMS_Module')
# Create a Connection Factory
cmo.createConnectionFactory('PeopleSoftCF')
cd('ConnectionFactories/PeopleSoftCF')
cmo.setJNDIName('jms/PeopleSoftCF')
cmo.setTransactionTimeout(3600) # 1 hour
cmo.setDefaultTargetingEnabled(true)
create('PeopleSoftCF_XA', 'JMSXAConnectionFactory')
cd('JMSXAConnectionFactories/PeopleSoftCF_XA')
set('Name', 'PeopleSoftCF_XA')
set('JNDIName', 'jms/PeopleSoftCF_XA')
cmo.setDefaultTargetingEnabled(true)
# Create a Queue
cd('/JMSSystemResources/PeopleSoft_JMS_Module/JMSResource/PeopleSoft_JMS_Module')
cmo.createQueue('PEOPLESOFT_IN_QUEUE')
cd('Queues/PEOPLESOFT_IN_QUEUE')
cmo.setJNDIName('jms/PEOPLESOFT_IN_QUEUE')
cmo.setDefaultTargetingEnabled(true)
# Create another Queue for outbound messages or another application
cd('/JMSSystemResources/PeopleSoft_JMS_Module/JMSResource/PeopleSoft_JMS_Module')
cmo.createQueue('PEOPLESOFT_OUT_QUEUE')
cd('Queues/PEOPLESOFT_OUT_QUEUE')
cmo.setJNDIName('jms/PEOPLESOFT_OUT_QUEUE')
cmo.setDefaultTargetingEnabled(true)
save()
activate()
disconnect()
exit()
7. Configuring JMS Bridges
JMS bridges are used to reliably transfer messages between two JMS destinations. This is particularly useful for integrating different WebLogic domains (e.g., a PeopleSoft domain with an external integration domain) or even different JMS providers.
For this example, let's assume we want to bridge messages from `jms/EXTERNAL_QUEUE` in an external WebLogic domain (or a different JMS provider like MQ Series) to `jms/PEOPLESOFT_IN_QUEUE` in our newly created domain.
First, we need to define the foreign JMS server and its connection factory in our domain, which points to the external JMS provider.
# Connect to AdminServer
connect('weblogic','MySecurePassword123','t3://weblogic-admin.example.com:7001')
edit()
startEdit()
# Create a Foreign JMS Server to connect to the external domain
cd('/')
cmo.createForeignJMSServer('External_JMS_Server')
cd('/ForeignJMSServers/External_JMS_Server')
cmo.setTargets(jarray.array([ObjectName('com.bea:Name=PeopleSoftCluster,Type=Cluster')], ObjectName))
# Define the remote connection factory for the external domain
cmo.createForeignConnectionFactory('ExternalCF')
cd('ForeignConnectionFactories/ExternalCF')
cmo.setLocalJNDIName('jms/ExternalCF') # JNDI name in our domain
cmo.setRemoteJNDIName('jms/ExternalCF') # JNDI name in the remote domain
cmo.setConnectionURL('t3://external-wls.example.com:7001') # URL of the remote AdminServer or a remote Managed Server
cmo.setUsername('externaluser') # Credentials for remote domain
cmo.setPassword('ExternalPass123') # CHANGE THIS!
# Define the remote destination (queue) in the external domain
cd('/ForeignJMSServers/External_JMS_Server')
cmo.createForeignDestination('External_Queue')
cd('ForeignDestinations/External_Queue')
cmo.setLocalJNDIName('jms/EXTERNAL_QUEUE') # JNDI name in our domain
cmo.setRemoteJNDIName('jms/EXTERNAL_QUEUE') # JNDI name in the remote domain
save()
activate()
disconnect()
exit()
Now, create the JMS Bridge itself:
# Connect to AdminServer
connect('weblogic','MySecurePassword123','t3://weblogic-admin.example.com:7001')
edit()
startEdit()
# Create the JMS Bridge
cd('/')
cmo.createJMSBridge('ExternalToPeopleSoftBridge')
cd('/JMSBridges/ExternalToPeopleSoftBridge')
# Target the bridge to the cluster for high availability
cmo.setTargets(jarray.array([ObjectName('com.bea:Name=PeopleSoftCluster,Type=Cluster')], ObjectName))
# Configure the Source Destination (External Queue)
cmo.createBridgeSource('BridgeSource_External')
cd('BridgeSources/BridgeSource_External')
set('ConnectionFactoryJNDIName', 'jms/ExternalCF')
set('DestinationJNDIName', 'jms/EXTERNAL_QUEUE')
set('ConnectionFactoryURL', 't3://external-wls.example.com:7001') # Redundant if using foreign server, but good for direct connections
set('Username', 'externaluser')
set('Password', 'ExternalPass123') # CHANGE THIS!
# Configure the Target Destination (PeopleSoft Inbound Queue)
cd('/JMSBridges/ExternalToPeopleSoftBridge')
cmo.createBridgeTarget('BridgeTarget_PeopleSoft')
cd('BridgeTargets/BridgeTarget_PeopleSoft')
set('ConnectionFactoryJNDIName', 'jms/PeopleSoftCF')
set('DestinationJNDIName', 'jms/PEOPLESOFT_IN_QUEUE')
# No ConnectionFactoryURL needed if the target is within the same domain
# No Username/Password needed if the target is within the same domain and using internal security
# Set Quality of Service (QOS)
# Options: Exactly-once, At-most-once, Duplicate-non-persistent
# Exactly-once is recommended for critical integrations, requires XA transactions.
set('QualityOfService', 'Exactly-once')
# Set transaction retry parameters
set('DurabilityEnabled', 'true') # Required for Exactly-once
set('MessageMaximum', 100) # Max messages per transaction
set('MessagingMode', 'Unicasted') # Or Multicasted
save()
activate()
disconnect()
exit()
Note on Quality of Service: 'Exactly-once' QoS requires both the source and target JMS providers to support XA transactions. If your external JMS provider does not support XA, you might need to settle for 'Duplicate-non-persistent' or 'At-most-once' and implement message deduplication at the application level. For PeopleSoft integrations, 'Exactly-once' is often preferred for critical business processes.
After creating the bridge, ensure its status is "Running" in the WebLogic console under Services -> JMS Bridges. Messages sent to `jms/EXTERNAL_QUEUE` on the external domain should now reliably appear in `jms/PEOPLESOFT_IN_QUEUE` in our `peoplesoft_domain`.
Security Considerations
Security is paramount in any enterprise deployment, especially for systems like PeopleSoft. A WebLogic 14c domain requires careful hardening.
- Strong Passwords: Always use strong, complex passwords for the WebLogic administrator and all other users/accounts. Change default passwords immediately.
- SSL/TLS Everywhere: Enable SSL/TLS for all communication, including AdminServer, Managed Servers, NodeManager, and JMS bridges. Use trusted certificates from a Certificate Authority (CA).
# Example WLST command to import certificate into keystore (after creating keystore) # Keytool command keytool -importcert -file /path/to/mycert.crt -keystore /path/to/mykeystore.jks -alias mycertalias -storepass changeit - Role-Based Access Control (RBAC): Implement fine-grained access control using WebLogic security realms. Grant users and groups only the minimum necessary privileges.
# Example WLST to create a new role and policy connect('weblogic','MySecurePassword123','t3://weblogic-admin.example.com:7001') edit() startEdit() cd('/SecurityConfiguration/peoplesoft_domain/Realms/myrealm/Roles/AppPolicies') cmo.createApplicationRole('CustomMonitorRole') cd('/SecurityConfiguration/peoplesoft_domain/Realms/myrealm/Roles/AppPolicies/CustomMonitorRole') cmo.setExpression('((GRP(Monitors)))') # Assign to a group named 'Monitors' save() activate() disconnect() - NodeManager Security: Configure NodeManager with SSL and ensure secure communication with the AdminServer. Restrict access to NodeManager ports at the OS firewall level.
- JMS Bridge Credentials: For JMS bridges connecting to external domains, ensure that the connection factory credentials are securely stored and managed, preferably using credential maps or securely configured JKS files. Avoid clear-text passwords in configuration files where possible.
- OS Hardening: Follow standard operating system hardening guidelines, including disabling unnecessary services, configuring firewalls, and regularly applying security patches.
- Auditing: Enable WebLogic auditing to track administrative actions and security-related