The IBM PureApplication System supports two types of virtual patterns: Virtual application patterns and virtual system patterns.

• The virtual application pattern (VAP) is a workload-level virtualization pattern which includes everything up to application platform expertise.
• The virtual system pattern (VSP) is the topology-level virtualization pattern which includes only up to middleware expertise.

This article describes some best practices for each of the pattern development types, practices that we came across when implementing these patterns for real-world purposes.

VAP practices

The virtual application pattern practices described in this article include:

1. Changing the Class Loader mode and policy. This enables pattern developers to easily build VAPs for applications that need their Class Loader mode and policy changed. (Class Loader policies control the isolation of an application.)
2. Performing put/get operations with an FTP server. This enables pattern developers to build VAPs for applications that need to access to external FTP servers. This tip can be applied to other servers such as external HTTP servers, RSS servers, and so on.
3. Troubleshooting why you cannot deploy a DB/DBaaS VAP when you get an OLTP error. This lets pattern developers understand (and avoid) the missing OLTP error.

Change Class Loader mode and policy

In IBM WebSphere® Application Server (WAS), you can change the order to load the classes by changing the Class Loader.

For example, if you want to load your class first, set the Class Loader mode as PARENT_LAST. Normally in WebSphere Application Server, the Class Loader mode is set via the WebSphere Application Server admin console after installing the EAR.

In a VAP, however, you are not allowed to change any configurations in the deployed VM. Instead, JVM policy in the Virtual Application Builder supports the Class-Loader-related configurations.

To configure JVM policy:

1. In Virtual Application Builder, add JVM policy on Enterprise Application.
2. Select PARENT_FIRST or PARENT_LAST for Class Loader Order and select MULTIPLE or SINGLE for WAR Class Loader Policy.
   
   Figure 2. Changing Class Loader by changing JVM policy
   
   
   

Perform put/get operations with an FTP server

If you want your virtual application pattern application to connect to an FTP server and put/get files, you need to define general targets in the Virtual Application Builder:

1. In Virtual Application Builder, define Generic Targets for port 20 and 21 and link them from the Enterprise Application component.
2. Enter FTP server name, IP address, and port number for each Generic Target.
   
   Figure 3. To perform put/get on an FTP server
   
   
   

Note: To fix the ports to connect to FTP server, you should use active mode instead of passive mode in your application.

Can't deploy a DB VAP due to OLTP error?

You might encounter a problem in which you cannot deploy a VAP of a web app that might include a database or DBaaS pattern. Instead, you get an OLTP system plug-in error that can look like this:

! Contact an administrator to configure the "oltp" system plug-in.

! Contact an administrator to configure the "oltp" system plug-in for "IBM Transactional 
  Database Pattern" environment based on your choice for the "Purpose".

This can occur because the system plug-in is not configured properly. To correct the error:

1. In the Workload Console, select Cloud > System Plug-ins > IBM Transactional Database Pattern > oltp and click Configure.
2. Select Both for Environment and click OK.
   
   Figure 4. Configuring the OLTP plug-in properly
   
   
   

Now we'll look at some VSP practices.

Back to top

VSP practices

The virtual system pattern practices described in this article include:

1. Creating wsadmin scripts for efficient VSP deployment: Make a datasource creation script and create an EAR installation script. A wsadmin script is difficult to create from scratch without any assistance or instruction. With this tip, pattern developers can easily create the wsadmin scripts to be used for a VSP.
2. Importing and exporting a VSP. This will show pattern developers how to use the command line interface, a very good way to restore the script packages and add-ons manually and copy the migrating pattern. It also introduces the concept of the DBCS (double-byte character set) environment which could trip up a pattern developer.
3. Changing the VM time zone setting for a VSP. In case you don't want the default UTC.
4. Expanding the size of DB2 file system for a VSP. For when you need a larger file system.
5. Transferring tables or data from an existing DB to a VSP. In case the DB is set by manual input or a dedicated tool and you need the data in another DB.
6. Using DB2 drivers that have been tested with your application. Obviously a driver that already works with your application would be the best one to include in the VSP package.

Deploy VSPs with wsadmin scripts

When deploying a virtual system pattern, use a Jython script file (*.jy) with wsadmin. You can easily create a Jython script by using a command assistance function from the WebSphere Application Server admin console.

Creating a datasource creation script
To build a datasource script:

1. When a virtual machine creates an instance, the following links are auto-generated: VNC and WebSphere. (Open the section Virtual machines in the virtual system instance.)
2. Click the WebSphere link. Login with UID: virtuser and a password you set.
3. This example is used when configuring a datasource. After invoking the Integrated Solutions Console, select Resources > JDBC > Data sources from the left menu.
4. Click the New button in the Preferences section and follow Step 1 to Step 5.
5. After clicking Finish, in the right pane click Command Assistance > View administrative scripting command for last action.
   
   Figure 5. Command Assistance
   
   
   
6. Copy the script in screen: Administrative Scripting Commands (such as AdminTask, AdminConfig).
   
   Figure 6. Copy the script in the screen
   
   
   
7. Update the description in a file like the createDatasource.jy Jython file of the createDatasource.zip by referencing to the scripts copied in Step 6.

Creating an EAR installation script
You just learned how to build a script creating a datasource. Now let's create a script to install an Enterprise Archive file.

1. When a virtual machine creates an instance, the following links are auto-generated: VNC and WebSphere. (Open the section Virtual machines in the virtual system instance.)
2. Click the WebSphere link. Login with UID: virtuser and the password you set.
3. After invoking the Integrated Solutions Console, select Applications > New Application > New Enterprise Application from the left menu.
4. Enter the path to the new application (where you put the EAR file).
5. Select Fast Path or Detailed. If you select Fast Path, follow Step 1 to Step 3.
6. After clicking Finish, in the right pane click Command Assistance > View administrative scripting command for last action.
7. Copy the script in screen: Administrative Scripting Commands (such as AdminTask, AdminConfig).
8. Update the description in a file like installApp.jy that can be found in the installApp.zip by referencing to the scripts copied in Step 6.

Export/import a VAP

In a VAP, you can export and import the modules with just one click. In a VSP, however, you need to restore the script packages and add-ons manually and copy the migrating pattern by a deployer command to a new environment.

To prepare:

1. Download a command line tool from IBM PureApplication System welcome screen and unzip it to <WORKING_DIRECTORY> (approx. 8MB).
   
   Figure 7. Download the command line tool
   
   
   
2. If you use a deployer command tool in a DBCS environment, then move to <WORKING_DIRECTORY>\deployer.cli\lib\3.1.0.0-20111118232331. The directory name is different depending on the version. Edit the registry file; uncomment the two rows (Figure 8) and edit the codeset.
   
   Figure 8. In a DBCS environment
   
   
   

A DBCS (double-byte character set) environment is one in which the character set is comprised of all characters (including control characters) encoded in two bytes OR merely every graphic character not representable by an accompanying S(ingle)BCS is encoded in two bytes. A DBCS supports national languages that contain a large number of unique characters or symbols, for example Japanese, Korean, and Chinese.

To export:

1. Download and save the script packages (if any, add-ons as well) for the subject pattern.
2. Move to <WORKING_DIRECTORY>\deployer.cli\bin and run a deployer command. A sample command can be something like this:

   deployer -h host_IP_address -u user_name -p password -f ..\samples\patternToPython.py -f xxx_vsp.py

   
   .
   
   Figure 9. Save script packages and add-ons
   
   
   

Select the subject source pattern you want to copy from the previous screen and export the Python script (xxx_vsp.py) (any file name you like that ends with .py) to use later for a target virtual system pattern.

To import:

1. Now that you downloaded the source script packages (as well as add-ons), create a script package (and add-ons) with the exact same name as the original one and upload the downloaded ZIP files. Make sure the parameters are set correctly by clicking the Refresh button.
2. Import the VSP file (xxx_vsp.py) you exported in the previous steps to a new environment using the deployer command. Use a command similar to this:

   deployer -h host_IP_address -u user_name -p password -f xxx_vsp.py

   
   Be aware: If the same pattern name exists, remove it before executing the deployer command.
3. Deploy the VSP you just imported in to the cloud. After the deployment, confirm that it runs okay as an instance.

Change the VM time zone setting for the VSP

The time zone of a deployed VM is set as UTC by default. If you want to change it, you need to describe it in the script. (In a VAP, you are not allowed to change from UTC).

On the DB2 side, if you want to change the time zone to JST (Japan Standard Time), describe the following in the DB creation script.

To change the time zone on the WebSphere Application Server side, then put in the first script executed in the WebSphere Application Server VM the following:

Expand the size of DB2 file system for VSPs

If a large-volume data migration is necessary in a VSP DB2 environment (nominally more than 20GB), you'll discover that a default size file system is not sufficient. You can add a disk by using an add-on function and increase the file system size.

1. In the Workload Console, choose Catalog > Add-Ons.
2. Select Default add disk in the left pane and confirm the Environment: parameters in the right pane.
3. In the VSP DB2 topology, place the Default add disk from the add-on menu and change the default value of Environment: DISK_SIZE_GB = 10 to a disk size you need. Also, enter the file system type and mount point (voluntary).
4. Create an additional script package by referring to the sample descriptions in Figure 12 ("test_adddisk" in Figure 13). Then place it before executing the database script package ("Create DB2 database test" in Figure 13).
   
   Figure 12. Unmounting the file system
   
   
   
   
   Figure 13. Create DB2 database
   
   
   

After you deploy, you can use /db2fs file system with its disk size increased in the DB2 VSP.

Transfer tables/data from existing DB in a VSP

If it is difficult to create a script for DB creation and data loading because the DB is set by manual input or a dedicated tool. You might need to create a script to transfer the data from the existing DB.

To use db2 backup:

1. Backup from the existing DB with:

   db2 backup db DB_name to backup_file_name compress

   
   
2. Create a script to restore data from the backup file and package it with the backup file:

   db2 restore db DB_name from backup_file_name

   
   

Note: In this method, the script package tends to become large since the backup file is packaged in it. In addition, this method depends on the platform involved, so for example, there is no compatibility between different endians such as IA Linux (little endian) and AIX (big endian). To avoid these issues, use the db2move method.

With the db2move method:

1. Acquire the DDL file from the existing DB:

   db2look -d DB_name -a -e -l -x -f -td % -o DDL_file_name

   
   
2. Acquire the data from the existing DB:

   db2move DB_name export -sn schema_name

   
   
3. If tables, including generated columns exist, export them:

   db2 export to table_name.ixf of ixf messages table_name.msg select * from table_name

   
   
4. Create a script like in Figure 14.
   
   Figure 14. Using db2move
   
   
   
5. Create a script package by packaging the files acquired from Steps 1 through 3 and the script.

Use DB2 drivers that have been tested with your application

You might want to use the DB2 drivers that have been tested with your application rather than the DB2 drivers provided by PureApplication System. In VSPs, you can replace them by packaging the DB2 drivers that you want to use.

1. Include the tested DB2 drivers (db2jars.zip) to the script package for DB2 driver installation.
2. Describe the following process in the script for DB2 driver installation:

   # Copy db2jar.zip and extract the driver files at /opt/db2 directory chmod 777 /tmp/script_package_name/db2jars.zip mkdir /opt/db2 chown virtuser:users /opt/db2 cp /tmp/xxxx_installDB2Drivers/db2jars.zip /opt/db2 sudo -u virtuser unzip -d /opt/db2 /tmp/xxxx_installDB2Drivers/db2jars.zip # Add the DB2 driver path to the environment variable echo "export DB2UNIVERSAL_JDBC_DRIVER_PATH=/opt/db2" >> /etc/virtualimage.properties source /etc/virtualimage.properties

   
   
3. Create a JDBC provider by setting the extracted DB2 driver JARs as the classpath in the wsadmin script for data source creation.
   • Sample code for non-XA datasource creation:

     AdminTask.createJDBCProvider('[-scope Cell=' + cellName + ' -databaseType DB2 -providerType "DB2 Universal JDBC Driver Provider" -implementationType "Connection pool data source" -name "DB2 Universal JDBC Driver Provider" -description "One-phase commit DB2 JCC provider" -classpath [/opt/db2/db2jcc.jar /opt/db2/db2jcc_license_cu.jar]]')

     
     
   • Sample code for XA datasource creation:

     AdminTask.createJDBCProvider('[-scope Cell=' + cellName + ' -databaseType DB2 -providerType "DB2 Universal JDBC Driver Provider" -implementationType "XA data source" -name "DB2 Universal JDBC Driver Provider (XA)" -description "DB2 Universal JDBC Driver Provider (XA)" -classpath [/opt/db2/db2jcc.jar /opt/db2/db2jcc_license_cu.jar]]')

     
     

Back to top

In conclusion

We hope that these best practices that we came across when implementing virtual cloud-oriented patterns for real-world purposes will be a good start to help you configure and deploy patterns into cloud environments.

Resources

Learn

• For more on using virtual patterns, visit PureSystems on developerWorks.
  
  
• In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
  
  
• Find out how to access IBM SmartCloud Enterprise; developing on SmartCloud is a great way to practice developing for IBM PureSystems.
  
  

Get products and technologies

• See the product images available for IBM SmartCloud Enterprise.
  
  

Discuss

• Join a cloud computing group on developerWorks.
  
  
• Read all the great cloud blogs on developerWorks.
  
  
• Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• VAP practices
• VSP practices
• In conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

Dig deeper into Cloud computing on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers