IBM Rational Automation Framework for WebSphere

Transcription

1 IBM Rational Automation Framework for WebSphere Guided Activity: Creating Dynamic Options For J2EE Application Deployment Using Rational Automation Framework for WebSphere v7.1.2 Contacts: Dale Ewald Alden Taylor Level: Intermediate April 2011

2 Page 2 of 20 Contents 1 Audience Overview Information resources Prerequisites Objectives Determine Deployment Scope in RAFW Using Samples to create a RAFW properties file for a J2EE application Providing the application EAR file to the RAFW environment tree Deploying applications to WebSphere Application Server Using Templates to generate a RAFW properties file Using Rational Build Forge to provide variable inputs into Templates Conclusion Appendix Trademarks Resources About the authors... 19

3 Page 3 of 20 1 Audience The audience for this guided activity is IBM WebSphere Application Server administrators and IBM Rational Automation Framework for WebSphere Engineers. You should have experience deploying applications to WebSphere Application Server, and have some familiarity with Rational Automation Framework for WebSphere basics. 2 Overview Application Deployment with Rational Automation Framework for WebSphere involves pairing a properties file with a deployable WAR or EAR file and executing an action that performs the deployment in the target WebSphere system. Learn the different ways of providing the properties file to Rational Automation Framework for WebSphere, and learn how this can be done dynamically with defaults and points of variability. This guided activity applies to a network deployment or standalone cell for WebSphere Application Server 6.0, 6.1, or 7.0. In this guided activity, the term product refers to Rational Automation Framework for WebSphere. 3 Information resources For information about deploying applications to WebSphere Application Server, refer to the IBM information center for your WebSphere product version. 3.1 WebSphere Application Server WebSphere Application Server WebSphere Application Server For information about Rational Automation Framework for WebSphere, refer to the product information center. 3.4 Rational Automation Framework for WebSphere

4 Page 4 of 20 4 Prerequisites These items must be completed prior to this Guided Activity: A. Create the WebSphere Application Server network deployment or standalone cell where the application is to be deployed. B. Create the Rational Automation Framework for WebSphere cell definition for the WebSphere Application Server cell. Use the Environment wizard to create the cell definition. C. Build the EAR file for the J2EE application. The <application>.ear file must exist before you can deploy it. D. Start the deployment manager or standalone server for the WebSphere Application Server cell. 5 Objectives A. Determine the deployment scope of your application B. Manually Create an <APP_NAME>.properties file i. Use the WebSphere administrative console to generate application deployment options in a wsadmin command script. ii. iii. Use the sample appname.properties as a guide to create a Rational Automation Framework for WebSphere <APP_NAME>.properties file for the J2EE application. Use the sample appname_split.properties as a guide to create a Rational Automation Framework for WebSphere <APP_NAME>.properties file for the target application. C. Copy or import the J2EE application EAR file to the ${SCOPE_HOME}/apps/media directory in the product Environment Tree for the WebSphere Application Server server or cluster. D. Deploy the J2EE application to a WebSphere Application Server server or cluster. E. Dynamically generate an <APP_NAME>.properties file i. Use the product-provided template appname_split.vm to generate a <APP_NAME>.properties file. ii. Use a custom appname_split.vm template to generate a <APP_NAME>.properties file. F. Create a Rational Build Forge Project to feed the inputs to a appname_split.vm template for <APP_NAME>.properties file generation. 6 Determine Deployment Scope in Rational Automation Framework for WebSphere The deployment actions in Rational Automation Framework for WebSphere support 3 scopes: CELL, CLUSTER, and SERVER.

5 Page 5 of 20 The rafw command in the product provides scope targeting in the form of parameters: CELL CLUSTER SERVER./rafw.[sh bat] env MYENV cell MYCELL./rafw.[sh bat] env MYENV cell MYCELL cluster MYCLUSTER./rafw.[sh bat] env MYENV cell MYCELL node MYNODE server MYSERVER The ${SCOPE_HOME} for each scope represent the following directories in the Environment Trees in the product: CELL ${RAFW_HOME}/user/environments/MYENV/cells/MYCELL CLUSTER ${RAFW_HOME}/user/environments/MYENV/cells/MYCELL/clusters/MYCLUSTER SERVER ${RAFW_HOME}/user/environments/MYENV/cells/MYCELL/nodes/MYNODE/servers/MYSERVER 6.1 Notes about choosing your Deployment scope: When the CLUSTER and SERVER scopes are specified for the product deployment actions, Rational Automation Framework for WebSphere will provide the MapModulesToServers option if it is not explicitly specified in the <APP_NAME>.properties file (more on this file in the next section). Use this to your benefit to increase reusability of this file across environments, and to minimize the number of deployment options that you provide in the properties file. When the CELL scope is specified for the deployment actions, the <APP_NAME>.properties file MUST specify the MapModulesToServers option. The Action will fail with an error if this is not specified. If you intend to target a cluster or server, do so by refining the Scope rather than using CELL scope and having to specify this option in the properties file. 7 Using Samples to create a Rational Automation Framework for WebSphere properties file for a J2EE application 7.1 Choosing a properties style With Rational Automation Framework for WebSphere 7.1.2, there are two types of properties files you can use to specify deployment options: 1. OPTIONS property style this style provides a properties file with minimal properties, and includes one OPTIONS= property that contains all WebSphere Application Server deployment options on one line. NOTE: The options provided in the OPTIONS property should be named the way wsadmin expects the options to be named (such as noprecompilejsps). ===================================================================== ################################################################

6 Page 6 of 20 ### ### ### This property file describes APP_NAME ### ### ### ################################################################ # Application Specific Info APP_NAME=APP_NAME APP_FILE=${SCOPE_HOME}/apps/media/${APP_NAME}.ear # war class loader policy: SINGLE=Application, MULTIPLE=Module WAR_CLASS_LOADER_POLICY=MULTIPLE # Application class loader mode # Application class loader mode options: PARENT_FIRST (default), PARENT_LAST CLASS_LOADER_MODE=PARENT_FIRST # Deployment options OPTIONS= =-noprecompilejsps -distributeapp -nousemetadatafrombinary -deployejb -creatembeansforresources -noreloadenabled -nodeployws -validateinstall warn - noprocessembeddedconfig -filepermission dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 -noallowdispatchremoteinclude.\*. - noallowserviceremoteinclude -MapWebModToVH [[ "PlantsByWebSphere Web Application" PlantsByWebSphere.war,WEB-INF/web.xml cluster1 ]] "PlantsByWebSphere Sample Gallery Web Application" PlantsGallery.war,WEB- INF/web.xml cluster1 ] ===================================================================== 2. SPLIT properties style this style provides a properties file that has all options split into individual properties. Using this style, it is easier to isolate default options from options that change from deployment-to-deployment or applicationto-application. NOTE: the options specified in each property are named and specified slightly different than wsadmin, such that wsadmin s noprecompilejsps will be listed as options.precompilejsps=false. The product handles the translation of these properties into wsadmin s options. ================================================================== ######################################################################## ### ### This property file describes APP_NAME for WAS 7.0 ### ### APP_NAME = The name of the application ear file without the.ear suffix### ### This file contains a listing of options that may be passed to wsadmin ### ### during an application deployment. For a detailed explanation of any ### ### particular option please consult the WAS 7.0 Information Center. ### ############################################################################### # Application Specific Info APP_NAME=APP_NAME APP_FILE=${RAFW_HOME}/user/environments/${ENV_NAME}/cells/${CELL_NAME}/apps/medi a/${app_name}.ear # war class loader policy: SINGLE=Application, MULTIPLE=Module WAR_CLASS_LOADER_POLICY=MULTIPLE # Application class loader mode # Application class loader mode options: PARENT_FIRST (default), PARENT_LAST CLASS_LOADER_MODE=PARENT_FIRST # Below are application deployment options for wsadmin, consult the link in the

7 Page 7 of 20 # header of this file for a detailed description of any option. # Precompile JavaServer Pages files # options.precompilejsps=true false # Distribute application # options.distributeapp=true false # The blaname option to specify the name of business level # application under which the system creates the Java EE application. # options.blaname=value # Use Binary Configuration # options.usemetadatafrombinary=true false... etc... options continued... ================================================================= 7.2 Finding the Samples There are samples of both both styles of property files in the product distribution, and can be found in the product here: ${RAFW_HOME}/samples/xml/was/common/appName.properties ${RAFW_HOME}/samples/xml/was/<version>/appName_split_<version>.properties 7.3 Determining the options to provide Being in charge of deployments, it is possible, if not probable; that you were not the developer that created the application that you are in charge of deploying. In this case you are not likely to know, without help, all the options to specify at deploy time to have a successful deployment that passes all smoke tests, functional tests, etc. In this situation, the development team should provide you with the non-default options required by the application. As the development team is deploying their application (perhaps manually in their development WebSphere Application Server console), they can use the View administrative scripting command for last action link on the Summary page of the Install Application workflow to capture the settings as they determine need to be specified:

8 Page 8 of 20 Figure 1 - Scripting Command for Options 7.4 Building your <APP_NAME>.properties file from a Sample A. Gather the options that you need to provide. B. Copy the desired sample properties file into the ${SCOPE_HOME}/apps/properties directory in the product Environment Tree. C. Rename this file according to your APP_NAME (i.e. myapp.properties) D. Modify the new properties file to match the options that are required for your application. See the notes below about default behavior of Rational Automation Framework for WebSphere for deployments and how it relates to your options. Notes about Rational Automation Framework for WebSphere default behavior for deployments: When using the View administrative scripting command for last action to determine your options, the appname <APP_NAME> parameter should be removed when using the OPTIONS property style, as the <APP_NAME>.properties file has a property reserved specifying this value. See the notes in the section titled Determine Deployment Scope in Rational Automation Framework for WebSphere about the MapModulesToServers option and whether or not you need to specify it. Rational Automation Framework for WebSphere will map the MapWebModToVH to default_host if it is not explicitly specified in the <APP_NAME>.properties file. 8 Providing the application EAR file to the Rational Automation Framework for WebSphere environment tree The product deployment action was_common_deploy_install_app requires that an EAR or WAR file be placed in the ${SCOPE_HOME}/apps/media directory. The ${SCOPE_HOME}/apps/properties/<APP_NAME>.properties file specifies the EAR or WAR file to use for the deployment, using the APP_FILE property.

9 Page 9 of 20 By default, the APP_FILE property is encoded such that the file will be an EAR and the file name will be the same as the APP_NAME; you have the option to modify the APP_FILE property to specify an alternate file name and to specify a WAR file instead. Notes about provisioning application EAR files to Rational Automation Framework for WebSphere You can use the was_common_deploy_export_app against the originating environment (such as Dev) to pull the EAR file from a live system. 9 Deploying applications to WebSphere Application Server The Rational Automation Framework for WebSphere deployment action was_common_deploy_install_app requires a single parameter: -a APP_NAME The a APP_NAME parameter on the action command tells the product to look for an <APP_NAME>.properties file in the ${SCOPE_HOME}/apps/properties directory. The product finds this properties file, and uses it to determine the file being deployed, using the APP_FILE property, and uses the other properties in the file as wsadmin options during deployment into the target WebSphere Application Server. 9.1 Deploy the application into WebSphere Application Server using Rational Automation Framework for WebSphere command CLUSTER scope (one line): ${RAFW_HOME}/bin/rafw[.sh.bat] -env MYENV -cell MYCELL -cluster MYCLUSTER -execute was_common_deploy_install_app -a MYAPP SERVER scope (one line): ${RAFW_HOME}/bin/rafw[.sh.bat] -env MYENV -cell MYCELL -node MYNODE -server MYSERVER - execute was_common_deploy_install_app -a MYAPP 9.2 Start the application using Rational Automation Framework for WebSphere command CLUSTER scope (one line): ${RAFW_HOME}/bin/rafw[.sh.bat] -env MYENV -cell MYCELL -cluster MYCLUSTER -execute was_common_deploy_start_app -a MYAPP SERVER scope (one line): ${RAFW_HOME}/bin/rafw[.sh.bat] -env MYENV -cell MYCELL -node MYNODE -server MYSERVER - execute was_common_deploy_start_app -a MYAPP 9.3 Deploy multiple applications into WebSphere Application Server using Rational Automation Framework for WebSphere command You can choose to do a bulk deployment, which can save processing time since the Rational Automation Framework for WebSphere command is performing the iteration over the specified applications. This performs faster than other automation logic. CLUSTER scope (one line): ${RAFW_HOME}/bin/rafw[.sh/.bat] -env MYENV -cell MYCELL -cluster MYCLUSTER -execute was_common_deploy_install_apps [-a MYAPP1,MYAPP2,MYAPP3]

10 Page 10 of 20 SERVER scope (one line): ${RAFW_HOME}/bin/rafw[.sh/.bat] -env MYENV -cell MYCELL -node MYNODE -server MYSERVER - execute was_common_deploy_install_apps [-a MYAPP1,MYAPP2,MYAPP3] Notes about application deployments When a WAR is deployed instead of an EAR file, WebSphere Application Server will create a wrapping EAR during installation, and the EAR application will have the same name as the APP_NAME. There is also an APP_NAME property in the <APP_NAME>.properties file. While this is a bit confusing, the purpose is to allow variances in the Application Name that is actually sent to WebSphere Application Server. The APP_NAME property will override the APP_NAME sent in on the parameter -a APP_NAME. 10 Using Templates to generate a Rational Automation Framework for WebSphere properties file Now that we ve talked about the foundations of application deployment with Rational Automation Framework for WebSphere, and the types of files used for deployment, let s have a look at the product s ability to generate a SPLIT properties style file for an application from a Template Templates in Rational Automation Framework for WebSphere Rational Automation Framework for WebSphere ships with a distribution of Apache Velocity, an open-source template engine. Templates are used in a few different areas in the product, and can be found in the product at ${RAFW_HOME}/product/templates appname_split.vm Template This product-provided template can be found under ${RAFW_HOME}/product/templates/deploy/was/<version>/ At first glance, this template looks very similar to the appname_split.properties Sample we discussed earlier, except that all options are surrounded by Velocity Template Language (VTL) conditional statements (#if / #end) to determine what properties should be included in the output, and include $variable references that are used to populate values that are sent in from the shell environment. #if ($opt.precompilejsps) # Precompile JavaServer Pages files options.precompilejsps=$opt.precompilejsps #end Multiples are also handled in the template, so that items like MapResRefToEJB (resource reference mapping) can happen multiple times according to application requirements. Note the VTL #foreach / #end in the following example: # maps resource references to resources #foreach( $child in $opt.mapresreftoejb.rafwchildren ) options.multi.${velocitycount}.mapresreftoejb=["$child.ejbmodule" "$child.ejb" "$child.uri" "$child.resourcereference" "$child.resourcetype" "$child.targetjndiname" "$child.login" "$child.properties" ] #end

11 Page 11 of Using the product template in Rational Automation Framework for WebSphere command The product action rafw_model_create_was_app_deploy_file -a APP_NAME uses the ${RAFW_HOME}/product/templates/deploy/was/<version>/appName_split.vm to generate an <APP_NAME>.properties file based on inputs that you provide. The simplest example of providing the input data is using the -opt parameters on the action command (all should be on one line): ${RAFW_HOME}/bin.rafw.[sh bat] -env MYENV -cell MYCELL -cluster MYCLUSTER - execute rafw_model_create_was_app_deploy_file -a MYAPP -opt APP_FILE=MYAPP_v2.0.1.ear -opt precompilejsps=true -opt MapResRefToEJB.1.EJBModule=MYAPP -opt MapResRefToEJB.1.EJB= -opt MapResRefToEJB.1.URI=MYAPP.war,WEB-INF/web.xml -opt MapResRefToEJB.1.resourceReference=jdbc/DevDatasource -opt MapResRefToEJB.1.resourceType=javax.sql.DataSource -opt MapResRefToEJB.1.targetJndiName=jdbc/myActualDatasource -opt MapResRefToEJB.1.login= -opt MapResRefToEJB.1.properties= -local The output from the product template will be a <APP_NAME>.properties file in the ${SCOPE_HOME}/apps/properties directory (cleaned of most comments for this example): ================================================================== APP_NAME=MYAPP APP_FILE=MYAPP_v2.0.1.ear # Precompile JavaServer Pages files options.precompilejsps=true # maps resource references to resources options.multi.1.mapresreftoejb=["myapp" "" "MYAPP.war,WEB-INF/web.xml" "jdbc/devdatasource" "javax.sql.datasource" "jdbc/myactualdatasource" "" "" ] ================================================================== Notes about providing data to Templates When using multiples, you simply increase the Number segment for each group: -opt MapResRefToEJB.1.EJBModule=MYAPP -opt MapResRefToEJB.1.EJB= -opt MapResRefToEJB.1.URI=MYAPP.war,WEB-INF/web.xml... etc... -opt MapResRefToEJB.2.EJBModule=MYAPP -opt MapResRefToEJB.2.EJB= -opt MapResRefToEJB.2.URI=MYOTHERMODULE.war,WEB-INF/web.xml... etc Overriding the Product template with a User template Although Rational Automation Framework for WebSphere ships with some templates, the product-provided templates may either be too complex, too simple, or just need to change for your purposes. In this case, you can create your own template. These are known as user templates and are placed in ${RAFW_HOME}/user/templates/<purpose>/<product>/<version>/

12 Page 12 of 20 By creating a template with the same file name as a product template, and placing it in the same relative directory (under../user/templates/..) as the product template, the desired product action will use the user template rather than the product template. Some thoughts come to mind about why you might want to override the appname_split.vm: Your FILE_NAME for the EAR/WAR you are deploying is going to be different than the APP_NAME. You want the ability to specify a WAR file rather than an EAR file You want to include Version numbers in your FILE_NAME but not in the APP_NAME You want to pass-in the APP_FILE name into the template and reference the apps/media directory You have identified that some option values will be constant across all applications that you will be deploying, and don t need to be variable Perform An Override of appname_split.vm A. Copy ${RAFW_HOME}/product/templates/deploy/was/<version>/appName_split.vm To ${RAFW_HOME}/user/templates/deploy/was/<version>/appName_split.vm B. Edit the new user template, make the highlighted changes (as examples), leaving Dynamic encoding where desired: # Application Specific Info APP_NAME=$APP_NAME #if ($opt.app_file) APP_FILE=apps/media/${opt.APP_FILE} #else APP_FILE=${SCOPE_HOME}/apps/media/${APP_NAME}.ear #end # Removed the IF - standard is MULTIPLE # war class loader policy: SINGLE=Application, MULTIPLE=Module WAR_CLASS_LOADER_POLICY=MULTIPLE # Removed the IF - standard is PARENT_FIRST # class loader mode options: PARENT_FIRST (default), PARENT_LAST CLASS_LOADER_MODE=PARENT_FIRST # Below are application deployment options for wsadmin, consult the link in the # header of this file for a detailed description of any option. #if ($opt.precompilejsps) # Precompile JavaServer Pages files options.precompilejsps=$opt.precompilejsps #end... etc... ==============================================================

13 Page 13 of Test the user template Execute the command in Using the product template in Rational Automation Framework for WebSphere command section above, and see the values in the generated ${SCOPE_HOME}/apps/properties/<APP_NAME>.properties Note: since the rafw_model_create_was_app_deploy_file action is a model action, it runs local to the product framework server. It does not modify target cells or servers. Therefore, test your template changes as much as you want without worry of altering a live system. 11 Using Rational Build Forge to provide variable inputs into Templates So far we ve seen what files the application deployment actions expect, and how we can generate the application options file from a template. However, providing all the input data directly through the action command -opt parameters seems a bit cumbersome. Let s have a look at how that can be alleviated in Rational Build Forge, such that you can even provide a UI to input the variable values Option 1 - Declare variables in a Build Forge project or library step using Build Forge dot commands The variables we need to specify for the appname_split.vm are listed as $opt.variablename in the template. When we provided the variable value on the command, we used -opt variablename=<value> to populate. However, when sourced from the shell environment, such as the Build Forge Step Command, we only need to provide the populated variable by name in the Step Command s environment scope, and we can eliminate the -opt parameters from the action command. See the Figure 2 where the variables are declared using a Rational Build Forge.bset command:

14 Page 14 of 20 Figure 2 - Step Command Field and.bset commands While the example in Figure 2 shows static values being set, it begins to show how you can begin sourcing the data from elsewhere using tools in Rational Build Forge. Notes about declaring Build Forge variables in Step Commands: The.bset command is used to declare variables to be available to all Steps after this step (available to steps after the step declaring the variable) The.tset command is used to declare variables to be used in this step only The.set command is used to declare/set variable values in Environment Groups, for use beyond the scope of a single project execution Option 2 - Provide Variable Input fields on the Project Execute page using a Build Forge Environment Group An Environment Group in Rational Build Forge is a storage facility for variables, and can control which are required, which have defaults, and so on. A. Create an Environment Group for the variables.

15 Page 15 of 20 Figure 3 - Creating an Environment Group Notice, in Figure 3, that we can make some variables required, and can provide some default values as well. Some variables can be input fields or Pulldown Lists when provided on a Project. B. Map the new Environment Group to a Build Forge Project Figure 4 - New Project associating an Environment Group

16 Page 16 of 20 C. Add a Step to the project to execute the rafw_model_create_was_app_deploy_file action Figure 5 - Project Step for Generating Options from Environment In Figure 5, Notice that there are no -opt parameters, only the required -a ${APP_NAME} parameter. Notice also that the Target Environment is mapped to this step (lower left in Figure 5). Doing so is required to provide the variables for ${ENVIRONMENT}, ${CELL_NAME}, etc.

17 Page 17 of 20 D. Start the Project using the Start Project button Figure 6 - Start Project page with Environment Input fields Here in Figure 6, we see that the required fields APP_NAME and FILE_NAME display with red border, and Build Forge will indeed enforce that these are populated. Also we see that the other fields include default values, and Pulldown List inputs that allow us to control the input choices. The next objective in a deployment process here would be to follow up with a deployment project that contains a step to provide the deployable WAR/EAR to Rational Automation Framework for WebSphere and a step to execute the was_common_deploy_install_app action. 12 Conclusion Remaining true to form, Rational Automation Framework for WebSphere is very much a framework. There are many ways to accomplish deployment and configuration objectives with the product. This Guided Activity has explained the core options of the deployment process with Rational Automation Framework for WebSphere, and provided thoughts on how to generate deployment files and even provide a UI to be potentially granted to other users for input. 13 Appendix 13.1 Actions Discussed in this Document was_common_deploy_install_app Installs a J2EE application to a WebSphere Application Server server or cluster. This action requires an EAR or WAR file in the ${SCOPE_HOME}/apps/media directory. You must specify the a <APP_NAME> argument with the action.

18 Page 18 of 20 This action requires a Rational Automation Framework for WebSphere <APP_NAME>.properties file in the ${SCOPE_HOME}/apps/properties directory. If the application has previously been deployed, this action runs as an update in the same form as wsadmin AdminApp.install update. was_common_deploy_install_apps Installs multiple J2EE applications to the WebSphere Application Server server or cluster. For a subset of applications, Use the a <APP_NAME, APP_NAME, > argument on the action to specify a comma-separated list. Omit the a <APP_NAME> argument to install an application for each <APP_NAME>.properties file found in ${SCOPE_HOME}/apps/properties. This action requires EAR or WAR files in ${SCOPE_HOME}/apps/media. If an included application has previously been deployed, this action runs as an update in the same form as wsadmin AdminApp.install update. was_common_deploy_start_app Starts a J2EE application running on a WebSphere Application Server server or cluster. You must specify the a <APP_NAME> argument with the action. rafw_model_create_was_app_deploy_file Creates an <APP_NAME>.properties file based on a template. You must specify the a <APP_NAME> argument with the action. Uses the data sourced in the environment, or found in the opt parameters on the action to populate the <APP_NAME>.properties file. Places the <APP_NAME>.properties file in ${SCOPE_HOME}/apps/properties Additional Actions to Note was_common_deploy_export_app Exports a J2EE application from a WebSphere Application Server server or cluster into a Rational Automation Framework for WebSphere Environment Tree for a WebSphere Application Server cell definition. You must specify the a <APP_NAME> argument with the action. This action requires a Rational Automation Framework for WebSphere <APP_NAME>.properties file in the ${SCOPE_HOME}/apps/properties directory. To export an application, it must have been deployed once. was_common_deploy_stop_app Stops a J2EE application running on a WebSphere Application Server server or cluster without stopping the WebSphere Application Server server or cluster. You must specify the a <APP_NAME> argument with the action.

19 Page 19 of was_common_deploy_uninstall_app Uninstalls a J2EE application from a WebSphere Application Server server or cluster. This action does not remove the <application>.ear file from the Rational Automation Framework for WebSphere apps/media directory. You must specify the rafw a <APP_NAME> argument with the action. This action requires a Rational Automation Framework for WebSphere <APP_NAME>.properties file for the J2EE application was_common_deploy_update_app Updates a file or module within a deployed J2EE application in a WebSphere Application Server server or cluster. Use this action to add or replace modules or files in the deployed application. You must specify the a <APP_NAME> argument with the action. Requires a <APP_NAME>.properties file for the J2EE application in ${SCOPE_HOME}/apps/properties. Requires a <APP_NAME>_update.properties file declaring the updates. For full EAR version updates, or to only modify the Options of a deployed EAR, use was_common_deploy_install_app instead. Trademarks IBM, the IBM logo, WebSphere, WebSphere Application Server, Rational Build Forge and Rational Automation Framework for WebSphere are trademarks of IBM Corporation in the United States, other countries, or both. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Also, if this article uses any of the product names from other companies that require trademarks, add the appropriate information here. See Special Attributions for details. Other company, product, or service names may be trademarks or service marks of others. Resources Learn Visit the Rational software area on developerworks for technical resources and best practices for Rational Software Delivery Platform products. Share this article Digg this story Post to del.icio.us Slashdot it! Subscribe to the developerworks Rational zone newsletter. Keep up with developerworks Rational content. Every other week, you'll receive updates on the latest technical resources and best practices for the Rational Software Delivery Platform. Subscribe to the Rational Edge newsletter for articles on the concepts behind effective software development.

20 Page 20 of 20 Subscribe to the IBM developerworks newsletter, a weekly update on the best of developerworks tutorials, articles, downloads, community activities, webcasts and events. Browse the technology bookstore for books on these and other technical topics. Get products and technologies Download trial versions of IBM Rational software. Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2, Lotus, Rational, Tivoli, and WebSphere. Discuss Check out developerworks blogs and get involved in the developerworks community. About the authors Dale Ewald (dale.ewald@atech.com) is an Architect with Ascendant Technology specializing for over 6 years in WebSphere and WebSphere Portal development and infrastructure. Dale has over 15 years of IT experience and has over 10 years of consulting experience. Alden Taylor (ataylor@atech.com) has been teaming with IBM as an Architect for the Rational Automation Framework since the product s inception. Alden is a consultant with Ascendant Technology, specializing for over 7 years on WebSphere Middleware architecture, infrastructure and development.