Introducing SerializableCart mode

This is good news! It would be good if there was support for adding custom columns to SerializableCart table, for efficient filtering. We tend to use custom fields a lot with MetaDataPlus. I guess a WHERE Data LIKE '%"CustomColumn": "@Value%"' would not a good idea ;-)

Is really the latest version of Quicksilver on Github updated with the serialized carts feature? The latest commit adds the feature SerializedCarts to ecf.app.config but it's not enabled.

I guess this feature is nice - at least in a performance perspective. Wouldn't it be more awesome if you could specify how to persist/read the cart? If you really cared about performance, you could store the serialized cart in Redis which surely would increase performance a lot.

This is not a suggestion to the writer of this blog, it's a suggestion to the Episerver team of course.

Thanks for your feedback guys!

Part of the motivation for introducing the order abstractions is to allow different implementations, not only for carts but also purchase orders and other order entities. However, rewriting the standard implementation isn't exactly trivial considering the need to be (somewhat) backwards compatible both with existing solutions and other parts of our own code, most notably Commerce Manager.

To rewrite the order system completely we would likely want to write out CM and replace it with a new GUI for order management, which is a big task. For that reason we decided to do a smaller scope story focused on the carts because this was where we were hurting the most (support for the new carts in CM is coming soon). Within this smaller scope we did not want to pull in a new dependency like Redis. While it is very simple to set up and use Redis in Azure, on-prem (and dev/test environments) is not trivial.

Considering the performance gain we could get with the current tech, we decided it wasn't worth the added complexity at this stage. That said, it is definitely a possibility that we will add a Redis backed implementation in the future. And with the abstractions it is already a possibility to roll your own, mind you will not have full support in Commerce Manager. But if the project does not require Commerce Manager you can even replace purchase order storage, IIRC this has already been done in some implementations.

Making custom columns queryable is an interesting challenge in this context. Adding that capability to the abstractions puts a lot more work on the implementer. We could maintain some kind of queryable index on the side but again that could mean pulling in another dependency (e.g. Find). We'll discuss it.

Quicksilver uses the order abstractions throughout so you just need to flip the flag to use the serialized carts feature.

It is on my to do list to have a Redis cart implementation.  Should not be hard now thanks to work with this story.

• IOrderGroupBuilder. Used to create sub-components for IOrderGroup. A builder is registered to create sub-components for a collection of type order group (see ForType property). A builder also has a SortOrder. If there are multiple registered builders for a type, the one with the highest sort order value is chosen.
• IOrderGroupFactory. Responsible for creating instances of order group components by using IOrderGroupBuilder. The default implementation automatically registers all builders for all types of IOrderGroup.

If I were to use Redis in production I would make sure to have an impersonation feature so my customer service reps could still manipulate carts on behalf of customer since this functionality would not work in commerce manager.  Purchase orders could still be managed in commerce manger since there would no changes to the implementation.  

In the long run would be nice to have an ui interface to manager orders from any implementation like our pricing and inventory systems.  I think is something that will get done, just not in the short term. 

See my question over at http://world.episerver.com/documentation/developer-guides/commerce/orders/serializable-carts/ - this should be answered in the documentation. Looks like awesome work so far, hoping I'm right in my theory there! :-)

Couple questions:

1. Is the same purchase order record that's created now when submitting an order created from this serialized cart?
2. When migrating existing carts to serialized carts, are the legacy order groups deleted?

Hi Todd,

Sory for very late reply.

1. Yes, it's the same purchase order record when placing a serializable cart.
2. Yes, legacy carts will be removed after the migration

Regards,