Understanding WLST built-in variables . . .[WLST scripting Best Practices (Part-5)]

This post is a continuation of my previous post - in a series of posts about WLST scripting best practices.

Managed Beans (MBeans) are used to represent all the configuration and runtime information about WebLogic Domain, Servers, the applications and services deployed on a WebLogic Server Domain. While you can get all the information from WebLogic MBeans, WLST simplifies the task of building scripts by providing some built-in variables. These WLST variables are initialized and/or modified when you change to online mode (connect to a server), start an edit session etc. to appropriate values.

One of the very useful WLST variable is cmo. cmo stands for current management object. When navigating in WLST you can use cmo to reference the current MBean (object) instance you are navigating into. The cmo value is changed when you navigate to different hierarchy of MBeans under different MBean trees in WebLogic (except jndi tree). The following illustrates the use of cmo.

...
connect(username, password, url)
edit()
startEdit()
cd('/Servers/server1')
s1=cmo
cd('/Servers/server2')
s2=cmo
print 'Listenport of server1 -> ' + s1.getListenPort()
print 'Listenport of server2 -> ' + s1.getListenPort()
...

Notice the use of cmo can for invoking operations on the respective MBean object. There are many such variables that will help you to write better and efficient WLST scripts. See here for the list of all the WLST variables.

If you know a variable name you can simply use it in you script. dumpVariables() command can be used to list all the variables and their values.

wls:/testdomain/serverConfig> dumpVariables()
adminHome                     weblogic.rmi.internal.BasicRemoteRef - hostID: '328889774891021637S:127.0.0.1:[7001,7001,-1,-1,-1,-1,-1]:testdomain:AdminServer',oid: '259', channel: 'null'
cmgr                          [MBeanServerInvocationHandler]com.bea:Name=ConfigurationManager,Type=weblogic.management.mbeanservers.edit.ConfigurationManagerMBean
cmo                           [MBeanServerInvocationHandler]com.bea:Name=testdomain,Type=Domain
connected                     true
domainName                    testdomain
...

In addition you should also be aware of these WLST variables in order to NOT use them to store your own information. If you do so then WLST will overwrite these variables during your interaction like connect, startEdit etc. So make sure you understand these WLST variables, use them in your scripts and do not use them to store your information.

Force confidentiality for Web Applications

Usually there are requirements for web based applications to use SSL when serving sensitive data between the client browser and WebLogic server. You can enable SSL port for WebLogic Server and disable the plain text port. This will force all the communication through the SSL port enabled on the target server. But if you have a mix of applications that require secured access and that doesn't then you can use the standard JEE web application descriptor to enable confidentiality. If you enable trasport guarantee configuration for the Web Applications, WebLogic Server will force the application or selective URL patternts to be accessed through the SSL port on WebLogic Server.

The following shows an example of transport guaranetee entry from web.xml:

...

   
       CONFIDENTIAL
   

   
       /*
   

...

Even if the client is accessing through plain text port, WLS container will automatically redirect the request to the SSL port if enabled or to any other Network Channel enabled with SSL. This will ensure that certain applications or requests to be always accessed through SSL. Setting the transport guarantee to be NONE will relax the requirements and will not force SSL for the applications. But if there are SSL enabled network channels or SSL port is enabled on the server then the application can still be accessed using SSL. If the value for transport guarantee is set to be INTEGRAL then the requirement is that the data sent between the client and server be sent in such a way that it can't be changed in transit.

Needless to say that this configuration can also be configured through deployment plans. If the application you are deploying on WebLogic Server is already packaged for deployment or third-party application then deployment plan will solve the purpose of overriding the application's configuration through external means. See here for more information on deployment plans with WebLogic Server.

More ways to check the existense of a resource with WLST

In one of my previous post, I discussed a couple of ways with which you can find out whether a particular configuration already exists before you create them. The methods are not just limited to the one on that post. So now I am here to discuss couple more way to do the same check. But just for completeness I shall also include the methods I discussed in my previous post. I am taking a sample use case to check whether a particular WebLogic Server instance exists in the domain or not. But you can extrapolate these technique for any other resource like JDBC Data Source, JMS Server, JMS Queue etc.

Goal - Check whether a server with the name 'mymanagedserver' exists in the domain

Method-1 Using "cd"

A simple approach is to use the "cd" command to navigate into that configuration MBean. If the "cd" command throws an exception then you can safely assume that the resource/configuration doesn't exists and you can continue with your task.

...
mgdServerName = 'mymanagedserver'
### Checking for the server
try:
 cd('/Servers/' + mgdServerName)
 print '===> Server \"' +mgdServerName+'\" already exists'
 print '===> No action was performed'
 exit()
except:
 pass
### Continue to create the server
...

Method-2 Catch "BeanAlreadyExistsException"

Another approach is to catch the "BeanAlreadyExistsException" when creating the resource and safely exiting the script.

...
mgdServerName = 'mymanagedserver'
### Create the Managed Server
edit()
startEdit()
try:
 create(mgdServerName, resourceType)
 print '===> Created Managed Server - ' + mgdServerName
 pass
except BeanAlreadyExistsException:
 print '===> Server \"' +mgdServerName+'\" already exists'
 print '===> No action was performed'
 cancelEdit('y')
 exit()
...

But with this approach you are starting an edit session and creating the server to find out it's existence. So you have to cancel the edit session once you find out that the resource that you are creating already exists if not you might get a warning message similar to the following:

You have an edit session open and you will lose all outstanding changes and your edit session will be stopped if you exit. Are you sure you would like to exit? (y/n)

So canceling the edit session with a response 'y' will make WLST not to prompt for the user response.


Method-3 Using "getMBean"

There is a WLST command called getMBean which will return the MBean object when you specify the appropriate path. If the instance is not found then it will return None. But getMBean command does not throw an exception when an instance is not found. So you have explicitly check result of the getMBean.

...
mgdServerName = 'mymanagedserver'
ref = getMBean('/Servers/' + mgdServerName)
if(ref != None):
print 'Server ' +  servername + 'already exists'
disconnect()
exit()
else:
pass
### Continue to create the server
...

Method-4 Using "ls"

You can simply navigate to the resource type and execute ls. This will return the list of all the instances as a string when you assign the output to a variable. Then you can use the find method on that string variable to check whether your server exists. The find method returns a "0" on success or "-1" on failure.

...
mgdServerName = 'mymanagedserver'
cd('/Servers')
servers = ls()
if (servers.find(servername) != -1):
print 'Server ' +  servername + ' already exists'
disconnect()
exit()
else:
pass
### Continue to create the server
...

Don't want to get prompted for confirmation in WebLgic Console?

If you are using WebLogic Admin console frequently to configure resources or to manage the life cycle of the servers, you might have seen a confirmation prompt. This prompt will show not up when you are running the domain in development mode. When the domain is running in production mode they will ask confirmation for all the operations. There used to be no way to disable this confirmation page prior WebLogic Server 10.3. Now in WebLogic Server 10.3 and higher you can set a console user preference that can disable these confirmation pages.

Use the tool bar at the center (top) of the console to go to the "Preferences". Under the "User Preferences" tab you will find an option called "Ask for confirmation in operations". By default it will be enabled in production domains and you can disable it to avoid that annoying confirmation pages where will have to click either "Yes" or "No". While you are there explore the other useful preferences like "Show Inline Help" and "Show Advanced Sections" which can buy some real-estate space in the console and save you some clicks.

Change in WebLogic Server HTTP Session Failover Logic With Proxy Plug-ins

When using HTTP Sessions with WebLogic Cluster, you can ensure high availability for your session by configuring HTTP Session Replication. For the replication strategy, you have many options to select from like In-memory, file, JDBC, Cookie etc. When you are using in-memory replication with a web server to front WebLogic Server Cluster, the proxy plug-in must be configured on the web servers. The proxy plug-ins are intelligent enough to stick the request from a client to the same server where the session is hosted. A secondary copy of the session will be sent to a backup server by the primary server. This information will be written to a cookie or encoded in the URL depending on the client's configuration to support cookies.



In the past, during failure of the primary server, the proxy plug-in on the web server will redirect the request to the secondary/backup server. This resulted in increased traffic to the secondary/backup server. So somewhere during the Weblogic Server 9.x the plug-ins are updated to do a random routing incase of failures. The proxy server will randomly distribute all the requests from the failed server to different servers that are still running in the cluster. When the request from the existing clients (with valid session id) gets redirected to servers that are not secondary server then that server will connect to the secondary server for that client and will pull the session to become primary server. This ensures that one server will not get overloaded when a server in a cluster fails.




The same exact strategy was used when you front a WebLogic cluster with a load balancing hardware as not all the load balancing hardware understand the WebLogic cluster configuration. Now the same strategy is applied to the WebLogic Cluster front by a proxy plug-in hosted on a web server. This make the failover strategy consistent whether you have hardware or a software based proxy in front a WebLogic Cluster.

WebLogic Server documentation is still not updated to reflect this change under the "Proxy Failover Procedure" section. If you are running WebLogic Cluster with 9.x and you are not seeing this behavior then you can contact Oracle Support to find out whether there is a patch that can you can apply for your current WebLogic implementation.