Administer > Deploy > Deploying customized assets > Customized WebSphere Commerce Enterprise Application (EAR) assets

Deploy custom J2EE assets

You deploy the J2EE assets to WebSphere Application Server.

WebSphere Application Server provides two tools to update the J2EE application with the customized applications:

• Administrative console update wizard

• wsadmin scripting tool methods

Both tools use the application update functions to update the WebSphere Commerce J2EE application with the new or changed assets. Regardless of the WebSphere Application Server topology, you use the tools the same way. If you are working in a clustered environment, the process to deploy the customization is same as in a non-clustered environment.

Regardless of whether you use the graphical or scripting tools, always back up the J2EE assets before you deploy.

Administrative console update wizard

A Web-based graphical user interface used to manage the WebSphere Application Server configuration. 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 the preferred language (JACL or Jython are supported), using the WebSphere Application Server administrative objects to manage the configuration. See Start the wsadmin tool for usage instructions.

What happens during application updates?

WebSphere Application Server manages the WebSphere Commerce J2EE 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_PROFILE /installedApps/cell/instance .ear, which contains the expanded copy of the 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 the WebSphere 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 the cluster.

In general, when you update the enterprise application, this is the WebSphere Application Server process:

Procedure

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 the 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:

Multiple updates
If you have multiple updates with the deployment, it is more efficient to complete all updates before you save the 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

• Deploy J2EE assets for a single file
  This option provides the ability to deploy a single file asset into the J2EE application

• Deploy J2EE assets for a partial application
  The partial application option provides the ability to deploy several files into the J2EE application at the same time. You must also use this option to delete any number of files that are in the J2EE application.

• Deploy J2EE assets for an entire module
  The single module option provides the ability to deploy an entire module to the J2EE application. Since there are many different types of modules in J2EE applications the steps can differ depending on the module type.

• Deploy a WAR module
  The single module option provides the ability to deploy an entire WAR module to the J2EE application. Since there are many different types of modules in J2EE applications the steps can differ depending on the module type.

• Compiling JavaServer Page files
  Compiling the JavaServer Page (JSP) files in the site or store will significantly reduce the amount of time needed to load the store. As a result, it is recommended that you batch-compile the store or site JSP files after publishing a store archive and after deploying JSP files to a production environment.

• Validate changes have been deployed for a custom Enterprise Application (EAR) file
  Once you have deployed the custom EAR file, you should validate that the changes have been successfully deployed.

Previous topic: Package custom J2EE assets

Related concepts

Remote widgets for e-Marketing Spots

Dynamic caching

Related tasks

Package custom J2EE assets

Deploy J2EE assets for a single file

Deploy J2EE assets for a partial application

Deploy J2EE assets for an entire module

Validate changes have been deployed for a custom Enterprise Application (EAR) file

Compiling JavaServer Page files

Related reference

Troubleshoot: Deployment

+

Search Tips   |   Advanced Search