Deploying the enterprise archive (EAR) using the WebSphere Admin Console

About this task


The doc ear does not contain end-user documentation, such as context-sensitive help files. It contains only development-related documentation, including API Javadoc, ERDs, and XSDs and should not be deployed to a production server. Deploy the doc ear with the application ear on test or development environments. Do not deploy the doc ear on a production environment.

Sterling Call Center provides support for deploying Multiple EARs (Enterprise Archives) on a single application server. On the same application server, you can:

  • Deploy different customizations of the same or different versions of the application, or
  • Deploy different versions of the same application

Multiple EARs or context roots require additional memory for the application server JVM. Testing has shown that the deployment of a second IBM® EAR file requires 2.5 - 3.5 times the memory of a single EAR. Supporting two deployments may require up to 2.5 GB of heap space and 1.2 GB of permanent space.

Note: If you are deploying an EAR that contains EJBs, consider increasing the JVM heap size in the <WAS_HOME>/deploytool/itp/ to avoid out-of-memory issues while deploying:
EJBDEPLOY_JVM_HEAP="-Xms2048m -Xmx2048m"
Note: Before deploying JAX-WS web services on WebSphere®, note that the WebSphere server will attempt to inspect every jar in the WEB-INF lib by default. To avoid this behavior, which can add a significant amount of time to the deployment of the JAX-WS web services, configure the WebSphere server to ignore certain jars during deployment of the JAX-WS web service. Add any jars that the server should skip to the Ignore-Scanning-Archives section in <WAS_HOME>/properties/ file. The jars you include will depend on what applications you build and so forth. One way to determine what jars to filter is to extract the SIXBean war file and use the jar -tvf command on it. Put the jar files you find in the WEB-INF/lib into the file.

To deploy the EAR on WebSphere:


  1. From the WebSphere Administrative Console menu in the left pane, select Applications > Application Types > WebSphere enterprise applications.
  2. The right pane is populated with a list of applications that are deployed. Click the Install button.
  3. Choose Local File System or Remote File System. Click the corresponding Browse button and browse to the Enterprise Archive such as smcfs.ear you want to deploy. Click Next.
  4. Choose Fast Path option. Click Next.
  5. Check Deploy enterprise beans, and change the application name as follows:
    • Ensure that there are no spaces in the application name; otherwise, the WebSphere-provided jsp compiler script will fail.
    • Ensure that the application name is different from that of the documentation EAR; otherwise, accepting the default makes both names the same.

      If you are using Web services, check Deploy WebServices.

      Note: If you want to precompile the JSP files during deployment, check Precompile JavaServer Pages files.

      Click Next.

  6. The Map Modules to Servers screen displays. Select the checkbox next to each desired module (at least two entries, smcfsejb.jar and smcfs.war, should be present). Click the Cluster/Server in the Cluster and Server pane. Click Apply. The screen refreshes and the server field is updated with the chosen value. Click Next.
  7. Accept the default JNDI names for the EJB modules on the Provide JNDI Names for Beans screen. Click Next.
  8. On the Map Virtual Hosts for Web Modules screen, select your web module and its correct virtual host. Choose Next.
  9. The Ensure all Unprotected 2.x Methods screen displays. Click Next.
  10. The Provide Options to perform the WebServices Deployment screen displays. Leave them as is and click Next.
  11. On the summary page, choose Finish.
  12. If you are deploying the Sterling Field Sales application, make the following additional changes in the WebSphere Administration Console:
    1. For each one of the application servers where you deploy the Sterling Call Center application, verify that the ClassLoader Policy is set to Multiple.
    2. Navigate to Enterprise Applications > Application Name > Class Loader. Set the Class Loader Order to "Classes loaded with local class loader first (parent last)."
    3. Navigate to Enterprise Applications > Application Name > Class Loader. Set the WAR Class Loader Policy to "Class Loader for each WAR file in application."