2 - The Adventure Works Scenario

On this page:	Download:
How a Customer Uses the Shopping Application | Browsing Products | Logging in and Registering with the Shopping Application | Adding Items to the Shopping Cart | Placing an Order | Viewing Order History | How the Shopping Application Stores Information | The Architecture of the Shopping Application | Summary | More Information

Adventure Works is a multinational manufacturing company that builds and sells metal and composite bicycles and associated products to the North American, European, and Asian commercial markets. The company is based in Bothell, Washington, with 290 employees and several regional sales teams located in various countries throughout their market base. To support these distributed sales teams, and also to enable customers to purchase items directly, Adventure Works developed an online Shopping application that allows users to browse the products that Adventure Works manufactures and place orders for these products.

This chapter describes the business requirements of the Adventure Works Shopping application, and summarizes the architecture of their solution.

How a Customer Uses the Shopping Application

The purpose of the Adventure Works Shopping application is to enable customers to view the items that the company has for sale, place orders for these items, and pay for them. The customer's experience is paramount, so the designers at Adventure Works chose to implement the system as an easy to use, forms-based web application. The Shopping application implements the features typical of many modern online commerce systems. It enables customers to browse products, add products to a shopping cart, and then place an order for these items. Customers can also view a list of all orders that they have placed.

When a customer has ordered and paid for the goods, they are picked from the Adventure Works warehouse, packaged, and dispatched. This part of the process is outside of the scope of the Shopping application and is handled by other systems internally inside Adventure Works.

The following sections describe the primary business use cases of the Shopping application in more detail.

Browsing Products

The products that Adventure Works sells are grouped into categories (Accessories, Bikes, Clothing, and Components), and each category is divided into a set of subcategories. For example, the Accessories category contains subcategories for Bike Racks, Bike Stands, Bottles and Cages, Lights, Locks, Helmets, and so on. Each subcategory contains one or more products. No products are held in more than one subcategory. The result is a tree-structured hierarchical relationship between categories, subcategories, and products. The Shopping application exploits this relationship to provide easy navigation of products.

When the user starts the application it displays a list of categories as shown by the screenshot in Figure 1.

Figure 1 - The categories displayed when the Shopping application starts

A customer can click a category to display the subcategories for that category, and then click a subcategory to browse the products in that subcategory. Figure 2 shows the result when the user clicks the Bikes category and then clicks the Road Bikes subcategory.

Figure 2 - The subcategories in the Road Bikes category

Clicking a product displays the details for that product. Figure 3 shows the information displayed for the Road-150 Red, 62 bicycle. The application also retrieves and displays information about related products that may be of interest to the customer, based on purchases made by other customers who also bought this bike:

Figure 3 - The details displayed for a product

Logging in and Registering with the Shopping Application

The application allows customers to browse products anonymously. However, before customers can actually add items to their shopping cart and place an order they must log in. Customers can click the Log in button and provide their username and password to authenticate themselves, as shown in Figure 4.

Figure 4 - A customer logging in

If the customer is new and does not yet have an account, the customer can click the Register button. The Register screen prompts the customer to provide details such as an email address (used to identify the customer when they log in), a password, a billing address, and credit card information. Figure 5 illustrates the page that enables a customer to register their information.

Figure 5 - Registering as a new customer

Adding Items to the Shopping Cart

Once a customer has logged in, the customer can add an item to the shopping cart by clicking Add To Cart. The customer can also specify the number of items to order on this page. The data in the shopping cart is saved to the database. This feature adds a degree of robustness to the application; if the user's browser should crash or lose connectivity to the Shopping application, the shopping cart is not lost. When the customer connects to the Shopping application again, they can carry on shopping and the customer can add further items to their cart.

The user can click the Shopping Cart icon at any time to review the contents of their shopping cart. This page also enables the customer to remove an item from their cart, or check out and place an order for the items in their cart. Figure 6 shows the shopping cart page in the Shopping application.

Figure 6 - The shopping cart for a customer

Placing an Order

To place an order, the customer can click Checkout on the shopping cart page. At this point, the customer must confirm information such as a billing address and a credit card. The image in Figure 7 shows this page.

Figure 7 - Specifying the billing information for an order

When the customer clicks Confirm, the order is placed and the customer receives confirmation of the order details, as shown in Figure 8.

Note

In the real world, when the customer places an order, the items in the order are picked using a separate warehousing system and the order is then shipped using a dispatching system. The Shopping application has to integrate with these warehousing and dispatching systems although they are outside the scope of the Shopping application and they are not included in the sample solution provided with this guide.

Figure 8 - The confirmation page showing the details of an order

Note that when a customer places items in their shopping cart, the contents of the cart are saved, and the user can close the browser without placing an order. The next time the customer logs in, their cart is restored, and they can add further items or simply check out using the items currently in their cart. However, it is possible that the price of one or more items might have changed since the customer added them to the cart. When the customer clicks Confirm in the Checkout page, the Shopping application verifies each item to ensure that its price has not been updated. If there are any differences, the Shopping application displays the message shown in Figure 9.

Figure 9 - Informing the customer that the price of one or more items has changed

The customer can click OK to view their shopping cart, which indicated which items have changed, as shown in Figure 10.

Figure 10 - The shopping cart indicating which items have a different price

If the customer is happy to accept the new price, they can click Checkout, and the process proceeds as described earlier.

Viewing Order History

A customer can view an audit trail listing any orders that they have previously placed, and any modifications made to those orders since they were placed, by clicking My Orders in the menu bar. Figure 11 shows the order history for a customer. Note that in the sample solution, when an order is created and added to the database, its status is set to Pending. Later, when the order has been processed its status is set to Completed. The order history for an order therefore displays at least two entries (one for each status). If an order is subjected to any further modifications, then the order history will contain entries for each of these changes as well.

Figure 11 - The order history for a customer

The customer can click the Tracking Id link for any order history record to view the details of that record, as shown in Figure 12.

Figure 12 - An order history record

How the Shopping Application Stores Information

A traditional web application stores data in a relational database and the business logic of the web application retrieves, displays, and modifies this information as the user browses the data. However, the developers at Adventure Works felt that this approach might not scale well for the Shopping application; they anticipate that the application will attract many thousands of concurrent users each placing many orders. For this reason, the developers decided to optimize the application by using a combination of data storage technologies, each one tuned to meet the specific business requirements of the various use cases, as follows:

• Customer information is stored by using SQL Server. The application must maintain customer confidentiality and security. SQL Server easily integrates into the security framework provided by the technologies used to build the Shopping application, and so it provides the ideal repository for holding the details of customers and their passwords.
• Shopping cart information is saved in a simple key-value store that can be accessed by using the customer's unique identifier as the lookup key. This mechanism is very quick and highly scalable.
• The details of products do not change very often, and in the Shopping application this data is read-only, this information can be stored and retrieved efficiently by using a document database.
• Customers can place multiple orders, and each order can contain many line items. The warehousing and dispatching systems that actually arrange for goods to be picked and shipped to the customer frequently modify the status information and other details of an order. These systems, which are outside the scope of the Shopping application, use SQL Server to meet the OLTP requirements of the business. Therefore the developers decided to save the details of orders to the same database to enable the Shopping application to integrate seamlessly with these systems.
• Once an order has been placed, the details of the order constitute a historical document, and the system must record a full audit trail of any changes made to the order. Therefore, the developers decided to save order information in two places; the active orders are held in SQL Server as described previously, but a historical record of each order is stored in a document database as a series of order history documents. Each order history document is held in a fully denormalized structure to enable the details of the order to be retrieved quickly. As changes occur to an order, a new order history document containing the updated order information is added to the document database, together with a date stamp indicating when the change occurred. In this way, it is possible to obtain the complete history that lists all the changes that have been made to an order.
• Product recommendations require maintaining complex relationships between products, customers, and orders. This type of information is best stored in a graph database.

The chapters in this guide describe how the developers at Adventure Works designed and implemented these data stores. These chapters also illustrate good practice for building applications that utilize these data stores.

Note

This guide concentrates on describing best practices for using SQL and NoSQL databases to store and retrieve data. It does not provide strategies for migrating data from a relational database to a NoSQL database.

The Architecture of the Shopping Application

The developers at Adventure Works are knowledgeable about various Microsoft products and technologies, including the .NET Framework, ASP.NET MVC and the ASP.NET Web API, SQL Server, and Visual Studio, so they decided to implement the solution by using these technologies.

The solution comprises three main components:

• The customer-facing user interface, implemented as an MVC4 web application. This application formats and displays information about products from the database, and enables the user to navigate through the site and place orders. Users can connect to this application using a web browser.

  Note

  In this guide, the user interface web application is provided simply as a means to demonstrate that the various data access mechanisms described are functioning correctly. It is possible to replace this user interface with any other application that can formulate the appropriate REST requests and consume REST responses.

• The business logic, implemented as a set of web services in an MVC4 Web API application. This application exposes the data and operations that it supports through a REST (Representational State Transfer) interface. Separating the business logic in this way decouples it from the user interface, minimizing the impact that any changes to the implementation of the user interface will have on this business logic.

Jana says:

Using REST enables Adventure Works to invoke operations and consume the responses by using any web-enabled system that can formulate REST queries, giving them great flexibility if they wish to integrate these services into other parts of their operations. Additionally, if Adventure Works decides to operate through partner organizations in different territories, those partners can implement their own localized user interfaces that generate REST requests and process REST responses.

• Data storage, implemented by using a combination of SQL Server and NoSQL databases. The designers at Adventure Works selected different repositories to match the business requirements of each of the use cases as described in the previous section. The web services access the data in these databases by using Repository pattern to isolate the database-specific code from the business logic.

Appendix A, "How the MvcWebApi Web Service Works," contains detailed information on the structure of the web service and the code that connects to the various repositories.

Building and hosting a web application for a multinational organization such as Adventure Works is a major undertaking and can require a significant investment in hardware, management, and other infrastructure resources. Connectivity and security are also major concerns; users require timely and responsive access, and at the same time the system must maintain the integrity of the data in the database and the privacy of users' information. To support a potentially large number of concurrent requests against an ever-expanding database, the designers at Adventure Works chose to implement the Shopping application in the cloud by using Windows Azure. The web application that implements the user interface and the web service that provides the business logic are deployed as web roles. Additionally the designers chose to deploy the various data stores that the application uses to the cloud. These data stores comprise a combination of Windows Azure SQL Database (SQL Server in the cloud), Windows Azure Table Storage, and other NoSQL databases running on virtual machines hosted in the cloud. This environment provides the necessary scalability, elasticity, reliability, security, and performance necessary for supporting a large number of concurrent, distributed users.

Bharath says:
	Deploying a solution such as this to the cloud minimizes the hardware and support investment that Adventure Works needs to make. They can monitor the volume of traffic to the web application and the web service, and if necessary simply scale the solution to run additional instances with more resources.

Note

As an alternative to using Windows Azure SQL Database, the architects also considered hosting the SQL Server database in a Windows Azure VM. However, they came to the conclusion that Windows Azure SQL Database would provide the scalability that the application requires, but they might review this decision in the future. Chapter 3, "Implementing a Relational Database" provides more information about the benefits and tradeoffs of using Windows Azure SQL Database against running a SQL Server database in a Windows Azure VM.

Figure 13 shows a high-level view of the Shopping application running in the cloud. Customers can connect to the user interface web application over HTTP from any device that provides a web browser.

Note

IMPORTANT
The UI web application generates anti-forgery tokens that help to protect critical operations such as registering as a new customer, logging in, and placing an order (other operations, such as viewing the product catalog, expose data that is in the public domain and are not protected). However, the MvcWebApi web service currently implements only minimal security measures. Any application that knows the URL of the web service can connect to it and send requests. A real-world implementation of this system would include more robust authentication and prevent unauthorized use, but in this reference implementation the additional code would obscure the data access guidance that this application is designed to convey.
Additionally, the application does not include any logging capabilities. If you wish to capture information about events such as failed and successful login attempts, the dates and times when customers placed orders, and other significant actions, you can incorporate this functionality into the web service by using the Semantic Logging Application Block. The Semantic Logging Application Block is part of the Microsoft Enterprise Library available from the patterns & practices website.

Figure 13 - High-level overview of the Adventure Works Shopping application running in the cloud

For more information about building and deploying applications to the cloud by using Windows Azure, see the patterns & practices guide "Developing Multi-tenant Applications for the Cloud, 3rd Edition" available from MSDN.

Summary

This chapter has introduced the Shopping application built by Adventure Works. The application consists of an MVC4 web application that acts as the user interface, a web service that provides a REST interface to the web application, and a collection of SQL and NoSQL databases that store the data for the web application.

In the following chapters, you will see how the developers at Adventure Works designed the data stores to optimize access to the data required by the application, and how they implemented the code that accesses this data.

More Information

All links in this book are accessible from the book's online bibliography on MSDN at: https://msdn.microsoft.com/en-us/library/dn320459.aspx.

• The community site for this guide at http://dataguidance.codeplex.com/ provides links to online resources.
• You can download the sample code described in this chapter from the Microsoft Download Center at https://www.microsoft.com/en-us/download/details.aspx?id=40294
• The patterns & practices guide "Developing Multi-tenant Applications for the Cloud, 3rdEdition" is available on MSDN.
• The portal with information about Microsoft Windows Azure is at https://www.microsoft.com/windowsazure/. It has links to white papers, tools, and many other resources. You can also sign up for a Windows Azure account here.
• You can download the Microsoft Enterprise Library from the patterns & practices website at https://msdn.com/entlib.

Next Topic | Previous Topic | Home | Community