BEA Logo BEA WLCS Release 3.5

  BEA Home  |  Events  |  Solutions  |  Partners  |  Products  |  Services  |  Download  |  Developer Center  |  WebSUPPORT

 

   WLCS Documentation   |   Deployment Guide   |   Previous Topic   |   Next Topic   |   Contents   |   Index

Deploying Your Enterprise Application

 

Any Web site that uses Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server must be deployed as a web application or enterprise application that is part of a WebLogic Server domain.

This topic assumes that you are using the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server reference domain and enterprise application as a starting point for managing and developing your own enterprise application. It includes the following sections:

Before you continue, we recommend that you read the following:

 


Getting Started in a Development Environment

When you install Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server in your development environment, it is configured to activate the reference enterprise application and use the Cloudscape demonstration database that is populated with sample data. This default configuration is appropriate for demonstration purposes only.

Before your organization begins to develop its own enterprise application, complete the following deployment tasks in your development environment:

  1. Place files under source control. For more information, refer to Place Files Under Source Control In addition, review Tips for Developing Your Web Application.

  2. Set up the database that you plan to use in your production environment.

  3. Start the server, as described in Starting and Shutting Down the Server.

  4. As you near the end of the development cycle, tune the wlcsServer performance for a testing or production environment. For information on Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server performance tuning, refer to the Performance Tuning Guide.

Any time during the development cycle, you can set up optional services for Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server:

In addition, you can modify the flow of the order process to fit your business process. For more information, refer to "Tailoring Order Status to Your Business" under "Using the Order and Payment Management Pages" in the Guide to Managing Purchases and Processing Orders.

Place Files Under Source Control

Assuming that you develop an enterprise application based on the wlcsDomain, most of the files that developers modify while creating an enterprise application are located in two directory trees:

We recommend that you place both of these directory trees under source control in addition to the following WebLogic Commerce Server, WebLogic Personalization Server, and Campaign Manager for WebLogic properties files:

When you start WebLogic Commerce Server, WebLogic Personalization Server, and Campaign Manager for WebLogic, it must have write access to the following directories:

To make modifications to a domain from the Administration Console, the corresponding config.xml file must be writable. For more information, refer to The Reference Domain.

The Admin Tool web application writes its modifications to the WebLogic Commerce Server, WebLogic Personalization Server, and Campaign Manager for WebLogic database and does not write to any files in the domain.

Developing an enterprise application also modifies the following files and data structures:

For guidelines on placing these files and data structures under source control, refer to the third-party vendor.

Tips for Developing Your Web Application

As you develop your own web applications, review the following reminders and suggestions:

Using Webflow and the Flow Manager Servlet

If you use Webflow within your web application, you must register and provide URL mappings for the Flow Manager servlet. Webflow is a feature that controls the sequence of JSP files and the flow of data through input processors and Pipeline Components. It is dependent upon the Flow Manager servlet.

For more information about Webflow, refer to Managing Presentation and Business Logic: Using Webflow and Pipeline. For more information about the Flow Manager, refer to "Flow Manager" under "Foundation Classes and Utilities" in the Guide to Building Personalized Applications.

Listing 1-1 shows properties in an application's deployment descriptor (web.xml file) that register and provide URL mappings for the Flow Manager servlet. By default, the deployment descriptor for the sample e-commerce application includes these properties. If you use this deployment descriptor as a starting point for your own web application, you do not need to modify the properties that correspond to Listing 1-1. For more information, refer to About the e-Commerce Deployment Descriptor.

If you employ the Portal Framework, you cannot use Webflow to control the sequence of JSPs. For more information, refer to "Using Webflow Within a Portal" under "Advanced Portal Topics" in the Guide to Creating Portals and Portlets.

Listing 1-1 Flow Manager Properties in a Deployment Descriptor

<!-- Registers the flowManager servlet -->
<servlet>
<servlet-name>flowManager</servlet-name>
<servlet-class>com.beasys.commerce.foundation.flow.FlowManager</servlet-class>
</servlet>
<!-- Map all requests with the pattern "/application/*" to the FlowManager servlet -->
<servlet-mapping>
<servlet-name>flowManager</servlet-name>
<url-pattern>/application/*</url-pattern>
</servlet-mapping>

Providing Unique Names for Elements in the Webflow

When working with Webflow, make sure that you provide unique names for links and buttons on JSP, input processors, and Pipelines. If you use the same name for two different elements, you will experience unwanted results. For more information, refer to "Using Webflow" under "Customizing Webflow and Pipelines" in Managing Presentation and Business Logic: Using Webflow and Pipeline.

Working With Events

If you use the Behavior Tracking and Events Service to track and respond to user actions, note that a user must be logged in (authenticated) before an event can be detected. Make sure that your modifications to the user registration and authentication features function properly before you modify and test features that rely on the Events Service, such as discounts, placeholders, and e-mail actions.

For more information, refer to "login.jsp Template" under "Customer Registration and Login Services" in the Guide to Registering Customers and the Guide to Event and Behavior Tracking.

Working with the Default Customer Profile

The the sample e-commerce web application provides a default customer profile and a CustomerProfileIP input processor to validate the customer registration form.

The form fields from the sample login.jsp refer to this customer profile as part of the authentication process. If you use these default form fields, you must make sure that your customers create profiles that are valid per the CustomerProfileIP. For more information, refer to "Customer Registration and Login Services" in the Guide to Registering Customers.

If you modify the customer profile and the CustomerProfileIP, you must make corresponding modifications to the CommitOrderPC Pipeline component, which validates customer profile information during the checkout process. Instead of modifying CommitOrderPC, you can write a new Pipeline component. For more information, refer to "CommitOrderPC" under "Order Summary and Confirmation Services" in the Guide to Order Processing.

 


Deploying Your EJBs or Web Applications

In the J2EE specification, EJBs and web applications are types of modules that you can add to an enterprise application. The process for deploying a J2EE module on WebLogic Server is similar for all module types.

If you develop EJBs to extend Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server, or if you develop your own web application, do the following to add them to your enterprise application:

  1. Copy the module into the following directory: WL_COMMERCE_HOME/config/wlcsDomain/applications/wlscApp

  2. Edit the WL_COMMERCE_HOME/config/wlcsDomain/applications/wlscApp/META-INF/application.xml file, and place a reference to the new module there. For information about creating references to modules, refer to Module Elements.

  3. If the server is running, restart it.

  4. Start the WebLogic Administration Console for your domain. For more information, refer to Starting the Administration Console for the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server Domain.

  5. In the Administration Console, in the left pane, click Deployments —> Applications —> wlcsApp.

  6. Under wlcsApp, click the EJB or web application that you added to application.xml. (See Figure 1-1.)

    Figure 1-1 Click the EJB or Web Application That You Added


     

    The right pane of the Administration Console displays the module deployment properties.

  7. In the right pane, click the Targets tab. Then click the Servers subtab.

  8. On the Servers tab, move wlcsServer from the Available list to the Chosen list. (See Figure 1-2.)

  9. Click Apply.

    Figure 1-2 Deploy the Module on wlcsServer


     

 


Deploying in a Production Environment

When you are ready to make your enterprise application available in a production environment, do the following:

  1. Install Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server in the production environment.

  2. Set up your database in the production environment. For information on exporting Oracle data objects from a development environment to a production environment, refer to Migrating Oracle Data Objects.

  3. Update Properties Files for Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server.

  4. Update wlcsDomain.

Note: For information on deploying your enterprise application on Managed Servers in a cluster, refer to Starting WebLogic Server with Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server Classes. If you need to make further performance tuning adjustments in the production environment, refer to the Performance Tuning Guide.

Update Properties Files for Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server

As part of developing your enterprise application, developers may modify the following files, which help to control the presentation and business processing logic in the e-commerce web application:

In addition, you or another administrator may have made modifications to the WL_COMMERCE_HOME/weblogiccommerce.properties file in the development environment that you want to make available in the production environment. For example, the weblogiccommerce.properties file determines which database Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server uses.

Copy all three files into the WL_COMMERCE_HOME directory of the production environment.

Update wlcsDomain

To make your enterprise application available to the wlcsDomain in the production environment, replace the WL_COMMERCE_HOME/config/wlcsDomain/applications/wlcsApp directory tree in the production environment with the wlcsApp directory tree that your developers modified in the development environment.

Then start the server in the production environment.

You can also use the Java jar command to compress the enterprise application directory tree into a single Enterprise Application Archive (EAR) file. Deploying a single file on your production server can facilitate Web site administration by reducing the number of files you must keep track of.

To modify anything inside the EAR file, you must uncompress the file, make your modifications, and then re-compress the file.

Instead of compressing the entire enterprise application, you can also use the Java jar command to compress your web applications into Web Application Archive (WAR) files. If you use WAR files, you must update the enterprise application's application.xml file to refer to the web application as a WAR file instead of as an expanded directory.

Deploying RULESET Table Data via a Test Environment

When you add data that may affect the behavior of the application, in particular, data that is contained in the RULESET tables, it is advisable to first deploy the new data in a testing environment. For this purpose, the application provides two utility files that help you move information from a testing server to a production server.

To use these utitlities, set up your test environment as your default deployment environment. For the procedure, see Deploying in a Production Environment. Once you have deployed your new data to this testing environment, use the Dumprules35 and Loadrule utilties to deploy the new rules from the testing environment to a production environment.

Note: WLCS Server must be up and running for each utility.

Write the Rule Set Information to a Flat File for Transfer

When you have synchronized your data to the new testing environment and are ready to go live, run dumprules35 to take the new rules out of the test database and convert them into a flat file.

To dump all WLCS3.5 rule sets defined in the current database run the dumprules35 (.bat or .sh) script from the <WL_COMMERCE_HOME>/bin/<OS> directory.

The dumprules35 script takes an input parameter of the <output directory> which specifies the OS destination directory to output the rule set data to. One OS file is created for each rule set stored in the database.

For example, if the RULESET table's NAME column defines a rule set named: default/GlobalClassifications, a directory named "default" is created, and the XML definition of the rule set (as stored in the DOCUMENT column of the RULESET table) is written to a file named: "GlobalClassifications.ruleset" in the default.

Write the Flat Files to a Production Database

Once the flat file has been created using the dumprules35 utility, use the loadrules utility to write the flat file to the production database, putting them on the live production server.

The loadrules (.bat or .sh) script, located in the <WL_COMMERCE_HOME>/bin/<OS> directory, executes LoaderDriver.class to insert or update rows in the RULESET database table based on the specifications in the LoaderDriverProperties.xml file.

Results of the load are written to the LoadResults.xml file. The LoaderDriverProperties.xml file can be modified or customized in order to utilize it to populate a production or staging database with new or modified ruleset definitions. Alternatively, utilities provided by the database vendor or SQL statements (depending on the database configuration) may be used to load rules into the database.

The default <WL_COMMERCE_HOME>/bin/<OS>/LoaderDriverProperties.xml file loads seven test/sample rule sets into the RULESET database table.

The NAME of the RULESET and the OS file containing the XML definition of the RULESET are inserted into the RULESET tables NAME and DOCUMENT columns as defined in the LoaderDriverProperties.xml file.

Usage for the LoaderDriver.class is as follows:

            "Usage : java com.beasys.commerce.axiom.reasoning.rules.util.LoaderDriver
"<bindingsFileName.xml> " +
"<propertiesFileName.xml>"
"<resultsFileName.xml>";

Where:

bindingsFileName: The name of the file which contains the xml-tags to java-class-name mappings

propertiesFileName: The name of the file which contains the loader properties

resultsFileName: Name of file to which results should be written

 


Dynamic Deployment

Dynamic deployment is modifying or adding a managed object without restarting the server. You can modify any existing JSP, HTML, image file in an active domain and Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server will deploy the modification per the intervals that you have established in the domain and web application properties.

For example, you set the JSP page-check interval for the e-commerce web application to 5 minutes. A developer added an ad banner to a catalog JSP, wlcsApp/wlcs/catalog/browse.jsp, and requests that you update the JSP in production environment. You then copy the modified browse.jsp into the wlcsApp/wlcs/catalog directory in the production environment. Depending on when WebLogic Server last checked for modified JSPs, it could take up to 5 minutes for WebLogic Server to display the modified JSP.

Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server does not dynamically deploy modifications of the following types of files:

 

back to top previous page next page