Implementation

The Implementation stage is where the design is translated into actual changes to the prototype. This stage includes UI changes depending upon feedback from the customer, custom development of components (if any), changes to the database schema, and changes to the ASP files. However, this part of the chapter does not deal with UI implementation or custom components. At the end of implementation, therefore, you should have a working commerce site that satisfies all listed requirements.

The Implementation stage involves modifying the wizard-generated ASP files. Most developers are comfortable using a text editor such as Notepad to manually edit the files. The ASP files are like HTML files with added functionality; they are responsible for the look of the site and the UI in general.

Database Implementation

Database implementation deals with making changes to the wizard-generated database to make it conform to the database schema. These changes usually cascade into changes to the appropriate ASP files as well. In the case of your sample site, it would require adding a new table called Vendors that holds the attributes of the Vendor, such as ID, name, address, phone, fax, e-mail address, home page address, and so forth.

To relate products with their vendors, you need to define a many-to-one relationship that translates into an additional column in the product table that holds the ID of the vendor. Both these changes require updates to the ASP files.

Note

In general, any change made to the database schema results in a number of changes to the associated ASP files.

Editing the Pipeline

Previously listed requirements 5 and 6 can be met by introducing the SMTP component in the purchase pipeline. Adding the SMTP component requires that you also add a scriptor component just before the SMTP component.

Securing the Site

Going back to the previously listed requirements, you still have the following requirement to be met: 4.2 Credit card information should be securely transferred. This means the ASP file that receives the credit card information, entered by the shopper through a form post, should be secured by a Secure Sockets Layer (SSL).

Commerce server-based sites usually use SSL to encrypt transactions passed over a secure port. By default, however, secure HTTP used over SSL Hyper Text Transfer Protocol Secure sockets (HTTPS) is disabled in sites created with a wizard. A commerce server does this to enable developers to create and test these sites without causing an error even on a server in which a server certificate is not installed.

Note

To enable SSL, you must install a valid server certificate. For further details about obtaining a certificate for your server, see http://www.verisign.com.

Database Access

You still have one more previously listed requirement that needs to be met: 7. Any order that is yet to be shipped can be cancelled by the customer. To implement this, you have to go back to the ASPs again. In the wizard-generated site, the status of the order is maintained in a separate field in the receipt table. The site does not, however, maintain status automatically. To do this, the ASPs, which display order data in the manager’s pages, will have to be modified to allow the manager to set the status of the order.

After you have taken care of maintaining your order status, you will now have to display this information to the customer. Here, when you display the order status, you can perform a check to see if it has been shipped. If it has not been shipped yet, the customer can be presented with an option to cancel the order. If the customer chooses this option, the status of the order should be set to indicate the cancelled status.

Note

The site manager and shopper pages use different logins to access the database. If the shopper should be able to cancel the order, then a sample site visitor account should have appropriate permission.

Tip

It usually helps to have an additional stage before being “shipped,” which indicates the status when the order has almost been shipped. This helps avoid losses that may arise when a customer cancels an order that is about to be shipped.

With the preceding in mind, your little sample site is now ready and is fully functional (see Figure 6.1), except for payment verification^[2]. The site should be subjected to testing before deployment.

Figure 6.1: A sample commerce server site after customization.

Security

Site security is very crucial in a commerce site. Exaggerated reports of credit card fraud on the Internet has led to people being highly apprehensive of shopping on the Internet. However, this initial mental barrier is now being overcome as more people take to shopping on the Net.

Site security is definitely one of the most important factors, if not the most, that the site designer will have to spend time on at all stages. The most basic security requirement is that customers of a commerce server site need assurance that confidential information such as passwords and credit card numbers are protected from unwanted access. To achieve this, a commerce server should support the industry-standard SSL.

SSL and HTTPS

Security of credit card information is the primary concern for the customer. By default, commerce server sites do not store credit card information used in an online transaction. Security of credit card information over the Internet is implemented using SSL.

In a nutshell, SSL is a method of data encryption that is used to secure transactions between the client and the server. The client and server share an encrypted session key that is generated by the client software. This key is transferred to the server using the server’s public key. Using the server’s public key to encrypt the session key ensures that only the private key of this pair will be able to decrypt the session key.

To receive a page that is secured by SSL, the browser sends a request using the HTTPS (S for Secure) protocol. In HTTPS, the URL for the restricted Web site starts with https:// instead of the normal http://.

Site Managers

For every commerce server site, a group is created that permits access to the site’s manager pages. The users in this group are the operators of that particular commerce server site. This group permits access to the site’s manager pages, along with Read/Write access to all of the site’s files. An operator of one commerce server site does not have this type of access to any other commerce server site.

Configuring the Network Against External Intrusions

Guarding the site from external intrusions is also critical. However, this can be accomplished rather cost-effectively through a standard firewall-safe network configuration.

In such a configuration, the network is guarded by a firewall (or proxy server) that allows certain “Demilitarized Zones” (DMZs), as shown in Figure 6.2^[3]. These DMZs are the areas of the internal network that may be accessed by external (or Internet) users. The firewall would be configured to allow HTTP access to the commerce server on the local area network (LAN). The database server, however, will not be publicly accessible. All database access from the commerce server machine would have to go through the firewall, as the commerce server will not be connected to the data. For critical purposes, having the same machine as a commerce server and the database server is not recommended.

Figure 6.2: External intrusions network configuration.

^[2]Copyright 2001, Eden-2000, SexyShoesandBoots.com, Eden-2000 Web Designs, MerchantWebsiteDesign.com, 2003.