Creating a New StoreNow that we understand how an online store works-and we have a better idea of what SSCE has to offer-it's time to take a look at what MSCS has to offer in terms of store creation. Let's start with seeing how the administration model for a Commerce Server host works.
Administration ToolsAs in the other parts of SSCE (and the rest of Microsoft's Internet products), MSCS can be administered either online or through the MMC; however, in this case, the web-based management tools are significantly more powerful than their MMC counterparts, to the point where the latter end up opening a browser window if certain tasks have to be carried out. Naturally, online administration has the further advantage of being easily expandable with a little ASP programming.
The next screenshot shows MMC with MSCS's snap-in open to show a list of the stores available on my own server. As you can see, the Microsoft Press sample is selected, and the two options that are available are starting to shop from the store or accessing its management interface. Both actions simply redirect the user to the store's own interface on the Web.
Right clicking on a store and selecting Properties brings up a dialogue box that displays several pieces of information regarding the store's configuration and allows the user to modify them. As we'll see in the next chapter, this data is actually stored in a file inside the store's virtual folder and can be accessed programmatically from ASP. Since it's possible to add an arbitrary number of custom properties to this file, but it is not possible to change the snap-in's interface, we have already hit a functionality limit for the MMC administration tools that doesn't apply to their online counterparts.
The online tools can be accessed through this URL:
Clicking on Server Administration causes the main administration screen-shown in the next screenshot-to be displayed. As you can see, this brings up a list of all the available stores (in a Java applet!), their status and their locations. The number of options available is quite impressive: each store can be opened or closed, shopped in, managed and reloaded. In addition, it's possible create a new store (something that we'll set out to do below), delete an existing one or edit its properties.
We have already seen the first few options as part of the management interface of each individual store, while the Properties screen presented here offers functionality that is new to us. As part of the configuration of a store, we can specify settings such as the store's base URL for in-clear and secure (HTTPS) transactions, the connection strings that should be used to open the store's database, and so on. It's interesting to notice that any changes we make to the URL configuration of the store (in-clear and secure base URLs, as well as whether HTTPS should be used at all on the site) are immediately reflected on the entire store, including all of its internal links.
Creating a Store FoundationFrom the administration tools, it is also possible to start the process that will eventually lead to the creation of a new store. For the MMC snap-in, all you need to do is right-click on a server and then select Create NewāOnline Store Foundation..., while in the online tool you just have to click on the Create... button.
In both cases, you'll end up in the first step of the Site Foundation Wizard (SFW), the first of two online step-by-step store creation tools. The goal of the SFW is to create the building block (called Store Foundation) of an online store on which it will be possible to actually build the site.
Wizards have become a widely used tool, mainly because of their ability to break down a problem into smaller, more manageable issues that can be solved by asking a series of questions of the user. Since creating a store is, indeed, a complex process that involves a number of decisions, the use of a wizard simplifies matters through its step-by-step approach.
It's important to remember that, because the SFW is an online tool based on Session objects, you will have to proceed through it at a certain speed in order to prevent your session from expiring; this usually happens after twenty minutes of inactivity. If you attempt to continue through the steps of an instance of the wizard after the session has expired, you will be redirected to the administration tool's home page and you'll lose all the information entered up to that point.
Step 1: Selecting a Web Server
The first task in the SFW, shown in the adjacent screenshot, consists of selecting an instance of IIS on which the store will be installed. All you have to do is select one from the list that is provided by the wizard and proceed. By default, the store will be installed in a virtual folder in the IIS server that you select-this is the only way for MSCS to be aware of the store's existence; in addition, the store itself has been designed to work in this configuration.
Making a Store Work Inside the Root Folder
If you want your store to be launched in the root folder of a website, the quickest way to do so is to just write a simple script that redirects the user to the site's virtual directory and store it in the site's root as default.asp. For example, this code can be used to redirect users to MSMarket when they enter the server's main site:
Step 2: Giving Your Store a Name
The next step in the SFW (following screenshot) consists of assigning a name to our store foundation. To be accurate, there are two names that have to be assigned: the Short Name and the Display Name.
While the Display Name is used, as the name suggests, only for display purposes, and therefore doesn't have to be unique across the system, the Short Name represents the individual instance of MSCS within the computer on which the store foundation is going to be created. As such, it will be used for a variety of purposes: the virtual folder in which the store will reside will be named after it, all the database tables used by the store will have it as a prefix, and so on. The short name is essential because it makes is possible for more than one store to reside in the same IIS instance and for their database tables to be stored inside the same database.
There is a 12-character limit for the Short Name, but you'll usually want to impose a shorter 3-character boundary for most practical uses. In particular, this will ensure that you will not have any trouble in creating database structures with meaningful names later on (as all objects in SQL Server are limited to a maximum of 20 characters, without spaces, for names). In order to allow you to save the data for more than one store in the same database, MSCS will prefix all the tables that belong to one of its instances with its Short Name (i.e. MT_Product).
To help you choose a name that is not already in use, the wizard provides a list of Short Names that have already been used. Unfortunately, the Java applet that displays the Reserved Names list-and the list itself sometimes-seems to be very fragile and will occasionally refuse to work. When that happens, you will have four options. First, try to guess a name that hasn't been used already. Second, you can try to refresh the page. If that doesn't work, try the "three-finger salute" (Ctrl + Alt + Delete, also known as system reboot). Finally-and, believe me, you can actually get to this-when everything else fails, you can always try to reinstall SSCE3.
Step 3: Specifying a Physical Location
At this point, the wizard needs to know where we want the store files to be physically located. By default, the system recommends the creation of a new folder where the root directory of the IIS instance used by the store resides. As you can see from the screenshot following, the default directory is named after the Short Name that we decided in the previous step.
Once you have created the store foundation, you can change its physical location at will. However, you will also have to change the IIS settings accordingly, and also modify the store properties either through the MMC or the online administration tool.
Step 4: Choosing a Data Source
As we have mentioned many times since the beginning of this section of the book, a database is at the core of an online store. The fourth step of the SFW (shown in the next screenshot) lets us choose the data source that should be used by our future store when connecting to its database. We are also asked to specify a username and a password for accessing it-the username is required even if the database is not protected (as it is often the case with an Access file).
Even though we won't be looking at the database structure of a store created by MSCS until later on, let's think briefly about what criteria you should use to choose a database system for your store. Microsoft Access is an inexpensive solution, but unfortunately it does not work well in a production environment-especially if you are expecting to have a lot of traffic through your store. You could, in principle, use it in your prototypes, and avoid the hassles of having to set up an enterprise-level system like SQL (not to mention having to buy another copy of the software). Sadly, the dialect of SQL used by Access differs enough from the one spoken by SQL Server to cause a lot of headaches when you move to a live production environment.
As a result, you should be leaning towards an enterprise-level database system. MSCS supports both Oracle and SQL Server 6.5, so the system that you will choose depends very much on what you are currently using; however, if you're just starting up and need to buy database software anyway, I recommend going with SQL Server, if not for anything else, just for the fact that you can be reasonably sure that future versions of MSCS will support it. In addition, the present version (at the time of writing) of the Site Server installation program does not support creating a Membership directory on Oracle.
You should also think carefully about the login information that you use for the store database. In my example here I chose to use sa, the system administrator alias for SQL Server. This is a reasonable decision when developing a store, because it gives us more freedom and lets us concentrate on the real problems rather than on why we can't execute a certain query. In a production environment, however, this corresponds to an invitation to being hacked; therefore I recommend that you change the login data to that of an account that only has the amount of permissions that is strictly necessary to the correct functioning of the store. You'll probably want to ease the restrictions for the management interface, which should use a different account to access the database.
Steps 5, 6 and 7: Selecting an Administration Account
The next three steps are dedicated to letting us choose an NT account that will be used to access the store's management interface. It's worth noting, at this point, that by default there is no integration between MSCS and P&M; as a result, any authentication needs are left in the hands of NT Security.
As you can see from the three screenshots that follow, the only reason why there are three steps for accomplishing this relatively simple task is that the SFW has to progressively discover where the login information should be taken from. To all you Internet Explorer 5.0 users out there, this must look like a serious lack of functionality-just keep in mind that SSCE was published way before IE5!
Once again, you should use particular caution when you choose the admin account login. For a prototype, using Administrator makes it possible to avoid any permission problems-as using sa did before-but you will have to settle for something different when you go live with your store, especially if you need to turn on basic-text authentication in order to support non-Microsoft browsers, which will cause passwords to be sent in clear text to the server. A good solution in this case is to manually create a group and grant it access to the management interface's scripts. You can then add individual users to the group (maybe with certain additional safety features, like the need to change their password every two weeks) and deny them access to everything else.
Steps 8 and 9: Creating the Store Foundation
Finally, the last two steps of the SFW take care of actually creating the store foundation. As you can see from the following screenshots, the wizard first asks us for permission to proceed with the creation process, then, when this is complete, provides us with a final page that also contains a link to the store's management pages.
What Has Been Done?
If you try to follow that link, you will find out that the management interface for the newly created store foundation does not actually contain any information, but just a link to the Site Builder Wizard, which we'll discuss in the next section.
If you look at the directory structure that has been created by the wizard, shown in this screenshot, you will notice that there are only a handful of files, aimed at providing just the basic functionality needed to display a simple "under construction" page. The Manager folder, too, only contains a bunch of files-very different from what we have seen so far.
What did the SFW really do, then? The answer is in understanding what a store foundation really is-the building block for creating a store. It includes all the structures that are needed by MSCS to be aware that the store exists and to manage its fundamental aspects (i.e. opening/closing, changing the base URLs, and so on), and a basic set of scripts that is intended to offer a possible structure for the store.
This is all that there is to it. As you can see, a store foundation is extremely simple, and at the same time is a powerful starting point for your store, because it provides you with a well thought out structure and many of the global parameters that you will need (which you'll find in the global.asa file). Even though you could use it to start your own project from scratch, you will find that using the Site Builder Wizard makes things a lot easier and significantly cuts down development time (and bugs).