Getting Order Index to update on CM box, in a multi-box Sitecore Commerce setup

Question

So we have a common setup of Sitecore Commerce running.

• 2 CD servers
• 1 CM server

All of these run the Commerce Authoring services locally (all of the above are pretty much configured identically), pointing to a shared database cluster behind the scenes.

And the problem is this.

During the day, orders will tick in on CD1 and CD2 and go through with no issue. However, the Order Management interface never picks up on this - we have to go manually rebuild the orders index whenever we want to see what new orders have arrived. The reason is half-obvious, the event of creating a new order is somehow not propagated to the other servers in this little family. The question is why not, and how should we configure this?

I've checked the following:

• ScalabilitySettings is enabled as one would require, in this type of setup
• I see log entries on CD1 and CD2 when orders come in, for "updating order index". So the individual CDs get their indexes updated. This doesn't help our client however, who naturally only works on the CM box.

So I'm guessing there's something more to it, when it comes to Commerce. What am I missing here?

Answer 1

Orders indexing enables searching order information, including when an order is created or updated. This index is used by the search function in the Customer and Order Manager business tool. The Orders search index is named commerce_orders_index . Its crawler and strategy are defined in the Sitecore Commerce Engine Connect component. Every time an order is created or updated, the Commerce Engine updates the data in the OrdersIndex list, which causes the index to be updated.

The configuration for the index crawler is located in the following files, for Lucene or Solr:

Sitecore.Commerce.Engine.Connectors.Index.Lucene.config
Sitecore.Commerce.Engine.Connectors.Index.Solr.config

The configuration for the Orders index strategy is located in file:

Sitecore.Commerce.Engine.Connectors.Orders.config

By default, the index is set to be run every ten minutes.

Index fields:

• orderid : the order ID.
• orderconfirmationid : the order confirmation ID.
• orderdate : the date the order was created.
• orderpaymentstatus : the payment status of the order.
• status : the status of the order.
• email : the email of the order customer.
• customerid : the id of the order customer.
• environment : the environment where the order was created.

See documentation

Also Sitecore Support strongly recommended to use Solr instead of Lucene.

How you can setting up Solr, you can find here

Answer 2

Problem found and isolated to Lucene index

So I finally managed to track this one down. It is related to the fact that we run on Lucene indexes so if you're running the recommended SOLR configuration, this problem will not affect you.

The problem lies in OrdersIntervalAsynchronousStrategy which was defined and deployed to all our instances, CM, CD1 and CD2.

What this strategy does, in simple terms, is this:

• Get a list of orders to index. This list is pulled from Content Authoring
• Index these orders
• Remove these orders from the list

As witnessed by this code:

...
    ManagedList ordersToIndex = IndexUtility.GetOrdersToIndex(environment, this.IndexListName, 0, this.ItemsToTake);
...
    IndexCustodian.IncrementalUpdate(this.Index, (IEnumerable<IIndexableUniqueId>) list1.Select<Order, IndexableUniqueId<CommerceOrderIndexableItem>>((Func<Order, IndexableUniqueId<CommerceOrderIndexableItem>>) (order => new IndexableUniqueId<CommerceOrderIndexableItem>(this.TranslateOrder(order, artifactId)))).ToList<IndexableUniqueId<CommerceOrderIndexableItem>>());
...
    IndexUtility.ClearIndex(environment, this.IndexListName, ordersToIndex.Items.Select<CommerceEntity, string>((Func<CommerceEntity, string>) (item => item.Id)).ToList<string>());

And what was happening was; that since this ran on all instances - a CD server would (sometimes) pick up an order and add it to the index BEFORE the CM server saw the order. And since the strategy REMOVES the order from the list of orders to be indexed - CM would never see it.

What made this extra hard to debug was the fact that, in all cases we had - the log files would throw us off course. CD2 would get an order, and nothing in the logs would tell us why it would not get indexed. Turned out, CD1 picked it up just minutes before CM would have seen it.

The fix

To get around this, the index strategy has been disabled on the CD servers of the environment. As far as I can tell, this index serves no purpose on CD. If this turns out to be a problem, a version of the strategy WITHOUT the list removal will need to be written, and deployed for CD servers.

I modified Y.Commerce.Engine\Sitecore.Commerce.Engine.Connectors.Index.Lucene.config on CD1 and CD2 and commented out this:

<!-- This cannot be allowed to run on CD servers. It basically picks up new orders to be indexed and indexes them, then removes them from the list of new orders. 
      Since we run Lucene, this means the CM server never sees these orders and gets them indexed locally -->
<!--<strategies hint="list:AddStrategy">
  <strategy ref="contentSearch/indexConfigurations/indexUpdateStrategies/ordersIntervalAsynchronousStrategy" />
</strategies>-->

Effectively disabling the order index strategy on CD servers. Orders are now being picked up on CM servers as expected.

I believe this to be a bug, since "strongly recommend SOLR" and "not supporting Lucene" is not one and the same ;-)