Building the Site


A site manager should be able to connect to the manager’s pages and build the site by running the wizard. This generates all the files and database tables, including product pages, basic layout, shipping and handling, tax, and payment. Furthermore, this builds the actual store that will exist on top of the site foundation.

You should run the wizard and follow the instructions displayed on the screen. Some points of interest when building the site are as follows:

  1. A locale step defines the default locale to be used in your store. This drives the configuration of the default tax calculation component as well as the format used to display currency and other localized variables.

  2. Price promotions allow you to offer promotions, such as discounts based on dollars spent, percentage discounts, or a two-for-one promotion. Cross-sell promotions allow the site to offer a related product when a shopper selects a particular product.

  3. With a features step, you can choose if and when you want shoppers to register at your site and whether you want to maintain this shopper information in the site’s database.

  4. A product attribute type step is based on the type of products that the site intends to offer. With static attributes, all products have the same attributes.

  5. Dynamic attributes allow the site to sell products that might differ in attributes, for example, one item may be offered in multiple colors, but not list the manufacturer’s name, and another item, such as a shirt, might have varied sizes, neck size, sleeve length, and color.

  6. An order history step offers the option for the site to store a shopper’s order history and receipt information[4]. This information is useful to customers who may want to look up existing orders. In addition, it can provide a source for integrating into an existing customer service application[3].

After running the wizard, your sample site is now ready and open for shopping. Now, let’s take a look at how the wizard-generated site meets many of the stated requirements right “out of the box.” With reference to the list of requirements given earlier, the site meets the following requirements at this stage: 1, 2.b, 3, 4.a, 8, 9, and 10.

The site you have just built can be used as a prototype after implementing the initial user interface (UI). The Design stage is next.

Design

The Design stage involves coming up with the overall structure of the site. This task would be mammoth if it were not made easier by the wizard because it automatically generates the basic structure of a commerce site with features such as a shopping cart, shopper ID, order ID, and so on. To build the design for your site, you have to design it around the existing commerce site design. There are essentially three aspects to site design in a commerce server: designing the database, the order form, and an order processing pipeline (OPP). A commerce server site populates its pages with data obtained dynamically from its database. The database holds all the data related to the site—data related to the products and shoppers. The site performance and reliability is influenced by the database design.

An order form object provides storage for customer and purchase information. A commerce server site uses the order form object to store the items that a customer has placed in the basket, to store bill-to, ship-to, and receipt information.

The OPP is a collection of components that encapsulates the processing that is performed on the order form. Each component in the OPP has its own distinct function that it performs on the order form.

Because the order form is of limited scope, the design should focus on a single example of each of the different design aspects. At the end of the Design stage, you should be clear about what is to be done in the Implementation stage.

Database Design

Central to the design of the site is the design of the site database. Much of the database schema required for a commerce site is automatically generated by the wizard. However, if you already have a product database in place, and you want the commerce server site to use it, you can select a sample site whose product schema most closely matches the existing database. You can use the wizard to copy that sample site, and then modify the queries as appropriate for your database.

In the sample sites, database queries that are used to display information (such as product descriptions and properties) on the page are defined in the ASP file for that page. So, to accommodate a different product schema, one need only modify the query as needed and create a combination of HTML and scripting to display the product information on the page.

Note

For more information on ASP, see http://www.activeserverpages.com.

In the case of your sample site, the need to modify the wizard-generated database schema arises because of the following previously listed requirement: 2.a—the product catalog can have products from various vendors. This requirement introduces a new entity into the schema—the vendor or manufacturer. This leads to a new relationship between the products table and the vendor table.

When translated into physical design, the entity maps to a new table. A new table to hold vendor attributes is created. The relationship between products and a vendor is a many-to-one relationship. This maps to a new column in the products table that holds the Vendor ID.

In general, a fair bit of denormalization is recommended because it can result in significant performance gains. Database queries should be kept to a minimum to increase speed.

Order Form Values

An order form object is a commerce server dictionary object. The order form object serves as working storage for order form data being collected or processed (the shopping basket).

An order form object is defined internally as a structured group of dictionary objects, and includes the methods required to add items, clear items, and clear the entire order form itself. Commerce server sites use the order form object to store items that a shopper might have chosen to purchase, and to store receipt information that will hold a shopper’s order history. Some of the common values that the order form might hold are:

  • Shopper ID

  • Name

  • Address

  • Order cost information

  • Purchase subtotal

  • Tax

  • Shipping

  • Total[3]

Note

The order form does not directly support storage of its data on disk—instead, a database storage object (DBSO) is used to accomplish this.

Now, with the preceding in mind, let’s get back to your sample site. You will need to add a few values to the order form. This is necessitated by the following requirement that was previously listed: 5. Customer should receive e-mail confirmation of his order. This functionality will be implemented by a simple mail transfer protocol (SMTP) component in the purchase pipeline. The SMTP component will require the information shown in Table 6.1[3].

Table 6.1: SMTP component functional information and description

Function

Description

Order. email_subject

The subject for the order confirmation to be sent by e-mail to the customer

Order.email_body

The message body for the order confirmation to be sent by e-mail to the customer

Order Processing Pipeline (OPP)

The commerce server pipeline is a software infrastructure that links one or more components and runs them in sequence on the order form object. Each stage in a pipeline consists of zero or more components, and each of these components is run in sequence. A component is a Component Object Model (COM) object that is designed to perform some operation on an order form. Usually, each component has its own small task to perform. For example, a fixed shipping component checks for the right shipping method and sets the shipping cost to the appropriate value.

A business-to-consumer commerce site in commerce server uses three kinds of OPPs—the product, plan, and purchase pipelines. The product pipeline is of little interest here. The plan pipeline consists of stages, which consist of components that verify the integrity of the order form. The purchase pipeline has stages and has components that accept the final purchase of an order form, write an order to database storage and finalize a receipt, and write the contents of the order form to the receipt database.

Note

The purchase pipeline is usually run once an order form has been run successfully through the plan pipeline, and the shopper has confirmed his desire to finalize a purchase.

A commerce server should include the requisite basic pipeline components needed for a basic commerce site. When you run a wizard, it automatically creates the three OPPs required for the site—this site does not, however, feature real-time credit card validation and only includes very basic tax and shipping components. Various third-party components are available for these functions. Your sample site should use default tax and shipping components. However, you need to add a new component to handle the following previously listed requirement: 5. Customer should receive e-mail confirmation of his order.

Tip

Introducing the preceding functionality into the site means that you have to add the SMTP component to the purchase pipeline.

[4]Vacca, John R., The Essential Guide to Storage Area Networks, Prentice Hall PTR, 2001.




Electronic Commerce (Networking Serie 2003)
Electronic Commerce (Charles River Media Networking/Security)
ISBN: 1584500646
EAN: 2147483647
Year: 2004
Pages: 260
Authors: Pete Loshin

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net