Develop patterns for IBM PureApplication System

Best practices and tips for developing virtual application and virtual system patterns

During the process of implementing and validating real ISV business applications on the IBM® PureApplication™ System, the authors gathered some best practices, tips, and how-tos for developing both virtual application patterns (VAPs) and virtual system patterns (VSPs). In this article, the authors share some of those secrets with virtual pattern developers to guide them through their pattern development process.

Yuki Miyata (ymiyata@jp.ibm.com), IDR Technology Executive, IBM

Yuki Miyata is a technology executive with ISV and Developer Relations Japan, specializing in solutions and platforms with WebSphere products and PureApplication System. He has more than 12 years experience in WebSphere technical support, including WebSphere beta projects and cloud-related projects. Since last year, he has been working on enabling ISV solutions on IBM PureApplication System.



Kohsuke Sakamoto (khirk@jp.ibm.com), IDR Technology Executive, IBM

Kohsuke Sakamoto is an information technology specialist with ISV and Developer Relations in IBM Japan. His work includes technical support for ISVs in healthcare industry, which covers many platforms and products from databases, application servers to virtualization. His latest focus is on enabling ISVs application on IBM PureApplication System.



Hideki Gohara (gohara@jp.ibm.com), IDR Technology Executive, IBM

Hideki Gohara is an information technology specialist with ISV and Developer Relations in IBM Japan. He assists ISVs technically, covering many server platforms, OS, and virtualization products. He specializes in migrating ISVs application on IBM PureSystems.



09 July 2012

Also available in Chinese Russian Japanese Portuguese

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.

Figure 1. Class Loader in WAS console
Class Loader in WAS console

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
    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
    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
    Configuring the OLTP plug-in properly

Now we'll look at some VSP practices.


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
    Command Assistance
  6. Copy the script in screen: Administrative Scripting Commands (such as AdminTask, AdminConfig).
    Figure 6. Copy the script in the screen
    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
    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
    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
    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.

Figure 10. Changing the time zone on the DB2 side
Changing the time zone on the DB2 side

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:

Figure 11. Changing the time zone on the WebSphere Application Server side
Changing the time zone on the WebSphere Application Server side

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
    Unmounting the file system
    Figure 13. Create DB2 database
    Create DB2 database topology

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
    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]]')

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

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Cloud computing on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • Cloud digest

    Complete cloud software, infrastructure, and platform knowledge.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing, WebSphere, Information Management
ArticleID=824042
ArticleTitle=Develop patterns for IBM PureApplication System
publish-date=07092012