Before You Start Developing with the Orders System

The Orders System implements the data abstractions and processes for placing orders on a Web site. The following list identifies key features of the Orders System:

  • Provides a representation of orders, both in-progress (called "baskets") and after the order has been placed (called "purchase orders").

  • Persists purchase orders to a database for later searching or processing by business systems.

  • Provides a mechanism for processing orders (called "pipelines") during the order's lifetime.

  • Represents orders in four ways:

  1. As .NET classes during run time.

  2. As name/value pairs (called "Dictionaries") while a pipeline is processing the order.

  3. As columns in a database after an order has been completed.

  4. As XML documents when a BizTalk adapter is using the order data.

  • Allows you to extend the runtime objects, the pipelines that process orders, and the database schema for storing purchase orders.

  • Allows you to name baskets, in order to implement special types of baskets such as wish lists.

Why Use the Orders System

By using the Orders System, you can obtain several important benefits without implementing custom code. The Orders System was designed to provide the following:

  • Data abstraction. Because you access orders in your code by using an object model, your code does not have to refer to the structure of the underlying data source.

  • Process abstraction. The pipelines that process orders are abstracted from the Web site code, allowing you to create new pipeline components without rewriting the site code.

  • Split tenders. You do not have to write a custom pipeline to process multiple payment methods for a single order.

  • Split shipments. You do not have to write a custom pipeline to handle multiple shipment addresses for a single order.

  • Mapped storage. The Orders System maps purchase orders to SQL tables so that you can mine purchase order data.

  • Customizable payment methods. You can create new payment methods.

  • Named baskets. You can implement custom types of baskets such as wish lists.

  • Customer and Orders Manager. Business users can use the Customer and Orders Manager to manage orders. You do not have to create a new user interface to allow business users to manage orders.

  • Extensible object model. You can extend the .NET classes to modify the behavior of the Object System.

  • Web services. The Orders System uses a service architecture, so that you easily can send orders to a line-of-business system.

High-level Scenarios

The following list describes the key scenarios for using the orders system:

  1. Adding items to a shopping basket.

  2. Adding items to a wish list, recurring basket, or gift registry.

  3. Viewing a basket on the Web site.

  4. Checking out and purchasing a basket.

  5. Finding, modifying, and deleting baskets.

  6. Finding, modifying, and deleting purchase orders.

  7. Processing punch-outs to accept baskets via a Web service.

See Also

Other Resources

Developing with the Orders System