The Server Labs Blog Rotating Header Image


ALSB/OSB customization using WLST

One of the primary tasks in release management is environment promotion. From development to test or from test to production, environment promotion is a step which should be as much automated as possible.

We can use the service bus MBeans in WLST scripts to automate promotion of AquaLogic/Oracle Service Bus configurations from development environments through testing, staging, and finally to production environments.

Each environment has particularities which may need changes in configuration of the software. These are usually centralized in property files, database tables, environment variables or any other place to facilitate environment promotion.

In AquaLogic/Oracle Service Bus there is the concept of environment values:

Environment values are certain predefined fields in the configuration data whose values are very likely to change when you move your configuration from one domain to another (for example, from test to production). Environment values represent entities such as URLs, URIs, file and directory names, server names, e-mails, and such. Also, environment values can be found in alert destinations, proxy services, business services, SMTP Server and JNDI Provider resources, and UDDI Registry entries.

For these environment values, we have different standard operations

  • Finding and Replacing Environment Values
  • Creating Customization Files
  • Executing Customization Files

However, these operations are limited to the ‘predefined fields whose values are very likely to change’… and what happens if we need to modify one of the considered ‘not very likely’? A different story is whether to consider SAP client connection parameters ‘not very likely’ to change in a environment promotion from test to production…

In order to automate these necessary changes, one option is to modify directly the exported configuration prior to importing it to the destination environment but in our case, we want to maintain the philosophy of the customization after the importing, keeping the exported package untouched. We will try to use a WLST script instead of a customization file, as the later doesn’t satisfy our needs.

The first thing we have to do for using WLST is to add several service bus jar files to the WLST classpath. For example, if we have a Windows platform we add the following at the beginning of wlst.cmd file (I’m sure *nix people will know how to proceed in their case)

For Aqualogic Service Bus 3.0:

SET ALSB_HOME=c:\bea\alsb_3.0
SET CLASSPATH=%CLASSPATH%;%ALSB_HOME%\lib\sb-kernel-api.jar
SET CLASSPATH=%CLASSPATH%;%ALSB_HOME%\lib\sb-kernel-common.jar
SET CLASSPATH=%CLASSPATH%;%ALSB_HOME%\lib\sb-kernel-resources.jar
SET CLASSPATH=%CLASSPATH%;%ALSB_HOME%\lib\sb-kernel-impl.jar
SET CLASSPATH=%CLASSPATH%;%ALSB_HOME%\..\modules\com.bea.common.configfwk_1.1.0.0.jar
SET CLASSPATH=%CLASSPATH%;%ALSB_HOME%\..\modules\com.bea.alsb.statistics_1.0.0.0.jar

For Oracle Service Bus 10gR3:

SET ALSB_HOME=c:\bea\osb_10.3
SET CLASSPATH=%CLASSPATH%;%ALSB_HOME%\lib\sb-kernel-api.jar
SET CLASSPATH=%CLASSPATH%;%ALSB_HOME%\lib\sb-kernel-common.jar
SET CLASSPATH=%CLASSPATH%;%ALSB_HOME%\lib\sb-kernel-resources.jar
SET CLASSPATH=%CLASSPATH%;%ALSB_HOME%\lib\sb-kernel-impl.jar
SET CLASSPATH=%CLASSPATH%;%ALSB_HOME%\..\modules\com.bea.common.configfwk_1.2.1.0.jar
SET CLASSPATH=%CLASSPATH%;%ALSB_HOME%\..\modules\com.bea.alsb.statistics_1.0.1.0.jar

In our example, we will try to change the HTTP timeout in the normalLoanProcessor business service present in ALSB/OSB examples server.


normalLoanProcessor configuration

For that, we will first connect to the bus from WLST and open a session using SessionManagementMBean

from import SessionManagementMBean
connect("weblogic", "weblogic", "t3://localhost:7021")
sessionMBean = findService(SessionManagementMBean.NAME, SessionManagementMBean.TYPE)
sessionName = "mysession"

mysession shown in sbconsole

Nothing new until now. Next thing we need is a reference to the component you want to modify. We chose to use a BusinessServiceQuery like:

from import BusinessServiceQuery
from import ALSBConfigurationMBean
bsQuery = BusinessServiceQuery()
alsbSession = findService(ALSBConfigurationMBean.NAME + "." + sessionName, ALSBConfigurationMBean.TYPE)
refs = alsbSession.getRefs(bsQuery)
bsRef = refs.iterator().next()

After this we have a reference to the business service we want to modify. Now is when fun begins.

There is an undocumented service bus ServiceConfigurationMBean (not to be confused with old whose description is ‘MBean for configuring Services’.

ServiceConfiguration.mysession as shown in jconsole

Among the different methods, we find one with an interesting name: getServiceDefinition

getServiceDefinition as shown in jconsole

It looks that we can use the getServiceDefinition method with our previous reference to the business service for obtaining exactly what its name states.

from import ServiceConfigurationMBean
servConfMBean = findService(ServiceConfigurationMBean.NAME + "." + sessionName, ServiceConfigurationMBean.TYPE)
serviceDefinition = servConfMBean.getServiceDefinition(bsRef)

This is the result of printing serviceDefinition variable:


Surprised? It’s exactly the same definition written in .BusinessService XML files. In fact, the service definition implements XMLObject.

Now it’s time to update the business service definition with our new timeout value (let’s say 5000 milliseconds) using XPath and XMLBeans. We must also take care of defining namespaces in XPath the same way that are defined in .BusinessService XML files.

nsEnv = "declare namespace env='' "
nsSer = "declare namespace ser='' "
nsTran = "declare namespace tran='' "
nsHttp = "declare namespace http='' "
nsIWay = "declare namespace iway='' "
confPath = "ser:endpointConfig/tran:provider-specific/http:outbound-properties/http:timeout"
confValue = "5000"
confElem = serviceDefinition.selectPath(nsSer + nsTran + nsHttp + confPath)[0]

We are almost there. First we update the service.

servConfMBean.updateService(bsRef, serviceDefinition)

Modified mysession shown in sbconsole

And finally, we activate the session (see NOTE) like we would do in bus console.

sessionMBean.activateSession(sessionName, "Comments")

mysession changes shown in sbconsole

Task details of mysession

Updated normalLoanProcessor configuration

With this approach, it could be possible to build a framework that allows to customize ALL fields as needed.

If you get the exception below when activating changes, please update your WebLogic Server configuration as described in Deploy to Oracle Service Bus does not work

Traceback (innermost last):
  File "", line 1, in ?
com.bea.wli.config.deployment.server.ServerLockException: Failed to obtain WLS Edit lock; it is currently held by user weblogic. This indicates that you have either started a WLS change and forgotten to activate it, or another user is performing WLS changes which have yet to be activated. The WLS Edit lock can be released by logging into WLS console and either releasing the lock or activating the pending WLS changes.
        at com.bea.wli.config.deployment.server.ServerDeploymentInitiator.__serverCommit(Unknown Source)
        at com.bea.wli.config.deployment.server.ServerDeploymentInitiator.access$200(Unknown Source)
        at com.bea.wli.config.deployment.server.ServerDeploymentInitiator$ Source)
        at Source)
        at com.bea.wli.config.deployment.server.ServerDeploymentInitiator.serverCommit(Unknown Source)
        at com.bea.wli.config.deployment.server.ServerDeploymentInitiator.execute(Unknown Source)
        at com.bea.wli.config.session.SessionManager.commitSessionUnlocked(
        at com.bea.wli.config.session.SessionManager.commitSession(
        at com.bea.wli.config.session.SessionManager.commitSession(
        at com.bea.wli.config.session.SessionManager.commitSession(

Using RightScripts to create a Weblogic cluster in Amazon EC2

In my previous post, I described how to set up a Weblogic cluster in Amazon EC2 using the Oracle-supplied Amazon AMI image. In this post, I will describe how to create a cluster using RightScripts, an alternative technology offered by RightScale.

In Amazon EC2, you work on an AMI – installing software, configuring – until you are happy with it. Then you ‘freeze’ it, storing it in S3 so that you can create many different instances based on this AMI. Amazon give you the possibility to pass configuration data to each new instance using “user-supplied data” which allows you do differ one launched AMI from another.

RightScale offer you an alternative. Instead of doing all the installation and configuration work on an AMI and then freezing it, you capture all the installation and configuration work in scripts – RightScripts. Each time you start up an instance in RightScale, you decide which RightScripts to execute against a base operating System to construct the complete machine that you wish to deploy.

For example, if you want to deploy an Apache Web Server, you write a RightScript that downloads, installs and configures Apache. You start up a new instance (with a base operating system e.g. CentOS) and run the RightScript. Once it has finished, you have an Apache server up and running. You can even associate one or more RightScripts with a base AMI to make a RightScale Server Template.

The benefits over the use of highly personalised AMIs are:

  • It is easier to change the configuration of your machines in the future – you can just execute another RightScript ‘on the fly’
  • You are not tied to one particular cloud vendor. RightScale allow you to execute RightScripts on machines in non-Amazon clouds

This article will show you how to create a Weblogic cluster using RightScale Server Templates made up of various RightScripts. You will need some familiarity with Amazon EC2 and S3 to get the full benefits from this article and I also assume that you’ve read my previous post on this theme.

You will need to sign up for a RightScale account to follow the steps in this post.


We will create two server templates – one for the primary cluster node that runs the admin server and a managed server and one that contains just a managed server. We will create these templates from various RightScripts that completely automate the installation and configuration process and just require a few variables to be set. This should mean that we can deploy many managed server instances with just a few clicks.

Creating the RightScripts

Log into the RightScale service and click on the Design > RightScripts link in the navigation bar on the left. Click on the ‘new’ button to add a RightScript and add each of the scripts described below, naming them the same as the header:

Install Weblogic

This script installs weblogic on top of the base operating system. It relies on a tar-gzipped copy of the Weblogic installation being stored in an S3 bucket (folder) to which you have access. To create this copy (a one-off procedure), run an instance based on AMI “ami-6a917603” and execute the following commands, substituting “my-new-bucket-name” for an Amazon S3 bucket name that does not already exist e.g. [my-company-name]-[weblogic]

rpm -ivh s3cmd-0.9.9-1.el5.noarch.rpm
tar -czvf /tmp/oracle-weblogic-103.tgz /opt/oracle
s3cmd mb s3://my-new-bucket-name
s3cmd put /tmp/oracle-weblogic-103.tgz s3://my-new-bucket-name/oracle-weblogic-103.tgz

(For more information on s3cmd, see here).

You can check that the weblogic zip was uploaded correctly using a tool such as S3Fox.

Here is the RightScript. Substitute “my-new-bucket-name” for the bucket name you created in the step above.


# NOTE: relies on AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables having been set.

# get WL zip out of S3 using the s3cmd tool that's installed by default
s3cmd get my-new-bucket-name:oracle-weblogic-103.tgz /tmp/wl.tgz

# untar WL to install it
tar -zxvf /tmp/wl.tgz -C /

# report success
exit 0

Install the Domain

When I say “install”, I really mean “extract”! Download the test_domain Domain from here and use S3Fox or another equivalent tool to copy it over to the “my-new-bucket-name” folder in S3 that you created earlier. The RightScript below retrieves this domain from S3, extracts it and places it in the /mnt/domains folder. You must substitute “my-new-bucket-name” for your S3 bucket name. This domain is a basic domain that has no servers or clusters configured – these will be configured later in RightScripts.


# NOTE: relies on $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY environment variables having been set.

# get domain zip out of S3 using the s3cmd tool that's installed by default
s3cmd get my-new-bucket-name:test_domain.tgz /tmp/test_domain.tgz

# untar domain to install it
tar -zxvf /tmp/test_domain.tgz -C /

# report success
exit 0

Start Weblogic Admin Server

This script simply runs the admin server and redirects output to a log file. This should probably be replaced with an init.d script in a production setup.


mkdir /mnt/logs/

# start up weblogic
nohup /mnt/domains/test_domain/ > /mnt/logs/weblogicAdmin.log 2>&1 &

Create Cluster

This script contacts the Administration server on a defined hostname and port and creates a Weblogic cluster using the Weblogic Scripting Tool (WLST).

#!/bin/bash -e

PY_FILE="/tmp/create-cluster_"`date "+%s"`.py

cat < $PY_FILE



/opt/oracle/weblogic/common/bin/ $PY_FILE

rm -rf $PY_FILE

Add Server To Domain

This script uses WLST to connect to an admin server and create a new server in the domain. The server’s name will be that of the machine’s EC2 public DNS name.

#!/bin/bash -e

SERVER_NAME=$(eval "curl")
PY_FILE="/tmp/create-server_"`date "+%s"`.py

cat < $PY_FILE



/opt/oracle/weblogic/common/bin/ $PY_FILE

rm -rf $PY_FILE

Start Managed Weblogic

This script starts up a Weblogic managed server instance which connects to the admin server and downloads all the domain info required. It relies on being able to download a security file – SerializedSystemIni.dat from your “my-new-bucket-name” folder in S3. Download this file here and upload it to S3 using S3Fox or an equivalent tool. Change the “my-new-bucket-name” folder in the script below to reflect your bucket name. This should probably be replaced with an init.d script in a production setup.



SERVER_NAME=$(eval "curl")

# create the server domain directory structure
mkdir -p $DOMAIN_HOME
mkdir -p /mnt/logs

# create the file
echo "username=$SERVER_USERNAME" >> $BOOT_FILE
echo "password=$SERVER_PASSWORD" >> $BOOT_FILE

echo "using admin URL: http://$ADMIN_SERVER_DNS_NAME:$ADMIN_SERVER_PORT"

mkdir -p $START_ROOT/security
s3cmd get my-new-bucket-name:SerializedSystemIni.dat $START_ROOT/security/SerializedSystemIni.dat

# start up weblogic
nohup /opt/oracle/weblogic/common/bin/ $SERVER_NAME http://$ADMIN_SERVER_DNS_NAME:$ADMIN_SERVER_PORT > /mnt/logs/weblogicManaged-$SERVER_NAME.log 2>&1 &

Create the ServerTemplates

Now that we have the basic RightScripts to construct Weblogic instances, we can create the ServerTemplates that logically group the scripts together.

Click on the Design > ServerTemplates link in the navigation bar in RightScale. Click on ‘new’ to create a new Server Template and call the template “Weblogic Admin”. Choose “EC2 US” and “m1.small” for the cloud and instance type attributes respectively. Use the browser tool to select the image “RightImage CentOS5_2V4_1_10”. Leave the rest of the attributes as their defaults and click ‘save’.

Click on the ‘scripts’ tab in the newly-created server template and add the RightScripts that you created earlier as boot scripts, in the following order: Install Weblogic, Install Domain, Start Weblogic Admin Server, Create Cluster, Add Server To Domain, Start Managed Weblogic. As you can see, this should install a weblogic server, create the domain and start the admin server. It should also create a cluster and a server in the domain and then finally start up the server.


Create another server template called “Weblogic Managed” with the same cloud, instance type and image attributes as “Weblogic Admin”. Add the following scripts as boot scripts in this order to the template: Install Weblogic, Add Server To Domain, Start Managed Weblogic.


Start the instances

In the RightScale navigation bar, go to Manage > Deployments and click on ‘default’. Click on “Add EC2 US server”. For the Server Template, select Private > Weblogic Admin. Enter “Weblogic Admin 1” as the nickname and choose the SSH key that you want to use. Use a security group that has ports 7001 and 7002 open. Leave the rest of the attributes as defaults and click “Add”.

Repeat these steps to create “Weblogic Managed 1” which uses the Weblogic Managed template. You should now have two servers configured in the “Default” deployment and it should look something like the screenshot below (note that my servers are in the EU):

Servers for "Default" deployment

Launching the servers

Click on the launch icon next to the “Weblogic Admin – 1” server and you should see a screen prompting you for some parameters. These are all the input parameters required by the RightScripts that will run at boot time. Enter the information as shown in the screenshot below and click on the ‘Launch’ button:


Wait until RightScale shows the status of the server as “operational” – this can take a while (8mins or so), so be patient! Once it’s started, click on the server name and then on the audit entries tab. The latest audit entry should have status “operational”. Click on this and you should see a list of the scripts that ran at startup and their outcomes:

Audit entries

On the info tab of the server, you should see the public DNS name of the server e.g. “”. Go to the URL: http:://[public-dns-name]:7001/console and log in with the username/password weblogic/weblogic.

If you click on the environment > servers link, you should see an Admin server and a managed server configured in a cluster. The managed server name should correspond to the public DNS of the machine:

Weblogic console servers

Now, in the RightScale console, start up the other server – “Weblogic Managed – 1” using the following inputs (substituting “Weblogic Admin – 1” for “Weblogic EU Admin – 1”) :

Inputs for Weblogic Managed

Once the managed server has started up, hit refresh in the Weblogic console. You should see the second managed server appear and the screen should look something like my one below:

Weblogic console showing all connected servers


Using the RightScripts provided in this post, you can easily deploy a Weblogic cluster using just two server templates. Adding new nodes is simple – just create another server based on the “Weblogic Managed” template and when the node starts up, provide it with the parameters it needs to connect to the admin server. The RightScripts take care of the rest for you.

Configuring Oracle ASM On Amazon EC2

As part of the work we did for running Astrometric Processing on Amazon EC2, we needed to configure an instance of Oracle Enterprise 11g using ASM (Automated Storage Management)

The steps in this post are based on the Oracle supplied AMI ami-7ecb2f17 which includes Oracle 11g 11.06 Enterprise Edition 64bit.

You can use the EC2 tools to launch instances, but for the purposes of this post I will use ElasticFox.

For convention in this post, I will use the following prompt symbols: $$ for your Local PC, and EC2$ for the remote EC2 instance

Step 1: Launch the instance

Launch ami-7ecb2f17 as a large instance. Once it is running you will have to wait a couple of minutes for SSH to be available. When you connect, using Putty or whichever tool you prefer, accept the license and choose a password as shown below.


At the next prompt “Would you like to create a database now”, select no.

Before you proceed, this image has a small problem. The /mnt partition isn’t mounted and as it is, we won’t have enough space to be able to create a new image based on this one.

This is an easy fix adding the following line to the end of /etc/fstab

/dev/sdb   /mnt      ext3    defaults        0 0

and executing the following in a shell

EC2$ mount /mnt

Step 2: Assign an elastic IP

In order for Oracle to work well, it’s better to have a static IP for it, and for that we will assign an Elastic IP.
Using Elastic Fox or the API tools create an Elastic IP e.g. and assign it to the instance

Change the instance hostname to be the public DNS name

EC2$ hostname

Step 3: Prepare ASMLib

Download Oracle ASMLib from the oracle website here making sure you chose the right drivers for this kernel: 2.6.18-
Ah. First problem, there aren’t any for this particular kernel, so we’ll download the nearest ones available which are the 3 drivers for 2.6.18-53.1.13.el5

Once downloaded, copy the rpm’s up to your instance and install them

EC2$ rpm -Uvh    oracleasm-support-2.1.3-1.el5.x86_64.rpm 
EC2$ rpm -Uvh  oracleasm-2.6.18-53.1.13.el5xen-2.0.4-1.el5.x86_64.rpm 

Because of the incompatibility of the drivers the second step will give us an error:

error: Failed dependencies:
kernel-xen = 2.6.18-53.1.13.el5 is needed by oracleasm-2.6.18-53.1.13.el5xen-2.0.4-1.el5.x86_64

We have to force the install and then use the script /usr/lib/oracleasm/oracleasm_debug_link to create a link between the two dependencies. If you have Oracle MetaLink see notes 805535.1 and 4626181.1
Here we need to add a small caveat. If you do the next steps, Oracle won’t support you. I imagine that this will change soon as they are committed to EC2

EC2$ rpm -Uvh --nodeps oracleasm-2.6.18-53.1.13.el5xen-2.0.4-1.el5.x86_64.rpm  
Preparing...                ########################################### [100%]
   1:oracleasm-2.6.18-53.1.1########################################### [100%]
   2:oracleasmlib           ########################################### [100%]

Create the link between the oracleasm packages

EC2$ /usr/lib/oracleasm/oracleasm_debug_link 2.6.18-53.1.13.el5xen 2.6.18-

Now we need to configure ASMlib using /etc/init.d/oracleasm configure

Believe it or not, that’s the hard part done. The rest is much, much easier.

Before we go any further with configuring Oracle we need some persistent storage for ASM. I’m going to attach 5 EBS (Elastic Block Storage) volumes of 100GB each to the instance using devices /dev/sdg through to /dev/sdk.

For each disk we need to create a primary partition for ASM

And then we have to create the disk for ASM


Step 4: Configure the ASM and the Database

Because these are EC2 server images, and therefore don’t have X installed, we have to execute dbca using pre-recorded response files.

EC2$ dbca -silent -responseFile dbca_ASM.rsp

EC2$ dbca -silent -responseFile dbca_AGISDB.rsp

You can download the response file I used for ASM here and the response file for creating the database here

Step 5: Start your databases

EC2$ echo "startup" | sqlplus -s / as sysdba
EC2$ echo "startup" | sqlplus -s / as sysdba
EC2$ echo "AGISDB Started"

Step 6: Fix /etc/inittab

The /etc/inittab generated by oracle doesn’t have the run level in it that Amazon EC2 instances have, run level 4. To fix this edit /etc/inittab and change the following line

h1:35:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1 


h1:345:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1 

Copy /etc/inittab to /etc/inittab.fixed

Add the following to /etc/init.d/dbora

/u01/app/oracle/product/11.1.0/db_1/bin/localconfig delete
/u01/app/oracle/product/11.1.0/db_1/bin/localconfig add
cp /etc/inittab.fixed /etc/inittab
emctl start dbconsole

Optionally start your databases

Final step: Create your new image

From your PC, copy your certificates up to the running instance

$$ scp -i   /*.pem root@ec2-xx-xx-xx-xxx.compute-1.amazonaw

Inside the image, create a new image bundle making sure you exclude the /mnt directory where your certificates are. If you create a public image with your certificates embedded in them, you compromise the security of your images.

EC2$ ec2-bundle-vol -d /mnt  -e /mnt,/apps -k /mnt/pk-.pem -c /mnt/cert-.pem -r x86_64 -u  -p mynewinstance

Upload the bundle to S3 to a suitable place, e.g. myimages

EC2$ ec2-upload-bundle -b myimages -m /mnt/mynewinstance.manifest.xml -a  -s 

Finally, register the image in EC2
$$ ec2-register myimages /mynewinstance.manifest.xml

I think I've included everything. If you have problems, please let me know.