Unzip the file to an installation directory, e.g. “/midvision” for linux or “C:\midvision” for windows.

This will create a directory called midvision. This location will now be referred to as $MV_HOME, e.g. “/midvision” for linux or “C:\midvision” for windows.

Edit the remote agent orchestration file.

If you plan to use a remote agent to run the deployments on the target servers then you will need to edit the remoting server file, putting in the host name of the server it will accept deployment requests from. Find the hostname of the machine you have installed the application to then type hostname from a command prompt.

e.g:

Windows	Linux
C:\Users\user1>hostname	[root@cloud ~]# hostname
user1-MV	cloud.server.com

Goto $MV_HOME/remoting and edit the file midvision-remoting-server.xml. On line 43 change line:

<resource type=”auth.servers”>gui@localhost</resource>

To gui@hostname e.g.

<resource type=”auth.servers”>gui@user1-MV</resource>

Start the server and the remoting agent.

Goto $MV_HOME/bin and the run the start-up scripts to start the web app and the remote agent.

Windows	Linux
start-web-app.bat	start-web-app.sh
start-remoting-server.bat	start-remoting-server.sh

Wait until you see “INFO: Server startup in“ in the output logs of the tomcat console (which opens as a separate window in Windows environments), alternatively check the $MV_HOME/logs/rapiddeploy-web-app.log for the line ”RapidDeploy web application is started” and ensure there are no errors, then go to http://localhost:9090/MidVision in a web browser. (Replace localhost with your linux server hostname/IP as appropriate)

At the login page enter the default username “mvadmin” and the default password “mvadmin” then click “Login”.  You will then be presented with a license page. Request a trial license from MidVision by emailing licensing@midvision.com. Once you have been emailed the license, enter the values on the screen and accept the EULA.

Note: This demo uses a Hypersonic in-memory database. This means if the web application process is killed from the Task Manager or a “kill” command then all data will be lost. To ensure that your data is stored to a file when the application is stopped, run the “stop-web-app.sh” or “stop-web-app.bat” script which is in the $MV_HOME/bin directory.

Use the Plugin Manager to Install the WebSphere Demo

Ensure the web application is started. Go to “Help / Plugin Manager” the “Available Plugins / Patches” tab. Click the “Install” button on the “WebSphere Example App” Plugin and then “Yes” to confirm, the project files will be downloaded to the $MV_HOME/projects directory. Once the download is complete the plugin will appear in the “Installed Plugins / Patches” tab.

Alternatively, download the latest zip file from http://www.midvision.co.uk/wordpress/dnld/plugins/demo_projects_310/rapiddeploy-demo-projects-3.1.0-websphere.zip and unzip in the root of your RapidDeploy installation (MV_HOME).

Configure the Resources.

Please note. If you are running RapidDeploy against an oracle database, a Sql script can be found in $MV_HOME/plugins/WebSphere Example App/<VERSION> that will create all of the following resources for you. You will still need to edit each project and replace “MV_HOME” with the correct path to the RapidDeploy install directory, and run a discovery on each project by editing it and then clicking “Discover” and clicking “Ok” to confirm.

Create the Projects

Go to “Resources/Projects/Add Project” then enter the following information (remember to change $MV_HOME with the actual location).

Field	Value
Name	WEBSPHERE_BinaryInstall_BaseND
Description	WEBSPHERE_BinaryInstall_BaseND desc
Owner	mvadmin
Deployment Type	binaryInstall
Collection Type	WAS_CLUSTER_70
Log Directory	$MV_HOME/logs
Project Root Directory	$MV_HOME/projects/WEBSPHERE_BinaryInstall_BaseND
Properties Directory	$MV_HOME/projects/WEBSPHERE_BinaryInstall_BaseND/j2ee/config
Build Store	$MV_HOME/buildstore
Promotion Store	$MV_HOME/promotionstore
Deployment package search string	WASND
Properties file identifier	py
Master in Database	False(not selected)

Then click “Create”. Now add another project.

Field	Value
Name	WEBSPHERE_BinaryInstall_CreateNodeProfile
Description	WEBSPHERE_BinaryInstall_CreateNodeProfile desc
Owner	mvadmin
Deployment Type	binaryInstall
Collection Type	WAS_CLUSTER_70
Log Directory	$MV_HOME/logs
Project Root Directory	$MV_HOME/projects/WEBSPHERE_BinaryInstall_CreateNodeProfile
Properties Directory	$MV_HOME/projects/WEBSPHERE_BinaryInstall_CreateNodeProfile/j2ee/config
Build Store	$MV_HOME/buildstore
Promotion Store	$MV_HOME/promotionstore
Deployment package search string	WASND
Properties file identifier	py
Master in Database	False(Not Selected)

Then click “Save”.

Then click “Create”. Now add another project.

Field	Value
Name	WEBSPHERE_7_DEPLOY
Description	WEBSPHERE_7_DEPLOY desc
Owner	mvadmin
Deployment Type	codeDeploy
Collection Type	WAS_CLUSTER_70
Log Directory	$MV_HOME/logs
Project Root Directory	$MV_HOME/projects/WEBSPHERE_7_DEPLOY
Properties Directory	$MV_HOME/projects/WEBSPHERE_7_DEPLOY/j2ee/config
Build Store	$MV_HOME/buildstore
Promotion Store	$MV_HOME/promotionstore
Deployment package search string	WEBSPHERE_DEPLOY
Properties file identifier	py
Master in Database	False(Not Selected)

Then click “Save”.

Now edit the project named WEBSPHERE_7_DEPLOY and then click “Discover” and click “Ok” to confirm.

This will search the project configuration directory and look for the environment definition files and create any servers, environment, instances and deployment components it finds in to the application database. The environments are defined by the file names defined in the project properties directory. The structure of the environment filename is this:

SERVER.ENVIRONMENT.INSTANCE.APPLICATION

In a WebSphere context this relates to:

SERVER.WEBSPHERE_CELL.WEBSPHERE_CLUSTER.APPLICATION

As the project WEBSPHERE_7_DEPLOY has a pre-configured environment definition, the discovery will create a new server named “wasserver01”, a new environment named “wascell01” and a new instance named “DEFAULTServer”. We will later configure the connection details to the server so we can install WebSphere and also we will configure the environment and the instance.

Now add another project – the final one!

Field	Value
Name	WEBSPHERE_7_CONFIGURE
Description	WEBSPHERE_7_CONFIGURE desc
Owner	mvadmin
Deployment Type	codeDeploy
Collection Type	WAS_CLUSTER_70
Log Directory	$MV_HOME/logs
Project Root Directory	$MV_HOME/projects/WEBSPHERE_7_CONFIGURE
Properties Directory	$MV_HOME/projects/WEBSPHERE_7_CONFIGURE/j2ee/config
Build Store	$MV_HOME/buildstore
Promotion Store	$MV_HOME/promotionstore
Deployment package search string	WEBSPHERE_CONFIGURE
Properties file identifier	conf
Master in Database	False(Not Selected)

Now edit the project named WEBSPHERE_7_CONFIGURE and then click “Discover” and click “Ok” to confirm.

Orchestration Panel

It is worth looking at the project orchestration panel at this point. The Examples projects have preconfigured orchestrations, but these may be amended as desired to add or change individual task actions (from the list of around 150 on the left hand side) for this deployment. In the example below, the TOKENIZERS tree item is opened, displaying three tasks. Task actions are environment independent actions that run in sequence whenever this deployment project is run (when any deployment package based on this project is deployed).

In this case we see the runIIP task highlighted, with its values in the “Selected Task Detail” pane.

Take a look at the orchestrations for the other projects.

Linux Configuration Tip: The orchestrations for all of these WebSphere projects will work correctly out of the box for Windows and Linux.

Configure the Server

Goto “Resources/Targets/Servers” then edit the server named wasserver01. Edit these fields (remember to change $MV_HOME with the actual location, you will also need to ensure the Build Store directory exists on your target):

Field	Value
General Tab
Display Name	wasserver01
Hostname	localhost
Build Store:	$MV_HOME/remotebuildstore
OS Type:	<Select your OS type>
Version:	<Set your OS version>
Allow Deployments:	True
Connection timeout (ms):	2000000
Remoting Tab
Agent Enabled for deployments:	True
Agent Enabled for discovery:	True
Remote Agent Port:	20000
Agent Path:

Then click “Save”.

Click edit on the server named “wasserver01”” and then click “Test Agent” and click “Yes” to confirm. The application will then check it can communicate with the remote agent. You should see the following output:


Test Success
The test connection completed successfully.


If the test was successful.

Configure the WebSphere Installation Directory for WEBSPHERE_BinaryInstall_BaseND

In this section we define the file path that WebSphere will be installed into on the target server for base binary and Dmgr profile.

Go to “Resources / Targets / Installations” then click “Add Environment Installation”.

Enter these fields. Remember to change $WAS_HOME with the actual location you want to install WebSphere to, the default value for this demonstration example is:

Linux: “/midvision/apps/WebSphere7/ndbase70”

Windows: “c:/midvision/apps/WebSphere7/ndbase70”

Field	Value
Installation Path	$WAS_HOME
Server	wasserver01
Project	WEBSPHERE_BinaryInstall_BaseND

Then click “Create”.

Add the following Environment Variables to the installation :

Key	Value
startingPort	28000
hostName	localhost
cellID	wascell01
adminUserName	wasadmin
adminPassword	wasadmin

Configure the WebSphere Installation Directory for WEBSPHERE_BinaryInstall_CreateNodeProfile

In this section we define the file path that WebSphere will be installed into on the target server.

Go to “Resources / Targets / Installations” then click “Add Environment Installation”.

Enter these fields. Remember to change $WAS_HOME with the actual location you want to install WebSphere to, the default value for this demonstration example is:

Linux: “/midvision/apps/WebSphere7/ndbase70”

Windows: “c:/midvision/apps/WebSphere7/ndbase70”

Field	Value
Installation Path	$WAS_HOME
Server	wasserver01
Project	WEBSPHERE_BinaryInstall_CreateNodeProfile

Then click “Create”.

Add the following Environment Variables to the installation :

Key	Value
startingPort	29000
hostName	localhost
cellID	wascell01
adminUserName	wasadmin
adminPassword	wasadmin
dmgrHost	localhost
dmgrPort	28003

Install WebSphere and Create a Dmgr profile

Now you have defined a server and an installation directory you can install WebSphere to your target server at the location specified. Using the WebSphere binary file downloaded at the start of this document, add it to the $MV_HOME/buildstore directory otherwise you will not have a package to install.

Now start the install job. Go to “Job / New Job”. Select the project WEBSPHERE_BinaryInstall_BaseND the open the server tree and select the EnvironmentInstallation you created in the earlier step, then click “Next”.

Select the version (which is the file you have copied to the buildstore). Then select “Skip to finish” and then click “Next”. Click “Execute Request” then click “Yes” to confirm. WebSphere will start to install in the target server. You can click the “View Progress” button on the job and you should see the deployment log files.

In this binary installation the following tasks are executed:

1. Check there is at least 1024Mb of free space on the target server at the install directory.
2. Check the directory is writable
3. Install WebSphere to the directory.
4. Create a Deployment manager Profile
5. Secure soap.client.props and check/change ownerships and permissions of all files
6. Start the Dmgr
7. Modify Dmgr Heap

When the job has finished you will see the text:


2011-12-21 12:01:34,902 [Thread-12] INFO  com.midvision.rapiddeploy.utilities.exec.LocalScriptRunner - 100%
2011-12-21 12:05:48,173 [Thread-12] DEBUG com.midvision.rapiddeploy.utilities.exec.LocalScriptRunner - Closing streams...
2011-12-21 12:05:48,174 [Thread-12] INFO  com.midvision.rapiddeploy.utilities.exec.LocalScriptRunner - Execution finished, exit code 0
2011-12-21 12:05:48,214 [Thread-12] INFO  com.midvision.rapiddeploy.orchestration.tasks - Task [ WebSphereBinaryInstallTask ]...Fixing permissions...
2011-12-21 12:05:48,214 [Thread-12] INFO  com.midvision.rapiddeploy.orchestration.tasks - Task [ WebSphereBinaryInstallTask ]...Finished... 2011-12-21 12:05:48,214 [Thread-12] INFO  com.midvision.rapiddeploy.orchestration.tasks - Work Unit ... Complete ...
2011-12-21 12:05:48,214 [Thread-12] INFO  com.midvision.rapiddeploy.orchestration.tasks - Finishing generic-batch...
2011-12-21 12:05:48,214 [Thread-12] DEBUG com.midvision.rapiddeploy.orchestration.tasks - Return Code = 0 Completed RapidDeploy Deployment Request


You can go to “Jobs / Previous Jobs” and you can download and view the log file of the complete deployment.

Create a nodeagent profile

Now start the nodeagent creation job. Go to “Job / New Job”. Select the project WEBSPHERE_BinaryInstall_CreateNodeProfile the open the server tree and select the EnvironmentInstallation you created in the earlier step, then click “Next”.

Select the version (which is the file you have copied to the buildstore). Then select “Skip to finish” and then click “Next”. Click “Execute Request” then click “Yes” to confirm. WebSphere will start to install in the target server. You can click the “View Progress” button on the job and you should see the deployment log files.

In this installation the following tasks are executed:

1. Check there is at least 1024Mb of free space on the target server at the install directory.
2. Check the directory is writable
3. Start the Dmgr Server if it is not running
4. Create a node profile
5. Secure soap.client.props and check/change ownerships and permissions of all files
6. Start the Dmgr
7. Federate this node to the Cell (Dmgr instance)
8. Modify nodeagent Heap

Install a sample WebSphere Cluster, Application and Resources

Check configuration

If you have installed WebSphere in a location other than c:/midvision/apps/WebSphere7 (Windows) or /midvision/apps/WebSphere7  (Linux), please change the data dictionary in the WEBSPHERE_7_DEPLOY project  as follows:

Goto “Environment/ Edit/Promote” then select the WEBSPHERE_7_DEPLOY project from the drop down.

Click the edit button next to the environment.

From the menu panel, select Dictionary/Data Dictionary:

Amend the values to match your chosen WebSphere install.

Create a deployment package

Goto “Resources/Software Management/Packages” then select the WEBSPHERE_7_DEPLOY project from the drop down.

Click “Add Package Wizard” button and enter “WEBSPHERE_DEPLOY_001″ as the package name. Check the “Skip to Finish” checkbox and click next.

Click “Create This Deployment Package” on the final tab.

We have now packaged our project directory, including a war file and all the required configuration to create the target domain. This package can be used to create our environment. It could also be used to create additional environments by simply cloning the configuration of the first environment. Instructions can be found in the RapidDeploy User Guide. For our purposes, creating one environment using this method is sufficient.

Repeat the steps in this section but this time create a package for the project “WEBSPHERE_7_CONFIG” and name the package “WEBSPHERE_CONFIG_0_0_1″.

Deploy the Package (WEBSPHERE_7_DEMO).

Go to “Jobs / New Job” then select the project WEBSPHERE_7_DEPLOY then open the server, environment, instance and select the application “examplesWebApp” then click “Next”.

Now select the version, which is the deployment package you have just created, select “Skip to finish” then click “Next”. Click “Execute Request” then click “Yes” to confirm. This will start to deploy the package.

The steps taken in this deployment are:

The following steps will:

1. Deploy the package to the target
2. Expand the ear file inside the  package
3. Perform some environment specific search/replace actions
4. Perform some environment specific XPATH search/replace actions
5. Perform some environment specific search/replace actions inside a jar file inside the ear
6. Compress the Ear file again
7. Perform a WebSphere install. Create/Modify a Cluster; Create an APplication server as a member of this new cluster; Set JVM Properties; Set Logging values, Create/Modify a Virtual host etc; Set all ports; Set WAS Variables.
8. Create a JMS provider
9. Create a JDBC provider and DataSource
10. Install the sample application modified above. Perform Application to Resource mappings (Such as Web Modules to Virtual Hosts).
11. Start the new cluster.

Once the job has completed you can view the deployment log file from the Previous Jobs section.

Check the Cell

The following Url: http://localhost:10030/snoop/ should return the standard Snoop servlet message from the installed application.

Log into and explore the WebSphere install by accessing the Admin Web UI at: https://localhost:28001/ibm/console

Username: wasadmin

Password: wasadmin

Snapshot a WebSphere Server Profile

Now WebSphere has been installed we can take a snapshot of the default configuration to use as a control when configuration changes are made.  When we use RapidDeploy to take a snapshot of WebSphere we use JMX to connect to the DM and retrieve all the configuration settings.  For an environment snapshot the scope of the snapshot is from the Cell level and for an instance snapshot the scope of the snapshot if from the Server or Cluster level, depending on what you have configured the Instance to.

Before a snapshot can take place we have to load some WebSphere client jars onto the classpath of RapidDeploy and the remote agent and then restart them.  MidVision cannot distribute these client libraries as they are packaged with the WAS installation.  These client jars are backwards compatible to previous versions of WAS, therefore always use the latest client libraries if you have more than one version of WAS installed in your infrastructure.

Copy these three client WebSphere jar files ($WAS_HOME = /midvision/apps/WebSphere7/ndbase70):

• $WAS_HOME/plugins/com.ibm.ws.emf.jar
• $WAS_HOME/plugins/com.ibm.ws.security.crypto.jar
• $WAS_HOME/runtimes/com.ibm.ws.admin.client_7.0.0.jar

To the following directories:

• $MV_HOME/lib
• $MV_HOME/web-apps/tomcat/webapps/MidVision/WEB-INF/lib

We also need to amend Rapiddeploy_default.properties or rapiddeploy.properties to change the following values to those matching your local WebSphere cell:

#---------------------------------
# IBM WebSphere AS
#---------------------------------
ibm.websphere.admin.username.default=wasadmin
ibm.websphere.admin.password.default=wasadmin
ibm.websphere.admin.keystore.path=C:/midvision/apps/WebSphere7/wascell01/DeploymentManager/etc/DummyClientKeyFile.jks
ibm.websphere.admin.truststore.path=C:/midvision/apps/WebSphere7/wascell01/DeploymentManager/etc/DummyClientTrustFile.jks
ibm.websphere.admin.keystore.password=WebAS
ibm.websphere.admin.truststore.password=WebAS

Now restart RapidDeploy and the Remote Agent (see above for instructions).

Configure the Environment (WebSphere installation – all profiles)

Go to “Resources / Targets / Environments” edit the environment named “wascell01”. Enter the following values (remember to change $WAS_DM_HOME with the actual location):

Field	Value
General Tab
Display Name	wascell01
Parent Server display name	wasserver01
Owner	mvadmin
Software Product:	IBM WebSphere 7
Environment Type:	Unknown
Software Version:	7.0.0.19
Binary Path:	$WAS_DM_HOME e.g. C:/midvision/apps/WebSphere7/wascell01/DeploymentManager (Windows, note the drive is specified) or /midvision/apps/WebSphere7/wascell01/DeploymentManager (Linux)
Connectivity Tab
Admin Port:	28003
Connection String:
Environment Admin Username:	wasadmin
Environment Admin Password:	wasadmin

Then click save.

Configure the Instance

Go to “Resources / Targets / Instances” edit the instance named “DEFAULTServer”.  This is normally the logical name of  a cluster or stand alone server to deploy to. Enter the following values:

Field	Value
General Tab
Instance Name	DEFAULTServer
Parent Environment name:	wascell01
Parent Server display name	wasserver01
Owner	mvadmin
Collection Type:	WAS_CLUSTER_70
Software Version:	7
Binary Path:
Allow deployments	True
Connectivity Tab
Hostname
Port:	28003
Username:	wasadmin
Password:	wasadmin
Alias:

Then click Save.

Take a Cell (Environment) Snapshot

Now we will take a snapshot of the version of WebSphere that has just been installed. It is a “Golden Image” version of the configuration, which will be used to compare against in the future.

Go to “Resources / Targets / Environments” edit the environment named “wascell01“. Then click “Snapshot” then click “Yes” to confirm. The snapshot will be requested. You can go to “Jobs / Executing Jobs” and see the log output of the snapshot.

Make a change to Configuration through the WebSphere Console.

Log in to the WebSphere Console. Select Servers / Websphere application servers / DEFAULTServer / Java and process management / Process Definition / Java Virtual Machine

Change the “Maximum heap size” to 1024, save the changes.

Now take another snapshot as was done in the previous section.

Compare The Snapshots

Go to “Environment / Environment Comparison”, click on “Snapshot Comparison”.  Enter “5” into the “Comparison Context size (optional 1-50):” field.  This will display 5 lines above each difference and 5 line below, to give the comparison some context.  If you leave this field blank it will display the complete XML, which can be quite large.  Then select snapshot with ID 2 for the left side and snapshot with ID 1 for the right side:

Now click “Compare”.

You should see the configuration differences from the “Golden Image” domain to the changed domain.

Deploy the Package (WEBSPHERE_7_CONFIG).

In the previous section we have used python scripts to deploy an application and configuration to WebSphere, this next project will demonstrate how to use the JMX based tasks to deploy and configure WebSphere.

Go to “Jobs / New Job” then select the project WEBSPHERE_7_CONFIG then open the server, environment, instance and select the application “DefaultApplication” and the application “rapiddeploy-test-ear” then click “Next”.

Now select the version, which is the deployment package you have just created, select “Skip to finish” then click “Next”. Click “Execute Request” then click “Yes” to confirm. This will start to deploy the package.

The steps taken in this deployment are:

The following steps will:

1. Deploy the package to the target
2. Install the sample applications modified above, but this time using JMX. Perform Application to Resource mappings (Such as Web Modules to Virtual Hosts).

Once the job has completed you can view the deployment log file from the Previous Jobs section.

Check the Applications have Deployed

The following Url: http://localhost:10030/snoop/ should return the standard Snoop servlet message from the installed application.

The following Url: http://localhost:10030/jpetstore should load the pet store application.

Create further environment definitions from the created one

Convert Snapshot to Template

Now that we have a template of our “Golden Domain”, we can turn that into a template for creating as many new environments as we need. We can then keep these environments (typically our “Route To Live” environments) in sync throughout the lifecycle of our project, deploying new versions of code, configuration or both. We can always roll back to our Golden Image, or any subsequent change made upon it, by redeploying previous deployment packages.

Please see the RapidDeploy User guide for assistance in converting a snapshot to a template and deploying out to subsequent environments.

Go to Environment / Edit/Promote. Select the WEBSPHERE_7_CONFIGURE project.

You will see one (preconfigured) environment. Click “Create Template from Snapshot Wizard”.

On the “Choose Location” tab, accept the default (this projects configuration directory). You can change this value if you want to use the configuration from this project to “seed” another project.

Click “Next”

On the “Snapshot Selection” tab, select one of the snapshots you took above.

Click “Next”

On the “Name” panel you need to give the new environment you are creating a name, based on the server, environment instance and application you are going to deploy to.

Some values may be prefilled with the values from the originating environment (where the snaposhot was taken from). Add additional values. In this case set the instance to “DEFAULTServer” and the application to “DefaultApplication1“.  Ensure the “Auto Template” check box is checked.

Click “Next”

On this panel we convert the snapshot to a template by adding placeholder variables to the snapshot, which are replaced at deploy time to environment specific values.  However, in this example we will do this in a later stage.

You can also use the download/upload buttons to download the snapshot to your desktop and edit in your favorite browser.

Click “Next”.

On this panel all the auto template items will be displayed.

Click “Next”

On the final tab click “Create this environment”. The template files will be copied to the project, and the configuration and dictionary files created.

Returning to the “Edit/Promote” panel we now see the new environment.

The buttons to the right enable us to edit the environment files, promote changes to the environment properties to other environments, delete or copy this environment. Please see the user guide for a complete description.

For example as administrators we can directly edit project files, stored on the RapidDeploy server (possibly in a configuration management tool) through the GUI.

Now we will edit the template and create some more environment specific tokens.  Click the “Edit” button on the new environment (Application name: DefaultApplication1).

The template process created some default settings which we will need to modify. Go to “Properties” -> “Instance Configuration”.  You should see these settings which you need to check are correct.

Below is a description of each setting:

ADMIN_PORT - This is the SOAP port to the DM.
BINDINGS - This is the HOST to the DM.
SOAP_CLIENT_PROPS_PATH – This is what is used to connect to the DM, using the soap properties set in this file, ensure this path is correct.  If it is wrong then the Environment binary path setting is also wrong and will need changing, as it is used to derive this setting. (It is also possible to connect using a username and password or key store and trust store files using other properties -USERNAME, PASSWORD, KEY_STORE_PATH, TRUST_STORE_PATH, KEY_STORE_PASSWORD, TRUST_STORE_PASSWORD)
TEMPLATE_XML_FILE – This is the project relative path to the snapshot template.
TARGET_MAPPINGS – If left as “DEFAULT” then the JMX tasks will use the environments application name to find the EAR file to deploy and map that EAR file to the server or cluster.  In this case the application name is set as “DefaultApplication1″ which is different from the EAR file “DefaultApplication.ear”.  Therefore, in this scenario, this setting needs changing to “DefaultApplication=DEFAULTServer“.

We also need to specify installation property to map the web module to the virtual host.  So add this property and save the changes.

MapWebModToVH = [[Default Web Application, DefaultWebApplication.war,WEB-INF/web.xml, DEFAULTServer]]

The changes should look like this:

SOAP_CLIENT_PROPS_PATH	C:/midvision/apps/WebSphere7/wascell01/DeploymentManager/properties/soap.client.props	Plain Text
TEMPLATE_XML_FILE	j2ee/TEMPLATE/wascell01/localhost_wascell01_28003_wasadmin_201211111550279.xml	Plain Text
TARGET_MAPPINGS	DEFAULT	Plain Text
ADMIN_PORT	28003	Plain Text
BINDINGS	localhost	Plain Text
MapWebModToVH	[[Default Web Application, DefaultWebApplication.war,WEB-INF/web.xml, DEFAULTServer]]	Plain Text

Now edit the environment again and select “Resources” / “Files”, then navigate to the template XML file: “WEBSPHERE_7_CONFIG” -> “j2ee” -> “Template” -> “wascell01″ -> *.xml

This file is quite large as it contains the entire cell configuration.  Find the initial heap size setting for the DEFAULTServer (which has been tokenised to @@SERVER_NAME_3@@).  Do a find for the value “initialHeapSize” and ensure the setting is for the server named @@SERVER _NAME_3@@.

Now replace the JVM heap size values with environment tokens @@SERVER_NAME_3_INITIAL_HEAP_SIZE@@ and @@SERVER_NAME_3_MAX_HEAP_SIZE@@.  Then click “Save”.

Now navigate to the Data Dictionary for that environment and create the tokens and the new literal values for this environment:

@@SERVER_NAME_3_INITIAL_HEAP_SIZE@@ = 256
@@SERVER_NAME_3_INITIAL_HEAP_SIZE@@ = 1024.

Then click “Save”.

Create a package

Create another deployment package as described above. This time use the “WEBSPHERE_7_CONFIGURE” project. Name the package “WEBSPHERE_CONFIGURE_0_0_2”

Modify the Orchestration to now also Deploy the Configuration via JMX

Go to the Project “WEBSPHERE_7_CONFIGURE” and click the “Edit” button, then select the “Orchestration” tab.  Enable the task “DeployConfigurationViaJMXTask” by checking the check box. Then save the change.

Deploy the package

Use “WEBSPHERE_7_CONFIGURE” project, and select the package created above.

You will notice you have three targets to deploy to now, the two shipped with this demo and the one you have just created. In this demo example these are actually the same target environment we created previously.

Take a snapshot

Take another snapshot of the target environment. Notice that the initial heap size has now changed to “256″.

Result

We have used the snapshot/template/promote to push a changed heap size back to our original domain. In fact we could have used this method to push our entire configuration of the “golden” domain to another vanilla WebSphere install, which would have created all of the servers, clusters, JMS and Database providers present in the first instance.