WebLogic domain migration made easy by WLST

Huge migrations will be done in short time with wise WLST tricks. Now every one thinking about visualization of Cloud computing, that impacts on Oracle FMW components and also on WebLogic components. When there is hundreds of servers in build and deploy for a business there must be best practices that includes WLST automation with templatizing is must. This strategy will save lot of time, which consumes for configuring each system resource, user-defined resource on the WebLogic domain. The customized WebLogic domain templates can be used for the following situations:

This new feature is introduced from WebLogic 9.x onwards, we have wonderful options in WLST.
1. Default template to customized domain template
2. Existing Domain to customized domain template then domain
3. Domain Template from WebLogic 9.x to WebLogic 10.x domain and also supports this from WebLogic 10.x to WebLogic 11g migration process.
4. WebLogic Domain migrations from one machine to another

WebLogic Domain migration with WLST

Let me explain my current experiment on creating new WebLogic 11g Domain from existing WebLogic 9.2 domain which we did successfully in UAT, staging and finally in live too. The basic steps I followed in offline are as :
1. creating template: readDomain() from the existing WebLogic 9.2 and create a domain template with writeTemplate().
2. configuring new domain: go to the destination machine and readTemplate(), writeDomain()
3. updating for new domain: readDomain() and then modify the ListenAddress, ListenPort, security settings, and Log details for the domain
4. after making all required changes use updateDomain()


Big Advantage of Domain Templates using WLST

This will reduce the pain of creating
1. DataSource
3. Multi DataSource
4. JMS module
5. Persistence store
6. Start scripts
7. Domain environment automatically updated

Configure new domain templates

A domain configured from an existing development server to new machine. all the domain files are hoped to new machine, but certain parameters dependent on the local configurations. Such as listen address for the admin server, here is the need of WLST in offline mode to rectify the current environment. readDomain() is the WLST command that gives the access to current configuration and reproduce that domain template with writeTemplate().

Source machine:

readDomain('/home/domains/olddomain')
writeTemplate('/home/templatepath/olddomain.jar')
closeDomain()

Configuring new Domain on migrating machine

Now you can copy this template olddomain.jar file to destination machine and copy to the destination location. Execute following offline command sequence as follows:

createDomain('/olddoamin/path/template.jar’,’domainPath’,’user’, ‘passwd’)

Extending a Domain with WLST

To an existing domain you can change the few parameters regularly this you can give in a separate properties file. Create a simple script when you run the WLST script it will impacted in the new domain for extending with new properties this could be a best practice. For further updates you need to update one of the parameter that will make all the environment scripts updated for this new domain with new environment, So don't forget to update one of these following values:

readTemplate('/home/templatepath/olddomain.jar')
writeDomain('/home/domains/newdomain')
closeTemplate()
readDomain('/home/domains/newdomain')
ls()
cd('Server')
ls()
cd('AdminServer')
set('ListenAddress','hostname.com')
set('ListenPort',10300) # Changing Admin Server ListenPort
set('Name','newAdmin') # Changing Admin server name

cd('/Server/newAdmin/Log/newAdmin')
set('FileName','/home/instances/newAdmin/logs/newAdmin.log')
updateDomain()
closeDomain()

Change to Production Mode
One of the situation that where you start working on developing complete platform designing for a Weblogic based environment such as SOA or WebCenter or some other. You might get situation where you need to change development mode to production mode. If your pre-production environtment is made exaactly simula of production then the only one thing you need to change that is Production Mode. This Production mode will give more security than development mode for WebLogic domain. Using WLST you can do this very easy to modify this

connect(adminUser,adminPassword,adminURL)
edit()
startEdit()

cd('/')

####################################################################################
# DOMAIN LEVEL CONFIGURATIONS
###################################################################################
print ' ******* SETTING DOMAIN LEVEL CONFIGURATIONS *********** '

domMode = getMBean('/')
domMode.setProductionModeEnabled(true)

domLog = getMBean("/Log/"+domainName)
domLog.setFileName(''+domainHome+'/logs/bea/'+domainName+'.log')

secCon = getMBean("/SecurityConfiguration/"+domainName)
secCon.setEnforceValidBasicAuthCredentials(false)

print ' ******* DOMAIN LEVEL CONFIGURATIONS SET SUCCESSFULLY *********** '
save()
activate(block="true")

disconnect()

The properties file be look like this:

adminUser=weblogic
adminPassword=weblogic123$
adminServerName=admin_cldom
adminServerListenaddr=localhost
admlistenport=7100

OverwriteDomain=true
domainName=cldom
domainHome=/wldomains/cldom

After running above script, you need to stop all the servers in the domain with the current domain configuration start the AdminServer first then start remaining managed servers. This will show the impact of change mode. One of my online buddy asked me is there any chance to migrate from non-WebLogic Application server(such as JBoss/WAS/OCJ4 etc) to WebLogic. Right now it is not available from Oracle, If Oracle give similar way of templates  for migrating from OCJ4 Application Server migration, Websphere migration, JBoss migration and TCat server migration templates then it is more easy life for migrating from any J2EE server to any other. This is a very marketing strategy because it can make more revenue for Oracle and it is easy for customers and WLA to migrate JEE applications to Oracle WebLogic Server. What do you say dear blog reader?? Keep writing your suggestions, comments.