Orders System Architecture
For the latest version of Commerce Server 2007 Help, see the Microsoft Web site.
At the center of the Orders System is the Orders database, which contains data about the objects in the Orders System. You can access the Orders database through run-time objects, through a BizTalk adapter, through the Orders Agent, or directly through the Orders Web service. The following figure illustrates the architecture of the Orders System.
.gif "Orders System architecture")
Along with the different ways to access the Orders System, there are also different API sets for interacting with the Orders System and different representations of Orders data.
The rest of this topic introduces the core components of the Orders System, the Orders API sets, and the ways that Orders data is represented.
The Orders Database
The Orders database contains data about two kinds of orders: orders that have already been placed (called PurchaseOrders) and orders that are in progress (called Baskets). To optimize performance, Commerce Server serializes a Basket into a binary large object (BLOB) before storing it in the Orders database. To improve searchability, Commerce Server allows you to map a PurchaseOrder’s properties to specific columns in database tables.
For more information about the Orders database, see How Orders Objects Are Stored in the Database.
Orders Runtime Objects
Site code interacts with the Orders System through .NET classes in the the Microsoft.CommerceServer.Runtime.Orders namespace in the Commerce Server runtime. At a high level, your site code would create a Basket object, add LineItem objects to the Basket, process a checkout, and convert the Basket to a PurchaseOrder object. At the beginning of each page, your site code would retrieve the Basket from the database; at the end of each page, your site code would save the Basket to the database if the Basket had changed. Commerce Server automatically converts the database representations of Baskets and PurchaseOrders to runtime objects.
For more information about the Orders runtime object model, see Orders Runtime Object Model.
Orders Agent
Outside of your site code, applications can interact with the Orders System via the Orders Agent. The Orders Agent is the abstraction participant in the bridge design pattern. There are two possible implementation participants that the Orders Agent can collaborate with. With the out-of-process (out-of-proc) implementation, the Orders Agent uses the Orders Web service to interact with the Orders database. With the in-process (in-proc) implementation, the Orders Agent interacts directly with the Orders database. By using the Orders Agent you only need to change the way you create the Orders Agent (that is, the way you instantiate the OrderManagementContext class) to make the same code work both in-proc and out-of-proc. For more information about the agents and the bridge pattern, see “Design Patterns, Elements of Reusable Object-Oriented Software” by Gamma, Helm, Johnson, and Vlissides.
Line-of-business applications might interact with the Orders System by using the Orders Agent out-of-proc. The Commerce Server Customer and Orders Manager is one example of an application that uses the Orders Agent out-of-proc. The BizTalk adapter for the Orders System uses the Orders Agent out-of-proc.
Command-line tools might interact with the Orders System by using the Orders Agent in-proc. For example, if you wrote a command-line tool to purge old baskets from the database, you might use the Orders Agent in-proc to interact with the Orders database.
Orders Web Service
Line-of-business applications that are not running on Microsoft Windows can interact with the Orders system through the Orders Web service. The Orders Web service provides access to Orders System functionality through a standardized SOAP interface.
Orders System APIs
There are two sets of APIs for accessing the Orders System: the runtime APIs and the data management APIs.
The run-time APIs are contained in the Microsoft.CommerceServer.Runtime.Orders namespace. Use the run-time APIs in your site code.
The data management APIs are contained in the Microsoft.CommerceServer.Orders namespace. Use the data management APIs to create client/server applications that access Orders data.
For more information about the Orders run-time classes, see Orders Runtime Object Model. For more information about the Orders data management classes, see Orders Data Management Object Model.
Orders Data Representations
The Orders System uses multiple representations for the same Orders objects. These representations are:
Run-time objects. A run-time object is an instance of a .NET class. Site code generally uses the run-time object representation.
Dictionaries. A dictionary is a set of name/value pairs that represent the attributes of an object. Pipeline components use the dictionary representation.
Datasets. A dataset is an in-memory representation of data from a database. The dataset representation is used primarily for displaying Orders data.
Databases. The database is the system of record for orders data. You can use SQL queries to mine Orders data, but you should not modify the Orders database directly.
XML. An XML document is a serialized representation of an object. BizTalk adapters and other line-of-business applications use the XML representation