Passing OrderForm to Business and Data Tiers
Now, let's look at how you can use the Commerce Server framework to pass the OrderForm data to the business tier and, ultimately, to the database for storage in the Customer, OrderHeader, and OrderDetail tables. The Commerce Server framework provides another COM component, the Pipeline component, to help process purchase-related data. The Commerce.MtsTxPipeline and Commerce.MtsPipeline components simplify the developer's job of applying business rules to the data in the OrderForm component. The first Pipeline component uses COM+ services to apply all data updates within a transaction; the second component doesn't offer transaction services.
The Pipeline is a conceptually simple way to sequentially call components that support the IPipeline COM interface (for information about this interface, see the Commerce Server software development kit—SDK). Each component that the Pipeline calls interacts with the OrderForm component, then passes the OrderForm back to the Pipeline, which calls the next component, and so on.
You can use the graphical Pipeline Editor to configure the Pipeline by specifying which components it hosts and the order of their execution. The Pipeline Editor saves these configuration parameters to a file called a Pipeline Configuration File (PCF). You can create any number of PCFs for a Web application. For example, you might want to configure one PCF for the shopping-cart page, one for the order process, one for order confirmation, and so on.
After the business tier has applied the business rules to the OrderForm component, you need to pass this data to the data tier for storage in the relational database management system (RDBMS). As I noted at the beginning of this article, this process traditionally involves multiple round-trips, or database calls, from the data-tier components to the RDBMS.
Consider a PCF called Purchase.pcf, which defines the purchase process. This particular pipeline file includes components for acquiring a unique order number, ensuring that all required OrderForm fields are present, authenticating the customer's credit card information, and so on. When all this prep work is done and the completed order is ready to go to the RDBMS, the business tier calls one or more data-tier components, passing in the OrderForm component as an input parameter. These data-tier components then disassemble the OrderForm, map its data to the tables and stored procedures in the RDBMS, and send this data a piece at a time to the database. Figure 3 shows pseudocode that depicts this flow of data from the data tier to the RDBMS, highlighting the actions that require a network round-trip.
SQL Server 2000's new XML-integration features let developers read data from and write data to SQL Server as XML. XML describes the structure and content of data as simple text. The OpenXML rowset provider lets you send a set of data to the database in the form of an XML document, then expose this data to SQL Server 2000 as a relational rowset. You can then extract the data in this rowset and use it to perform multiple inserts, updates, and deletes. Let's look at how you can use OpenXML to simplify and streamline the process of getting the order data from the data tier and into SQL Server.
Putting OpenXML to Work
You can think of the OpenXML rowset provider as a function because it returns a relational rowset that you can use as you would use a table. This feature lets you use data in XML documents as the source for queries, inserts, updates, and deletes.
To use OpenXML, you must first load an XML document into an in-memory tree—or Document Object Model (DOM)—structure by using the sp_xml_preparedocument system stored procedure. This stored procedure returns an integer handle, which the OpenXML function can then use to access the DOM. The basic OpenXML syntax is
OpenXML(idoc int [in], rowpattern nvarchar [in],
[flags byte [in]]) [WITH (SchemaDeclaration | TableName) ]
The only required parameters are idoc (the integer handle to the DOM) and rowpattern (which you specify by using XPath pattern syntax). The XPath rowpattern parameter identifies the XML nodes within the XML document that are to be processed. Some nodes map to database table rows; others map to columns. The optional flags input parameter defines the mapping that OpenXML will use between the XML document nodes and the relational rowset. By default, OpenXML uses attribute-centric mapping, which corresponds to a value of 0. A value of 1 also specifies attribute-centric mapping, and a value of 2 specifies element-centric mapping.
You use elements to mark up sections of an XML document, as this example shows:
<ElementName>content of an element</ElementName>
Elements can contain content, but they also might be empty or contain child elements, as the following example shows:
<ElementParent>
<ChildElement1>West All Stars</ChildElement1>
<ChildElement2>East All Stars</ChildElement2>
</ElementParent>
Attributes, in contrast, add descriptive information to an element, such as
<ProductImage type="thumbnail">1237.jpg</ProductImage>
In this case, type is the attribute and has a value of "thumbnail".
Prev. page
1
[2]
3
4
next page 
