|
|
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:
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:
Figure 1-1 Click the EJB or Web Application That You Added
The right pane of the Administration Console displays the module deployment properties. 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:
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:
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|