Commerce Server 2009 OperationSequenceComponent Extensibility, Part 2

In my previous post, I discussed using the Commerce Foundation’s extensibilty model to create a basic pricing engine.  I created a simple OperationSequenceComponent that I configure to run whenever a query for a product comes through the foundation.

While this was simple to do and worked great, as Brian pointed out in the comments, it doesn’t completely solve the problem.  As you can see, once we add that item to the basket, then the pricing reverts back to the original pricing.

The reason that this occurs is that basket calculations are not done in the Commerce Foundation, but are done down in the legacy COM-based pipelines.  The legacy pipelines actually query for product information directly to the database.  It does not go through the Commerce Foundation.  This means that are extension that we built never gets hit.

Lets open up the pipelin editor, which is in the tools folder and then navigate to the basket.pcf, which contains the sequence of components to run when the basket pipeline is run.

Fortunately for us, we know that it is the “QueryCatalogInfo” pipeline component, which is the first component that runs, that retrieves the basic information for a product and pushes it into the context for later use by other pipeline components.

So it would be nice to know what this component does.  The easiest way to do that is to turn on logging.  Pipelines can log everything read or written to the context, so it’s relatively easy to turn on logging and look at what the various components do.  To turn on logging, you go to the web.config and find the entry in the <pipelines> section and change logging to “true”.

pipeline name="basket" path="pipelines\basket.pcf" transacted="false" type="OrderPipeline" loggingEnabled="true" />

The basket pipeline runs every time you load the basket page, so it’s easy to see what happens by refreshing the basket page.  There should be a new folder underneath the Pipelines folder in your virtual directory which has file with an extension “.pipelog”  Open the “basket.pipelog” up in notepad and you should see a log of everything that the pipeline read or wrote during it’s execution.  The first pipeline component that executed is what we are interested in and so we can look at that:

This gives us a good idea of what this “QueryCatalogInfo” component does.  Now we have a couple of choices here.

1) We can create another com-based pipeline component that we put right after the "QueryCatalogInfo” component that adjusts the price per our business rules

2) We remove this legacy component and replace it with an OperationSequenceComponent that does the same thing.

If I want to simply stick another COM component in there then I end up having to run my rules-engine with any caching etc in two places.  I would much rather simply change the way the pipeline works so that it retrieves the product information using the Commerce Foundation, executing my pricing extension in the same way it does when I retrieve a product for display.

The other thing that you might notice is that it writes a lot of stuff into the context that you really don’t need because no other pipeline component uses them.  We can probably make something that is more simplified and only passes in information that we need.

What you might notice in looking at the above list of values read and written is that there are certain values that the pipeline assumes are already there.  For example, it assumes that there is an “Items” entry and it assumes that for each item in the items dictionary there is a productid, variantid, catalog,, catalog-language. 

So if those entries are already there, how did they get there?  The answer is that there is certain information pushed into the context by the Commerce Foundation before a pipeline is even run.  In our case the helper method for the basket pipeline knows that some elements of the orderform need to be in the pipeline context before it is run and it helpfully (hence the name…) copies them over for us.

Now if it loaded the orderform and directly copied the values into the context in the same OperationSequenceComponent, then we would have a very hard time extending it.  Luckily for us, this was something that was considered and it was broken into several operations.

If you open up the “channelconfiguration.config” file and search for “QueryOperation_basket” you will see the following entries:

<Component name="Basket Loader" type="Microsoft.Commerce.Providers.Components.BasketQueryProcessor, Microsoft.Commerce.Providers, Version=1.0.0.0, Culture=neutral,PublicKeyToken=31bf3856ad364e35" />
…

          <Component name="Order Pipelines Processor" type="Microsoft.Commerce.Providers.Components.OrderPipelinesProcessor, Microsoft.Commerce.Providers, Version=1.0.0.0, Culture=neutral,PublicKeyToken=31bf3856ad364e35">
<Configuration customElementName="OrderPipelinesProcessorConfiguration" customElementType="Microsoft.Commerce.Providers.Components.

OrderPipelinesProcessorConfiguration, Microsoft.Commerce.Providers, Version=1.0.0.0, Culture=neutral,PublicKeyToken=31bf3856ad364e35">
<OrderPipelinesProcessorConfiguration>
<!--
The name attribute should contain one of the Order pipeline names defined in the pipelines section of the CommerceServer site configuration.
The type attribute should contain one of the values of the Microsoft.CommerceServer.Runtime.Orders.OrderPipelineType enumeration:
Custom Indicates a custom pipeline type.
Product Indicates a Product pipeline (e.g. Product.pcf).
Basket Indicates a Basket pipeline (e.g. Basket.pcf).
Total Indicates a Total pipeline (e.g. Total.pcf).
Checkout Indicates a Checkout pipeline (e.g. Checkout.pcf).
AcceptBasket Indicates an AcceptBasket pipeline (e.g. AcceptBasket.pcf).
-->
<OrderPipelines>
<Pipeline name="basket" type="Basket" />
<Pipeline name="total" type="Total" />
</OrderPipelines>
</OrderPipelinesProcessorConfiguration>
</Configuration>
</Component>

You see that there is a “Basket Loader” component that runs first.  This loads the basket and places it in the operationCache.  Later the “Order PipelinesProcessor” runs and this takes that cached order and writes it into the context.

This is great because we have the ability to inject our own logic between those two entries that modifies the basket object in the operationCache and adds our additional information to the basket line items.

So we can write a new OperationSequenceComponent that looks like this:

What this component does is retrieve the basket from the operationCache, walk through each of it’s order forms and each line and calls out to the foundation to retrieve data for each item.  This will then execute the “QueryOperation_Product” which will execute our custom pricing rule.  The retrieved data is then copied into the order forms lineItem dictionary.

This means that when the basket is copied into the context later on in the component sequence, it will already have those values in place that the QueryCatalogInfo is supposed to put there.  So we can remove that piepline component so that it will not run.

We strong-name, build and GAC the component above and we can go into the “channelconfiguration.config” file and add this new components into the list right above the “Order Pipelines Processor” component in the “QueryOperation_basket” message handler.  Note that the “Order Pipeline Processor” component is called from a number of message handlers and we need to add this entry above each one:

<Component name="QueryCatalogInfo" type="Microsoft.Commerce.Samples.Pipelines.QueryCatalogInfo, Microsoft.Commerce.Samples.Pipelines, Version=1.0.0.0, Culture=neutral,PublicKeyToken=b23706c1d1011ab9" />

It looks like we have everything configured now, so lets restart IIS (give it a clean slate) and refresh the basket again and see what we get.

Amazingly enough, my basket now contains the pricing generated by my pricing engine.  I’ve also removed a legacy com-based component from a pipeline which is executed quite a lot, which gives me more control of the overall solution.