Skip to main content

What's in your cart?

Let's say, you've added product A to your shopping cart. Then you get back to the product details page and add product A again. What's going to happen? You will still have one line in your cart, but the quantity of product A will be equal two. This is a standard behavior of B2C shopping carts, including the Sitecore Commerce 9 ones.

Now, imagine that your business processes require a bit more complicated scenarios, where you might want to actually create two lines in the cart, and avoid rolling them up into a single one. It is much more common than you might think. For example, you are buying two toasters of the same make and model, but you want only one of them gift-wrapped. Or you buy two pairs of glasses belonging to the same SKU, but you want to specify different prescriptions for them. Obviously, you do not want to roll them up under a single cart line.

What does Sitecore Experience Commerce 9 provide you with in order to handle such scenarios? Let's take a look at the developer documentation. The Commerce Connect documentation page for Cart Service Provider has the following:


Excellent! Sitecore's got you covered! You can use ForceNewLines attribute to control rolling up the cart lines at any time, on demand. So, you quickly implement and try using it with your standard Sitecore Experience Commerce 9 installation. What happened? Why do you still have a single cart line even with ForceNewLines=true? That's when you notice that little note in documentation, saying "This parameter is only supported if the external commerce system supports this functionality". Oh, c'mon, we're using Sitecore Commerce Engine - the most compatible system when it comes to Commerce Connect. It surely supports everything... Or is it?

OK, time to do the most common thing in your daily Sitecore Commerce developer routine: decompile Sitecore code. Even a quick look at the Sitecore.Commerce.Plugin.Carts.AddCartLineBlock reveals that none of its input CartLineArgument parameters are being used to control the lines rollup behavior. None. Great.

Frustrated, you look through the code again, and notice the following:


What is that? It actually is one of the Cart Policies, that can be located in the standard environment policy files. Just set it like this, and you're covered:


 Well, not exactly. You just switched your system from one mode to another. In order to control it on demand, you would need to write a pipeline block that recognizes the desired mode and dynamically sets RollupCartLinesPolicy in the CommerceContext. Placing it in front of the AddCartLineBlock would make the Commerce Engine great again a bit more flexible.

Comments

Popular posts from this blog

SharePoint 2013 and "search scopes"

While SharePoint 2013 introduced some undeniably handy features in the content discovery department, some of the old functionality has changed so much that you'll have to forget many of the design tricks that worked in 2007 and 2010.  One of such pain points is deprecating search scopes in SharePoint 2013. The requirement Let's start with a trivial situation. You have a requirement that states: "A user should be able to perform different types of search from any page/sub site on the portal by selecting a type of search and specifying keyword(s)". This would be considered an out-of-box functionality in 2007/2010: you just enable search scopes dropdown (considering the search box control is already in the master page), and define scopes. Piece of cake! Well, not so much in 2013.   The problem The thing is - there's no search scopes in SharePoint 2013. OK, to be exact - there's no user-definable search scopes, as we still have a couple of built-in

Navigation Settings in SharePoint 2013 Site Definitions

Who likes creating SharePoint site definitions from scratch? Well, it's not my favorite part of the SharePoint development either. An initially good idea of setting up your whole site through an XML file, received implementation and support far from being perfect. That quickly lead developers to look for alternative ways of defining and provisioning sites, primarily through the SharePoint API. A simple ONET.XML with beefy code-packed features became de-facto standard. What was supposed to be a template became compiled code. I was hoping SharePoint 2013 would at least attempt to do something about it… Tasked with creating a few publishing portal site definitions, I was unpleasantly surprised to find out that any attempt to use my new site definition to provision a site collection root results in both Global and Current Navigation switched to "Managed Navigation" mode, while I needed it to stay in the good old "Structural Navigation" one. This mode is new to Sh