Deploying custom Java EE assets

You deploy your Java EE assets to WebSphere Application Server.

WebSphere Application Server provides two tools to update your Java EE application with your customized applications:
  • Administrative console update wizard
  • wsadmin scripting tool methods
Both tools use the application update functions to update the WebSphere Commerce Java EE application with your new or changed assets. Regardless of your WebSphere Application Server topology, you use the tools the same way. If you are working in a clustered environment, the process to deploy your customization is same as in a non-clustered environment.
Important: Regardless of whether you use the graphical or scripting tools, always back up your Java EE assets before you deploy.
Administrative console update wizard
A Web-based graphical user interface used to manage your WebSphere Application Server configuration. You can use this tool initially to learn about the deployment process. This tool cannot be used for automated deployments.
wsadmin tool
A command line scripting tool that can be used to automate WebSphere Application Server configuration tasks. The tool provides several language options. You write scripts in your preferred language (JACL or Jython are supported), using the WebSphere Application Server administrative objects to manage the configuration. See Starting the wsadmin tool for usage instructions.

What happens during application updates?

WebSphere Application Server manages the WebSphere Commerce Java EE application. It is imperative that you only use the WebSphere Application Server utilities to manage the application. Any updates you do to the application without using the tools can be lost when installing WebSphere Commerce maintenance or when migrating to the next version of WebSphere Commerce.

WebSphere Application Server maintains several copies of the application:
Application binaries
Application binaries are contained in a directory, typically WC_profiledir /installedApps/cell/instance_name .ear, which contains the expanded copy of your application. Note that cell, here, denotes the name of the cell at the time the application was installed, not the cell name post installation. At runtime, this directory is used to load WebSphere Commerce application classes and JSP files.
Master copy of the application
A collapsed version of the WebSphere Commerce application. It is used by theWebSphere Application Server application management utilities. When you export the application, it is this file that is returned; changes in the application binaries directory are not exported with the application. This collapsed copy is also used when the application server distributes the application to the nodes that are part of a cluster; therefore, changes to the application binaries directory are not reflected on all of the nodes of your cluster.

Procedure

In general, when you update the enterprise application, this is theWebSphere Application Server process:
  1. Update
    1. The collapsed copy of the application is checked out of the application server's configuration repository.
    2. The changed assets are merged into the collapsed copy of the application.
    3. A descriptor is created that describes the changes to the application.
  2. Save
    1. The new collapsed copy of the application and descriptor is checked into the configuration repository.
  3. Synchronize
    1. The new application is synchronized with the nodes that are running the application. (This is only when using a deployment manager configuration.)
  4. Expand
    1. The changed assets are extracted from the master copy of the application and copied to the application binaries directory.
    2. File permission is set on the changed assets in the binaries directory.
    3. The application is restarted automatically.

Results

The following diagrams illustrate WebSphere Application Server environments.
Diagram showing how application updates work in a standalone WebSphere Application Server environment with single node within your cell

How application updates work in a standalone WebSphere Application Server environment where you have a single node within your cell
Diagram illustrating a simple managed environment where you have a Deployment Manager that manages two application server nodes. Use this diagram to understand how application updates work in a managed WebSphere Application Server environment:

Simple managed environment where you have a Deployment Manager that manages two application server nodes
Multiple updates If you have multiple updates with your deployment, it is more efficient to complete all updates before you save your changes instead of saving after each update. In general, the correct process is:
  1. Update using full module (see package and deploy for a full module)
  2. Update using partial application (see package and deploy for a partial application)
  3. Save
Not
  1. Update using full module
  2. Save
  3. Update using partial application
  4. Save