There is a built-in restriction in the new Commerce Server 2009 Foundation API (MCCF - Multi Channel Commerce Foundation) to only expect one OrderForm instance on the aggregate root, being the OrderGroup. An OrderGroup is either a Basket or PurchaseOrder (or OrderTemplate if you are using that).

Below is a simplified diagram of the key classes in the Object Model for the Orders System. Please notice that we have the OrderForms collection on the OrderGroup class, where each instance of an OrderForm can be retrieved either by index or by a name (string).

This allows us to create multiple OrderForms, each with their own data like Line Items, Payments, Shipments etc, and share other data like Addresses, TrackingNumber and a few more properties on the OrderGroup class.

In all projects I’ve been working on we don’t actually use the ability to have multiple OrderForms. We only have one single OrderForm at all times.

The Commerce Server 2007 code would then look something like:

             1: Basket basket = OrderContext.Current.GetBasket(userId,
basketName);

             2:  

             3: 
            if (basket.OrderForms.Count
== 0)

             4:  basket.OrderForms.Add(new OrderForm());

This retrieves a named Basket from the Orders System and if the basket is new, it will create an instance of OrderForm and add this to the OrderForms collection.

             1: basket.OrderForms[0].LineItems.Add(

             2: 
            new LineItem("ProductCatalog", "ProductID", "VariantID",
1m));

At some point we would then like to add a Line Item to our basket as illustrated above where we hardcode the index-value to 0 to retrieve the one and only OrderForm we have.

In Commerce Server 2009 though, we never deal with the actual types, instead we work with the ICommerceEntity type. The Commerce Server 2009 code for retrieving a basket would be something like:

             1: var query = new CommerceQuery<CommerceEntity>("Basket");

             2:  

             3: query.SearchCriteria.Model.SetPropertyValue("UserId",
userId);

             4: query.SearchCriteria.Model.SetPropertyValue("BasketType",
0); // 0 = Basket, 1 = Purchase Order

             5: query.SearchCriteria.Model.SetPropertyValue("Name",
basketName);

             6:  

             7: var operationServiceAgent = new OperationServiceAgent();

             8:  

             9: var response =

             10:  operationServiceAgent

             11:  .ProcessRequest(

             12: 
            new CommerceRequestContext

             13:  {

             14:  Channel = "DefaultChannel",

             15:  UserId = Guid.NewGuid().ToString("b"),

             16:  UserLocale = CultureInfo.CurrentCulture.ToString(),

             17:  UserUILocale = CultureInfo.CurrentUICulture.ToString(),

             18:  RequestId = Guid.NewGuid().ToString()

             19:  }, 

             20:  query.ToRequest())

             21:  .OperationResponses

             22:  .Single() as CommerceQueryOperationResponse;

             23:  

             24: var basketEntity = response.CommerceEntities.Single();

Effectively this will execute the CommerceQueryOperation_Basket Operation Sequence defined in ChannelConfiguration.config which in short will load the Basket from the Orders System and map this to the generic ICommerceEntity type.

In the process of retrieving and mapping a Basket to a ICommerceEntity the following extension method from Microsoft.Commerce.Providers.Utility.OrderGroupExtensions is being called on the OrderGroup:

             1: 
            public
            static
            void EnsureDefaultOrderForm(this OrderGroup
orderGroup, string modelName)

             2: {

             3:  ParameterChecker.CheckForNull(orderGroup, "orderGroup");

             4: 
            if (orderGroup.OrderForms["Default"]
== null)

             5:  {

             6: 
            if (string.IsNullOrEmpty(modelName))

             7:  {

             8:  modelName = "Basket";

             9:  }

             10:  OrderForm orderForm = CommerceServerClassFactory.CreateInstance<OrderForm>(modelName,
2, newobject[] { "Default" });

             11:  orderGroup.OrderForms.Add(orderForm);

             12:  }

             13: }

This method is responsible of making sure that a single OrderForm with the name “Default” is always available in the OrderForms collection of the OrderGroup instance.

Also there is an extension method to always retrieve this single OrderForm called Microsoft.Commerce.Providers.Utility.OrderGroupExtensions.GetDefaultOrderForm.

             1: 
            public
            static OrderForm
GetDefaultOrderForm(this OrderGroup orderGroup, string modelName)

             2: {

             3:  ParameterChecker.CheckForNull(orderGroup, "orderGroup");

             4: 
            if (orderGroup.OrderForms["Default"]
== null)

             5:  {

             6: 
            if (string.IsNullOrEmpty(modelName))

             7:  {

             8:  modelName = "Basket";

             9:  }

             10:  OrderForm orderForm = CommerceServerClassFactory.CreateInstance<OrderForm>(modelName,
2, newobject[] { "Default" });

             11:  orderGroup.OrderForms.Add(orderForm);

             12:  }

             13: 
            return orderGroup.OrderForms["Default"];

             14: }

This method is used throughout the many Operation Sequence Components in the Foundation API and if you are developing your own custom Operation Sequence Components that works on the Orders System this method is properly something you would like to use.

As mentioned earlier we’ve just been using one OrderForm in all our Commerce Server projects, so this new limitation is not a problem for us, but on one of my Commerce Server Training courses I had a guy telling me that they where actually using multiple OrderForms on a CS 2007 project, so this new limitation would be a problem for them if they were to upgrade or create a similar solution on a new CS 2009 project.

What if we need more than OrderForm on our project, what to do?

In short: rethink. A solution with multiple OrderForms in CS 2009 will be too difficult to implement because of the many dependencies in the standard Operation Sequence Components that expecting there to be only one – remember they are all calling the GetDefaultOrderForm() extension method. Consider using multiple OrderGroups instead.

If you are reading this and have come up with a better solution to having multiple OrderForms in CS 2009 or have any comments at all I would really appreciate hearing from you :-)

Max Akbar’s Commerce Server 2007 training videos have yet again become available for purchase. More than 19 hours of material can now be found on http://www.commerceservertraining.com/training-videos.aspx.

We are working on producing and releasing new training videos targeting Commerce Server 2009.

In Commerce Server the Rank property is used as a sorting discriminator when retrieving categories, products and variants. This property is usually managed using Catalog Manager as shown in the screenshot below:

The Rank property could also be managed in your own application which will be the topic of a later blog-post. This blog-post will focus on how to get the actual Rank value when retrieving categories in Commerce Server.

How did we do this in in Commerce Server 2007?

Pretty easy! We just include “Rank” as an item in the PropertiesToReturnArray for child categories (line 12) when requesting a specific category and later retrieve the value from the property-bag of the Category instance (line 24) as shown in the example below:

             1: 
            public
            void RequestUsing2007(string catalogName, string categoryName)

             2: {

             3:  var catalogSystem = CommerceContext.Current.CatalogSystem;

             4:  

             5:  var configuration = new CategoryConfiguration

             6:  {

             7:  LoadChildCategories = true,

             8:  ChildCategories =

             9:  {

             10:  SearchOptions =

             11:  {

             12:  PropertiesToReturnArray = new[]
{ "DisplayName", "Rank" }

             13:  }

             14:  }

             15:  };

             16:  

             17:  var category =

             18:  catalogSystem.GetCategory(catalogName, categoryName, "da-DK",
configuration);

             19:  

             20: 
            foreach (var childCategory in category.ChildCategories)

             21:  {

             22:  _writer.WriteLine("Id={0}",
childCategory.Name);

             23:  _writer.WriteLine("DisplayName={0}",
childCategory.DisplayName);

             24:  _writer.WriteLine("Rank={0}",
childCategory["rank"]);

             25:  

             26:  _writer.WriteLine();

             27:  }

             28: }

And how can I do it in Commerce Server 2009?

In Commerce Server 2009 with the new Foundation API the overall way of retrieving entities in Commerce Server has changed a lot. In the example below I’ve added “Rank” as part of the properties to retrieve when requesting child categories for a specific category (line 10):

             1: 
            public
            void RequestUsing2009(string catalogName, string categoryName)

             2: {

             3:  var categoryQuery = new CommerceQuery<CommerceEntity>("Category");

             4:  categoryQuery.Model.Properties.Add(new[]
{ "Id", "DisplayName" });

             5:  

             6:  categoryQuery.SearchCriteria.Model.SetPropertyValue("CatalogId",
catalogName);

             7:  categoryQuery.SearchCriteria.Model.SetPropertyValue("Id",
categoryName);

             8:  

             9:  var childCategoryQuery = new CommerceQueryRelatedItem<CommerceEntity>("ChildCategories", "Category");

             10:  childCategoryQuery.Model.Properties.Add(new[]
{ "Id", "DisplayName", "Rank" });

             11:  categoryQuery.RelatedOperations.Add(childCategoryQuery);

             12:  

             13:  var operationServiceAgent = new OperationServiceAgent();

             14:  

             15:  var response = 

             16:  operationServiceAgent.ProcessRequest(

             17: 
            new CommerceRequestContext

             18:  {

             19:  Channel = "MyChannel",

             20:  UserLocale = "da-DK",

             21:  UserUILocale = "da-DK",

             22:  RequestId = Guid.NewGuid().ToString()

             23:  }, 

             24:  categoryQuery.ToRequest());

             25:  

             26:  var operationResponse = (CommerceQueryOperationResponse)response.OperationResponses.Single();

             27:  

             28:  var entity = operationResponse.CommerceEntities.SingleOrDefault();

             29:  

             30: 
            foreach (var childCategory in entity.Properties["ChildCategories"] as CommerceRelationshipList)

             31:  {

             32: 
            foreach (var categoryProperty in childCategory.Target.Properties)

             33:  {

             34:  _writer.WriteLine

             35:  ("{0}={1} ({2})", 

             36:  categoryProperty.Key, 

             37:  categoryProperty.Value, 

             38:  categoryProperty.Value.GetType().Name);

             39:  }

             40:  

             41:  _writer.WriteLine();

             42:  }

             43: }

One of the Operation Sequence components being executed in this operation is responsible for creating the CategoryConfiguration instance, that we manually created in the Commerce Server 2007 example (CS 2007 example line 5). This Operation Sequence component is named “CategoryConfiguration_Prepare”.

The actual logic for building the CategoryConfiguration instance is implemented in a class named CatalogConfigurationBuilder. This class will look in the MetadataDefinitions.xml file to match up the properties requested by the developer (in our case “Id, DisplayName, Rank”) with the properties registered for the actual entity being requested (“Category”).

If Rank is not registred in the MetadataDefinitions.xml file, it will be ignored by the CatalogConfigurationBuilder (method doing this is called TranslatePropertyName) and will therefore not be part of the “PropertiesToReturnArray” that in the end decides which columns to retrieve from the catalog table in SQL Server.

To make sure that Rank is registred in MetadataDefinitions.xml verify it by follow these steps:

1. Open MetadataDefinitions.xml
2. Locate <CommerceEntity name=”Category”>
3. Make sure that there is a <PropertyMapping> element for property=”Rank” (<PropertyMapping property=”Rank” csProperty=”rank” />)
4. Make sure that there is a <Property> element for name=”Rank” (<Property name=”Rank” dataType=”String” />)

Step 3 explained:

             1: 
            <
            EntityMappings
            >
          

             2: 
            <
            EntityMapping
          

             3: 
            csType
            ="Microsoft.CommerceServer.Catalog.Category"
          

             4: 
            csAssembly
            ="Microsoft.CommerceServer.Catalog,
Version=6.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
            >
          

             5:  

             6: 
            <
            PropertyMappings
            >
          

             7: 
            <!-- 
          

             8: 
             The following mappings are required
here to ensure that all
          

             9: 
             the product common properties
are represented in the Microsoft Multi-Channel Commerce Foundation 
          

             10: 
             metadata. These are not returned
by the Commerce Server
          

             11: 
             metadata automatically as the
common properties.
          

             12: 
             -->
          

             13: 
            <
            PropertyMapping
            property
            ="BaseCatalogName"
            csProperty
            ="BaseCatalogName"
            />
          

             14: 
            <
            PropertyMapping
            property
            ="Rank"
            csProperty
            ="rank"
            />
          

Step 4 explained:

             1: 
            <
            Properties
            >
          

             2: 
            <!-- 
          

             3: 
             The following property definitions
are required here to ensure that all
          

             4: 
             the product common properties
are represented in the 
          

             5: 
             metadata. These are not returned
by the Commerce Server
          

             6: 
             metadata automatically as the
common properties.
          

             7: 
             -->
          

             8: 
            <
            Property
            name
            ="BaseCatalogName"
            dataType
            ="String"
            >
          

             9: 
            <
            DisplayName
            value
            ="Base
Catalog Name"
            />
          

             10: 
            </
            Property
            >
          

             11: 
            <
            Property
            name
            ="Rank"
            dataType
            ="String"
            />
          

That’s it! The response returned by the Foundation API should now have the actual Rank value returned for each child category entity:

Id=ThirdRankingCategory (String)
Rank=1 (Int32)
DisplayName=ThirdRankingCategory (String)

Id=AnotherRankingCategory (String)
Rank=2 (Int32)
DisplayName=AnotherRankingCategory (String)

Id=SomeRankingCategory (String)
Rank=3 (Int32)
DisplayName=SomeRankingCategory (String)

By default Microsoft Commerce Server 2007 is highly extensible for example in regards to extending the object model in the Order System (e.g. creating new classes or extending existing ones). Also the Profile System is properly the most extensible subsystem in Commerce Server being a general purpose data repository that allows the developer to define and store any custom data in it. While this is all great and good news, not everything on the Commerce Server platform is possible to extend and this post will focus on one specific lack of extensibility in regards to extending Payment Methods and Shipment Methods.

If you want to read more about Commerce Server 2007 seen from a developer and architect's point of view, I recommend reading my colleague Søren's "Developing with Commerce Server 2007"-series on his blog publicvoid.dk.

Requirements

In Denmark we have a national wide postal service called Post Danmark which we use as our carrier for sending letters, packages etc. This is defined in Commerce Server as one of the Shipment Methods on the specific customer solution I'm currently working on. Post Danmark also offers a service allowing the end-customer to postpone the actual payment of the order until the physical arrival. By having this option, we created a Payment Method in the system called "Post Danmark Efterkrav" ("Post Danmark Cash On Delivery"), so the customer can choose this in the checkout process. To be able to use this payment method we demand that the customer has already chosen Post Danmark as the shipment method. If the customer has chosen another shipment method we will not allow the customer to choose the cash on delivery payment method from Post Danmark, thus having the payment method depending on the chosen shipment method.

Management of Commerce Server Payment Methods and Shipment Methods takes place in the Customer and Orders Manager application. When creating a Payment Method it is possible to specify e.g. Payment Type (Credit Card Payment, Gift Certificate Payment, etc.). It is also possible to specify Name and Description of the Payment Method in the languages you want to support, plus a few more options. Unfortunately this is one of the areas in Commerce Server where you seemed to be locked by this model or behavior and you cannot do any obvious extending. Nonetheless we needed some way to do it, because we wanted to be able to specify a relation or dependency between Payment Methods and Shipment Methods. We wanted to make it possible to specify that a specific Payment Method should only be available when a specific Shipment Method was selected in the checkout process. And of course we wanted to accomplish this using as much Commerce Server standards as possible, so future service pack upgrades would not cause problems among other obvious reasons :-)

The solution

As mentioned earlier the Profile System in Commerce Server is our general purpose data repository where we can model almost anything and leverage from Commerce Server API's to do data access operations and provide security to our data store. The solution we came up with was to create two new profiles in the Profile System; one for payment method extended properties (PaymentMethodExtensionProfile) and another for shipment method extended properties (ShipmentMethodExtensionProfile) and link these profiles to the Shipment Method and the Payment Method types.

Shipped with Commerce Server comes a Software Development Kit, which among other very nice things contains the complete source code to all the business applications (except the Catalog and Inventory Schema Manager). There are two classes in the Customer and Orders Manager project responsible of displaying the dialogs for management of Payment Methods (PaymentMethodEditView) and Shipment Methods (ShippingMethodEditView) respectively. In each of these Windows Forms dialog classes, we added a new button in the toolbar, gave it an icon and named it "Extended Properties". When the user clicks on this button, we execute some code, that depending on whether it is executed from a Payment Method or Shipment Method basically just performs a search for a specific profile (our extended properties profile) specified by the unique id of for instance the Payment Method, and depending on whether the profile exist or not we open the standard profile management dialog in the right state (edit or new). If the profile does not exist, we initialize it with the unique id (our relation-key value). This is all done in a relatively few lines of code, where all we do is basically the same steps as a business user would manually do to either create a new profile or search for an existing one. All the code pieces for this is of course already in the solution, the hard part was just to find these exact pieces and assemble them to suit our requirements.

I have attached some screenshots below that shows how our feature is implemented in the Customer and Orders Manager application.

The figure above shows the list of payment methods in the system.

The figure above shows the new button we have added to the dialog, that, when the user clicks on the button, executes our custom logic that opens up the profile management dialog (either a new one, or an existing one), related to the payment method.

The figure above shows the actual profile which we use for extending the properties for a specific payment method in the system.

The figure above shows the actual relation between the payment method and the shipment method. The logical relation is established between the two extension profiles of the "Post Danmark" shipment method and the "Post Danmark Efterkrav" payment method.

Conclusion

The solution I have described here for extending Payment Method and Shipment Methods in Commerce Server 2007 works really good for us and we have added a lot of extended properties to both the Payment Method type (see screenshots supplied) and the Shipment Method type. Some of the functionality this provides is the ability to filter a specific shipment method to a specific country as well as filter a payment method based on the items added to the basket. Really cool and useful features and the best part of it: we are using standard Commerce Server all the way! :-)

Another very cool thing to mention is that when we had Max Akbar at Vertica to provide us some educational days of concentrated Commerce Server training, I gave him a demo of the feature, and his responses to it were really good.

If you have any questions or want me to elaborate more on this subject please don't hesitate to contact me in any way.

My first experience with Microsoft Commerce Server was in May 2007 when I started working at Vertica. At that point I had absolutely no clue of what Commerce Server could leverage as a standard eCommerce platform. The first few weeks basically went by doing training based on some internal training material and the documentation on MSDN for Commerce Server. Soon after that I became team member on a Commerce Server project for one of our customers. Since then my work has been more or less exclusively to this project which have been a incredible educational experience for me.

Moving on to my point it had been planned for some months that we should have Max Akbar, former Program Manager for the Microsoft Commerce Server Team, come to our company location in Aarhus and provide us some technical training on Commerce Server. At that time I had only read some of Max' posts about Commerce Server but honestly I did not knew much about who he was or what he had do with the Commerce Server product. But as I got to learn more about Commerce Server and began digging more and more into the technical aspects of the product, in purpose of extending and modifying it to our customer needs, Max' name and posts appeared more frequently on the web-sites I came along. Also he had posted some very useful articles on his blog that really helped me a lot doing the development. So it was very great news that he would come to our company, and I was really looking forward to meet him and none the less learn from him.

So this week we had Max coming all the way from California, USA to Aarhus, Denmark to spend a couple of days with us giving in-house training on the Commerce Server 2007 product. Although Max suffered a bit jetlag from his flight there were no way to tell it because he really pulled off some very intensive training and the level of expertise was just stunning! The experience and in-depth knowledge with the Commerce Server product was absolutely remarkable. I really enjoyed attending the course with Max and it fully lived up to my expectations - and then some.

This blog post doesn't cover all the topics that we went through the training with Max, but hopefully it gives a resume of what went on. The first day we got around talking about the installation, architecture and security stuff of Commerce Server as well as giving us some insight on some of the work he had been doing at Microsoft and some of the large scale enterprise solutions he have been a part of. It was very exciting to hear about all that. The second day we learned a lot about the CSS - Commerce Server Staging on how to easily deploy Commerce Server business data and content between different environments. It was very cool to learn about because the CSS part of Commerce Server is one thing that I have none on-hands experience with nor much knowledge about. We also got through the Catalog-, Profiles- and Marketing systems which gave me some very good insight on how this is implemented in the product and how to best interact with the systems. After the second day of training most of us from Vertica went out with Max to grap a beer on Kafé Komma and later we all went to eat on a really good restaurant. The third and last day of the training was primarily focused on integration, extending the Orders system and building custom pipelines.

For me it was really cool to show Max some of the stuff that I have been working on. Especially on how I have extended the Payment- and Shipping Methods using the standard Profile System and how I integrated this into the Customer and Orders Manager application with pretty much no modification to the application at all. I'm proud to say that Max found the stuff I did very cool. I might write a post about it some day.

Also pretty cool was that Max gave us some of the custom tools that he has developed for his various Commerce Server solutions and I'm absolutely sure that they will come in pretty handy in our solutions as well. Max is a really nice guy and besides all the training he did we also had a lot of fun during the training days. I'm really glad to met Max and hopefully I'll come across him again some day.

I'm sorry for any bad English, bad grammar or misspelling. The clock is getting pretty late and I'm not even done packing all my stuff yet. The thing is that we are all leaving very early in the morning (4.15 AM to be exact) as we are going with the train from Aarhus to the Copenhagen Airport from where we are flying to Edinburgh. Vertica has arranged a company trip throughout the weekend to Scotland which I'm really looking forward to.

The other day I wrote a blog post about a search problem in the Commerce Server Starter Site. I had added a new property to the propertiesToReturn element of web.config and that caused all search operations on the web-site to fail with the following exception from the database: 'Invalid column name 'Show_Variants_As_Products'.

In my efforts to solve the problem I stumbled across another issue when I tried to execute the "Refresh Catalog FullText Index" command on one of my catalogs in the Catalog Manager (screenshot provided).

This command executed without errors but when I tried to perform a new search on the web-site the database threw another exception with the following error message:

Full-text table or indexed view has more than one LCID among its full-text indexed columns.

This post helped me to the solution.

The solution

In SQL Server Management Studio I opened the Product Catalog database and found the table holding the products for the specific catalog I initially performed the Refresh command on. I changed  the "Language for Word Breaker" setting for the CategoryName column from 'English' back to 'Neutral'  in the properties Full Text Indexing (screenshot provided below).

dbo.[catalogname]_CatalogProducts > Full Text index > Properties > Columns > CategoryName=Neutral (from English)

Short explanation

When creating a new property definition which has the 'Assign to all products' attribute set to true and when this new property is added to the propertiesToReturn element in web.config (configuration/commerceSite/propertiesToReturn) search operations on the web-site can cause the following exception: Invalid column name '[property-name]'. This occurs if one or more of the catalogs in Commerce Server are out of sync with the catalog schema (defined in the Catalog And Inventory Schema Manager) e.g. if the catalog is empty.

Solution: Create a new dummy product in each catalog to ensure synchronization is done. You can safely delete the dummy product after creation.

Complete explanation

I had added the property 'Show_Variants_As_Products' in the Catalog And Inventory Schema Manager. The 'Assign to all products' attribute was set to true to ensure that all products in Commerce Server include this property.

Afterwards I added the new property to the propertiesToReturn string list in web.config:

<commerceSite
 requireSSL="false"
 enableExpressCheckout="false"
 persistAnonymousBaskets="false"
 rewriteProductUrls="true"
 assetLocation="~/"
 defaultShippingMethodId="87c0e40f-3661-4197-8f88-fa3f101ae1ad"
 propertiesToReturn="CategoryName, ProductID, CatalogName, i_ClassType, DisplayName, cy_list_price, VariantID,  Show_Variants_As_Products">

This setting ensures that the property is available in the returned DataSet when e.g. performing search operations on the web-site.

However when I tried to perform a search, the web-site crashed with the following exception coming from the SQL Server:

Invalid column name 'Show_Variants_As_Products'.

In the Catalog Manager I opened a random product in one of my catalogs to verify that the new property was actual present - and it was. So a bit confused I opened SQL Server Profiler to create a new trace to check the queries which was actually sent to the database from the web-site when performing a search.

The query sent to the database was:

exec dbo.ctlg_GetResults
 @Catalogs=N'MyCatalog1,MyCatalog2,MyCatalog3,',
 @Language=N'da-DK',
 @PropertiesToReturn=N '[CategoryName], [ProductID], [CatalogName], [i_ClassType], [DisplayName], [cy_list_price], [VariantID], [Show_Variants_As_Products], [BaseCatalogName],
 [oid], [OrigProductId], [OrigVariantId], [OrigCategoryName], [DefinitionName], [PrimaryParentCategory], [UseCategoryPricing]',
 @SQLClause=NULL,
 @FTSPhrase=N'perfume',
 @AdvancedFTSPhrase=NULL,
 @OrderBy=NULL,
 @StartingRec=1,
 @NumRecords=10,
 @SortAscending=1,
 @ClassType=10,
 @eJoinType=-1,
 @TargetTableName=N'',
 @SourceJoinKey=N'',
 @TargetJoinKey=N'',
 @RecordCount=@p16 output,
 @EnableInventory=1,
 @InventoryServerName=NULL,
 @InventoryDatabaseName=NULL,
 @FilterOutOfStockProducts=0,
 @FilterBackOrderableProducts=0,
 @FilterPreOrderableProducts=0,
 @UseThresholdAsFloor=1,
 @TreatmissingAsOutOfStock=0,
 @StockHandling=0,
 @InventoryPropertiesToReturn=N'*',
 @CategoryClause=NULL,
 @Recursive=0

When executing this query directly on database I got the same error message. I opened each of the catalog tables to verify that the new column 'Show_Variants_As_Products' was present. The column was present in the first two catalogs (MyCatalog1 and MyCatalog2) but in the last catalog (MyCatalog3) the column was not present indicating that this specific table was out of sync with the Catalog schema. The catalog was also in fact empty. So creating a new dummy product in MyCatalog3 using the Catalog Manager did the trick of getting the MyCatalog3 catalog table back in sync with the Catalog schema. I tested it with a new search operation on the web-site and everything returned successfully.