Sergey's Point

We have a Sitecore Commerce 9.0.3 implementation where minions play a somewhat more significant role than they were probably initially designed for. They synchronize catalog with PIM , pricing with external price system, promotions with external marketing system, etc. One of the most important roles is pushing the queue of created orders to the fulfillment provider. Once the order volume passed the initial rate, the fulfillment provider started getting duplicate orders. This was somewhat random, and hard to catch. The duplicate orders would always be sent within less than a second from each other. The minion logs on our side would show no duplicate attempts to send anything, and the code itself made that impossible. To add to the mystery - rebooting the server would fix the issue but only until the next deployment. After much investigation and some lucky coincidence, we've found out the following: Authoring role would suddenly start running minions ; The minions in Authoring

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

I remember my first experience with .Net Framework and C# after years of MFC/COM/DCOM torture with lovely C++. Whoa, I don't have to track every reference and resource allocation? That GC thing rules! No more memory leaks! Right... Let's say, you're tasked with integrating Sitecore Commerce 9 and some PIM. It totally makes sense to use the Sitecore Commerce catalog system, so your integration would imply importing catalog structure and contents from PIM. While API capabilities of PIMs may vary, pretty much every type of PIM supports file exports of catalog. The native Sitecore Commerce catalog import/export is still in its infancy (no support for partial, incremental, or selective operations, not to mention lack of converters into its pretty unorthodox format, as well as inability to import product assets), so your only option is to build a custom catalog import plugin. The code for creating catalogs, categories and sellable items is relatively well-known and somewhat

Contrary to the popular belief, the Sitecore Commerce Experience Accelerator (CXA) is much more than just a set of the commerce-related SXA elements with a reference storefront. Even if your newly created Sitecore Commerce 9 storefront is not going to be SXA-compatible, it makes sense to re-use parts of the CXA features and foundation, as they conveniently encapsulate complexity of the raw Commerce Connect. Since CXA was initially created with the default storefront experience in mind, it still has quite a few quirks that one would not expect to see in a true production-ready framework. One of the most notorious "features" is the default toaster image. Even if you are using a completely custom catalog, while extending the  Sitecore.Commerce.XA.Feature.Catalog feature, product images default to a toaster image. Moreover, if the Commerce Connect chokes while generating catalog templates, and "forgets" to create the Images attribute (the infamous "first produ