Art of BI: Changing WebLogic Server Deployment Order using MBeans

I mention quite often to clients (and to anyone who will listen, really) that to be an advanced administrator and developer of Oracle Business Intelligence one needs to look at the Fusion Middleware stack as the foundation and learn about the core, WebLogic Server.  There are many benefits to doing this, such as automating processes, deploying custom applications, even gaining a better understanding of High-Availability and Clustering in OBIEE.

This post is brought about from some new development on the BITeamwork Collaborative BI solution where one customer had an issue with a delay in the Oracle BI start up supposedly from BITeamwork being deployed as an application with the WebLogic Server default Deployment Order value of 100.  This was a valid concern since BITeamwork seeks to call the /analytics JEE application’s web services when it starts in order to assess if OBIEE Presentation Services is actually started.

When a JEE application gets deployed in the WebLogic Server the default deployment order is set to 100 by default.  Deployment Orders tell WebLogic Server at startup which JEE applications to start first through prioritization set by the application’s Deployment Order. That is, applications with a lower Deployment Order value start up first sequentially. If you look at a standard OBIEE 11.1.1.7 deployment the Deployments table in the WLS Admin Console looks like the screenshot below:

In the screenshot you may see that the deployment order for the analytics application is 250.  This is the OBIEE Presentation Services JEE application that one would access from the default URL, http://<server_name>:9704/analytics

Most Library file deployments are deployed as 100 but some like the bijdbc library are deployed later in the sequence – 300.

As with any dependency based routine, if one of these applications starts prior to another it may depend on, there is potentially some level of failure of the system. Most times these issues can be overcome by either restarting a failed, inactive, or prepared application or at other times a restart of the WebLogic Server as a brute force tactic usually resolves the issue.

So, to solve the issue we faced with the BITeamwork application start up order against the other incumbent deployed applications there were only two options which could be used to modify the Deployment Order:

1. Manually via the WebLogic Administration Console

2. Programmatically via MBeans

The first option was not truly acceptable based on the quick and seamless installation process that BITeamwork presents.  That is to say, we don’t want customers to deploy BITeamwork via the installation script and then be required to log in to the WebLogic Server to change the Deployment Order manually.  That defeats the easy install and introduces the possibility of configuration variances which we didn’t want.  Just to show you quickly, the Deployment Order per application may be changed manually by, Clicking on an application from the Deployments table, clicking the Lock and Edit button to edit the deployed application, changing the deployment order value, and finally saving the edit and Activating Changes. The image below shows the deployed application edit form.

Assessing the MBeans can be done by using the WebLogic Enterprise Manager GUI.  Once on the MBeans Browser you’ll see there are several different types of MBeans.  Per the screenshot below the three types are (A) Configuration MBeans have a view over all WLS application objects and their attributes , (B) Runtime MBeans are those that can provide real-time information about objects, (C) Application MBeans are those specifically deployed as a part of Fusion Middleware (Edmond Biemond does a great job of explaining these).

Right of the bat we can see that we are looking for Configuration MBeans.  Drilling into the the Configuration MBeans folder tree, com.bea | AppDeployment, we can see all application’s deployed to the WebLogic Server. Clicking on the applications name under the AppDeployment folder you can see the attributes of the application.  The Attributes tab shows attributes which are read-only (R) and writable (RW) as denoted by the column labeled “Access”.

To determine what the deployed application’s MBean object name is you’ll need to show the MBean Information.  Do this by expanding the Show MBean Information toggle above the “Attributes” and “Operations” tabs.  The MBean object name is the one that we will be required to call from WLST in order to configure the attributes of our deployed application.

Capture the MBean Name (com.bea:Name=…..) as this will be used in the WLST script.

At this point I want to skip directly to a test script that you can call with WLST.  In order to run the test script, copy the logic below and save the file to your Oracle BI Server file system with a name such as changeDO.py.  Be sure to modify the first line with the connect function to point to your correct WebLogic Server and update it with your WLS administrator’s credentials.


connect("weblogic", "Admin123", "t3://localhost:7001")
domainConfig();
edit();
startEdit();
cd('/')
bitwDeployedAppName = "null"
deployments = cmo.getAppDeployments();
for deployment in deployments:

activate();


Once the logic above is saved to a file, navigate in a terminal or command prompt to the following directory on the server, <FMW_HOME>/oracle_common/common/bin, for example on a *Nix OS, /u01/fmw/oracle_common/common/bin/

Once there, execute WLST to call the script by typing in the following at the command line:


wlst.sh changeDO.py


By executing the code above the WLST engine will fire, connect to WebLogic Server, and run the script logic you’ve placed in the changeDO.py file.  A quick breakdown of the file is that it  prompts to set the WLS to configure the domain, it then calls edit mode and changes the directory to the base path of the MBean tree.  This script is unique as we leverage a loop in order to parse through all of the deployed applications seeking the deployed application that contains the test “bicomposer”.  Once that application is found, it runs a routine which dynamically inputs the full deployed application’s name (i.e.: the name you’ve located in the MBean tree).  It then uses mbs which is a WLST keyword that selects the current MBean position (i.e.: the deployed application caught in the loop) to set its attribute using the setAttribute function.  As you can see the SetAttribute function uses several arguments which should be clear to understand in lay terms.  Here we are changing the DeploymentOrder attribute to a value of 101.  Incrementing the bicomposer to 101 from 100 doesn’t impact the start up as this is just a test for you to assert the code using a real world example.  To change the value back after running the script you can either use the manual approach or update the script value back to 100 and re-run the WLST execution.

As I mentioned this post was spawned by an update which will be included in BITeamwork 2.0 which should be out July 2013.