Resources

• Products & Solutions
• System Requirements
• Samples
• Install Center
• Third-Party Software Reference
• Documentation
  • What's New in SAS
  • Product Index A-Z
  • SAS Viya
  • SAS 9.4
  • SAS 9.3 and Earlier
• Papers
• Focus Areas

SAS^® AppDev Studio^™ 3.3 Developer's Site

Deploying Web Applications with SAS AppDev Studio

This page provides general information about Web application deployment. For information relating to specific application servers or servlet containers, see:

• Tomcat Deployment Information
• WebLogic Deployment Information

Production Server Requirements

Before you deploy your Web application, make sure that your production environment meets the SAS AppDev Studio 3.2 System Requirements. Basically, you can deploy to any application server and/or servlet container that provides full support for the Servlet 2.3/JSP 1.2 standard using JDK 1.4.0 or higher. However, when deploying to a production environment, only certain combinations or JDK and application server are supported for various systems. For details about the supported combinations and the server security fixes that must be installed, see the Third Party Software page, specifically the JDK (Java Software Development Kit) and Application Servers sections.

General Deployment Process

Overview

The following provides a short checklist of steps that you need to take to deploy Web applications developed with SAS AppDev Studio 3.2 Eclipse Plug-ins. It is not meant to be a comprehensive list; the remaining sections of this document provide the additional details you need. Instead, this section serves as a quick reference to help make it easier to deploy Web applications.

1. Choose the form of deployment, WAR file or source directory, if supported. If a WAR file, also choose, if necessary, whether the Web application will be served in expanded form or directly from the WAR file.

2. Determine if any changes to the Web application are needed to account for switching environments from development to production, and how those changes will be handled. For example, it might be necessary to modify which SAS servers are accessed by the Web application.

3. Prepare the WAR file. If you want to deploy a source directory, it would be created by expanding the WAR file to the desired deployment location.

4. Deploy the Web application to application server or servlet container.

5. Update the application server or servlet container with any settings needed by the Web application.

6. Start or restart the Web application or server, as needed.

7. Test the deployed Web application to make sure the deployment was successful.

It is best if these items are considered when development of a Web application begins and during development. This will help you avoid surprises during deployment and having your choices limited. These items are discussed in more detail in the sections that follow.

Choosing the form of deployment

Using a WAR file is the typical way to deploy the Web application's content. It involves a single file and is supported by the Servlet specifications. The specifications also support serving the Web application directly from the WAR file. However, this isn't required. When serving a Web application in an expanded form, the specifications don't require the expanded form look like the WAR directory structure, though it is likely to be similar or identical.

Thus, it is best to develop the Web application such that it can be served directly from the WAR file. If this isn't feasible, then you should verify what the expanded form looks like on your expected target application servers or servlet containers. You would also have the option of using the source directory form of deployment, if supported.

If you plan to have a Web application served from a WAR file, make sure you avoid the use of ServletContext.getRealPath() and ServletRequest.getRealPath(). Both of these methods will return null when the Web application is served from a WAR file.

Determine if changes are needed to switch to production

It is likely that any SAS servers accessed by a Web application during development will need to change when it is deployed to the production environment. What needs to change depends on how the server locations are built into the web application. Such settings could be in properties files or the web.xml file in some fashion. If you are using SAS Foundation Services, switching to the production version of the services metadata source will likely involve additional changes.

How the settings are implemented can impact the choices available to implement the changes. For example, the application server or servlet container may allow modifying web.xml settings after the Web application is deployed. It might also be feasible to implement the settings using System properties. This might avoid making changes to the Web application just prior to deployment, but may dictate that the application server or servlet container may need to be restarted to have new System properties take effect.

If making changes just prior to deployment can't be avoided, switching might be automated using Ant or some other build tool. The Eclipse that the SAS AppDev Studio Eclipse Plug-ins requires includes built in support for running Ant build scripts.

Prepare the WAR file

In Web Tools, it is not unusual for a Web application project not to physically contain all the resources that comprise the Web application. In particular, JAR files which are part of the Web application may exist in the form of utility projects or be found in a location outside of the project. Creating the WAR file provides the important step of pulling all the resources together, even if you intend to deploy the Web application as a source directory. This can be accomplished using the Eclipse Export wizard using the following steps.

1. Select File Export to open the Export wizard.
2. Select WAR file and click Next.
3. Select the Web Module from the list and specify the Destination.
4. Select the Export source files and Overwrite existing file check boxes as needed
5. Click Finish.

Web Tools also provides the ability to validate certain resources, such as a Web application's web.xml file. The default is to run this validation automatically when changes occur to those resources. If this default validation has been turned off, you should run the validation manually to ensure there are no errors reported before creating the WAR file.

Deploy the Web application to the application server or servlet container

Use the application server or servlet container specific procedure to deploy the WAR file, or expand the WAR into a source directory, if supported. If deploying a WAR file, note that it is not typically required that the context name under which the Web application is served match the name of the WAR file. However, when using automated procedures, the WAR file name will typically be used as the context name by default. If this matters, modify the WAR file name to the desired context name prior to deployment. When using automated procedures with a source directory, it might be necessary to modify the name of the subdirectory holding the Web application content to obtain the desired context name.

Update application server or servlet container settings

This step involves applying any needed changes to the application server or servlet container settings to account for the addition of the Web application. If necessary, the minimum and maximum heap sizes should be adjusted. If the Web application creates lots of transient objects, garbage collection options may need to be tuned. The changes might also include adding runtime permissions required by the Web application, and if appropriate, enabling a security manager, if not already enabled.

There might also be post-deployment Web application changes needed. For example, depending on the Web application's memory consumption and its anticipated user load, an adjustment to the session timeout might be in order. There could also be additional Web application settings specific to the application server or servlet container that need setting or adjusting.

Start or restart the Web application or server

Depending on what changes were required in the prior step, the actions necessary to get the Web application running correctly should be one of the following:

• Restart the application server or servlet container. This would be necessary if JVM related settings changed, such as policy file changes and/or System properties.
• Restart the Web application. This would be necessary if Web application specific settings were changed that didn't automatically trigger a Web application restart.
• Start the Web application. This would be needed if the Web application required manual starting after any updates to Web application specific settings.

The specifics of performing any of the actions above will depend on the application server or servlet container being used.

Test the deployed Web application

As always, thoroughly testing the deployed Web application is necessary to verify the deployment was successful. This includes verifying that the Web application can access all of the required SAS servers and spawners. You must also make sure that any required updates have been applied to the SAS servers.

You should also inspect the application server or servlet container's status information or log files to see if anything unusual occurred. The Servlet 2.3 specifications do not clearly define what should happen if problems are encountered during deployment and startup of the Web application. For example, if during Web application startup, the class for a filter declared in the web.xml file fails to load, it isn't specified whether the Web application should be allowed to run without this filter or prevented from running. Behavior in a case like this could vary.