Launching StoreFront E-Commerce Web Sites

Last month, I introduced you to LaGarde's StoreFront 2000, a set of add-ons for Microsoft FrontPage 2000, and discussed the features and basics of implementing a StoreFront Web store. In this issue, I go over the process that I've developed to bring up StoreFront Web stores for use with Microsoft Access databases quickly and efficiently. I don't discuss setting up StoreFront with Microsoft SQL Server or Oracle databases because those installations require additional licensing, involving the DBA, and possibly involving an Active Server Pages (ASP) programmer.

As I said last month, not everyone can afford a flagship e-commerce solution such as Microsoft Site Server, and a big e-commerce solution isn't always the right answer for a company just getting started on the Web. Several of my customers already have merchant accounts complete with payment processors that they're used to working with. They also have accounting software and other business-management processes in place. A business shouldn't have to fit an e-commerce solution: The e-commerce solution should fit the business. In addition, most businesses want to be able to manage their product database and see their order reports themselves without having to rely on a computer professional. StoreFront can make this independence possible.

Developing StoreFront Web Stores
I installed the StoreFront 2000 software on both the Web author's workstation, which was running Windows 98 Second Edition (Win98SE), and the production Web server, which was running Windows NT with Service Pack 5 (SP5), Microsoft Windows NT 4.0 Option Pack, IIS 4.0, Microsoft SMTP Server, and Microsoft Certificate Server. Both the workstation and the server had Microsoft Office 2000 Professional, so they already had FrontPage 2000 and Access (without additional licensing fees). StoreFront installs on top of FrontPage 2000, and installation is easy. (Be sure to back up your system before you make changes, install software, or otherwise change the registry and metabase.)

I don't recommend developing any Web application on a production server. The content author should develop the StoreFront Web store, the ASP, and the product database on the workstation. (The personal Web server that ships with FrontPage 2000 supports ASP, so the store works well on the Web author's machine.)

Prepare the Production Server
In preparation for the launch of the new Web store on the production server, you need to prepare the production Web site, the database, and the site and database security. The user guide that ships with StoreFront is good, and you can also find Help, step-by-step instructions, and a series of documents that describe the setup tasks on the server online at http://www.storefront.net/software/support/serveradmin.htm. Here's a list of tasks that matches my experience (it's somewhat different from the list you'll find on the StoreFront Web site):

1. Install StoreFront 2000 and the United Parcel Service (UPS) Shipping component (an optional but desirable shipping cost calculator that LaGarde provides).
2. From the Microsoft Management Console (MMC) Internet Information Server snap-in, create the Web site.
3. On the Home Directory tab of the Web site's Properties dialog box, select the Script option under Permissions, as Figure 1 shows.
4. Next, while you're still in the Internet Information Server snap-in, configure the FrontPage Server Extensions on the Web site by right-clicking the Web site, selecting Task, then selecting the option to configure the FrontPage Server Extensions. Follow the wizard.
5. Create Windows 2000 or NT accounts for the author, store administrator, and any other store personnel who will need edit or browsing authority on the StoreFront administrative tools.
6. Open FrontPage on a workstation or the server, and launch the StoreFront Import Wizard. Point the wizard at the Web site; it will create all the files and the storefront.mdb database for the store. The Web author will overwrite these files later when you publish the Web store, but for now, you need them so you can perform the remaining setup steps.
7. Before you leave FrontPage, give the Web author permissions to author on the Web site. (This step assumes that you're logged on to the Web site in FrontPage with an ID that has permissions to administer the FrontPage Web in FrontPage.) To set these permissions, select Security, Permissions from the FrontPage Tools menu, then click the Users tab and add your Web author and the store administrator. Give them Browse and Author permissions.
8. Create a virtual Microsoft Data Access Components (MDAC) directory under the new Web site to handle remote data access for the StoreFront tools. (See Related Reading, page 10, for MDAC resources.) Creating a virtual MDAC directory for each StoreFront Web store and locking it down to only the Web store author and administrator adds a layer of security over the Web store internals and its database. As part of this process, you must set the security on the MDAC directory to require NT Challenge/Response authentication, Windows Integrated authentication, or Basic authentication. (I show you how the security works shortly.)
9. Set up a Data Source Name (DSN) for the StoreFront database.
10. Set up the database connection from the Web store to the DSN by opening the Web site through FrontPage and selecting the StoreFront Administration tool. On the StoreFront Database Connection dialog box, which Figure 2, page 10, shows, set up the database connection by supplying the Web site URL and the DSN. (The URL and name will be a connection to a DSN that resides locally on the production server, so you don't need to select the Use Remote Database Connection check box.)

Publish the Web Store to Production
When you've tested the Web store, approved it in its development environment, and prepared the production site, you can publish the new e-store to the production site. If the store uses an Access database (as this example does), you can publish the database to the production Web site along with the rest of the Web content and overwrite what was already there.

After publication, you need to recheck the connections from the StoreFront application to the database and the application paths in the StoreFront Administration tool. (FrontPage can change these settings to point to the developer's workstation.) To check connections, open the production Web site in FrontPage and follow these steps:

1. From the StoreFront menu, select StoreFront Administration to open the Database Connection dialog box, which Figure 2 shows.
2. Enter the Host and DSN for the production Web site. (Use the Internet domain name in the Host field, not a machine name).
3. If you're running FrontPage from a remote client, select the Use Remote Database Connection check box, and click OK.
4. When the connection to the database opens, the StoreFront Administration dialog box, which Figure 3 shows, will open. Make sure the Web Path Information for the search.asp, addproduct.asp, and process_order .asp paths is correct for your production Web site.
5. Adjust any other settings that either you can't set up from some workstations or that will now point to different locations, such as the Mail Setup.

How Remote Database Security Works
The StoreFront Database Connection dialog box appears every time you use one of the StoreFront client tools in FrontPage. From this dialog box, you manage the connection between the StoreFront tools and the database.

Before the Web store is published, the Web author uses the local Access database file storefront.mdb, which he or she will set to the local DSN on the local server. When the site is published to the production server and has gone live, the Web author and store administrator use the Remote Database Connection feature to access the DSN on the production server through the StoreFront tools. In this way, they can administer the site and maintain the product database.

When an author logs on to the database remotely, the MDAC handles the connection to the database after that author has provided satisfactory security credentials to IIS. If the author is using FrontPage and has already provided credentials to open the Web site, FrontPage automatically supplies those credentials to IIS. This FrontPage feature is a nice time-saver, but it leaves you with the impression that the database isn't secure.

To test the security of your MDAC virtual directory, open the remote FrontPage client and click StoreFront Administration (don't open the Web site). The StoreFront Database Connection dialog box will appear. Make sure the Use Remote Database Connection check box is selected, then enter the Host and DSN you want to test. Click OK. If you didn't enter your username and password in this dialog box, the system will prompt you for them. Now you know that the database is secured against remote access by unauthorized users.

Test, Test, Test
Before your store goes live, I encourage you to test it thoroughly. Here's a checklist to help you cover all the bases:

• Make sure the store is running correctly in the new environment.
• Verify that the Web author has generated the product pages correctly.
• Verify that the search page and search results pages are functioning.
• Make sure the order cart and fulfillment sections let you place an order.
• Verify that the email order and confirmation are being sent.
• Test the reports; verify that all your test orders are present and accounted for.
• Make sure all the reports generate and print.

When you're satisfied that the store is functioning properly, test your Secure Sockets Layer (SSL) connections for store administration. If you're performing a quick installation that doesn't send information through a payment processor, you need to set up only SSL and a certificate to receive the transactions and secure the store administration. (See Brett Hill, IIS Informant, June 2000, for a tutorial about setting up a certificate.)

Finally, test the store's connection to the payment-processing company (if it has one). A discussion of payment processor installation is beyond the scope of this article. Each payment processor is different and requires different installation, authentication, licensing, and so on. Test primarily to make sure you've correctly installed and configured the payment-processing service on the server.

Take Care of the Database
When the store is running, the production database becomes the main database because it contains all the store's products and customer records. You certainly don't want anyone to overwrite this database by accidentally publishing the fledgling StoreFront database from the development machine over it. Best practice is to back up the entire Web store site to a functioning shadow Web site before anyone publishes Web pages or updates the database. Be prepared to fall back to your backup quickly if it's necessary. If you can't coordinate this approach, then perform backups as often as possible.

In addition, when the store is live, the store administrator (this administrator can be the Web author or an employee of the store owner) can make changes to the product database, orders, reports, and customers through the StoreFront Tools in the FrontPage client. The administrator can also use the HTML-based store administration tools that are installed in the \admin directory of the Web store when you install StoreFront.

To test new pages and page updates after the store goes live, the Web author must either set up a remote connection from his or her workstation to the production database or make a physical copy of the database to the workstation. I don't recommend the second option because it creates change-management problems; also, it's feasible only with Access, not with SQL Server.

Tip: StoreFront installation doesn't always install crpaig32.dll, a Crystal Reports DLL necessary for report generation. You can find the file in the StoreFront_temp_ directory and copy it to C:\winnt\system32. An FAQ on this DLL is at http://www.storefront.net/software/support/kbase.asp.

Tip: In Step 9, make sure the StoreFront database DSN has a different name from the DSN the Web author used on the development machine (e.g., tackshackprod, contrasted with the Web author's DSN tackshackdev). This distinction will save a lot of confusion when the store goes live and the author needs to be sure that he or she is working with the production database.

Tip: You must perform Step 3 on the personal Web server running on the Web author's workstation. Otherwise, the server won't process the ASP pages.

Related Reading

Steps 8 and 9 require knowledge of Microsoft Data Access Components (MDAC). These steps are described in detail at http://www.storefront.net/software/support/server_datacon.htm. You can find additional information about MDAC at http://www.microsoft.com/data.