Category: Commerce

EntryContentBase, MetaObject, CatalogEntryDto, Entry: which should you use?

It can be pretty confusing for new Commerce developers to understand how to work effectively with entries in Commerce. There are many things which represent the same concepts, however they are different and their APIs are not compatible. So which is which and what should you use?

Which is which

    • CatalogEntryDto is the DataSet to represent one or more entries (CatalogEntryDto can of course be empty). Beside the basic information like Name, Code, or MetaClassId, depends on how did you load it, a CatalogEntryDto can contain information about the assets, the associations or the variations (you can specify what to load by using CatalogEntryResponseGroup parameter. CatalogEntryDto, however, does not contain information of the metadata system of an entry – for example, if you add a metafield named “Description” to your entry metaclass – that is not available in a CatalogEntryDto.
      CatalogEntryDto can be loaded or saved by ICatalogSystem methods.

    Continue reading “EntryContentBase, MetaObject, CatalogEntryDto, Entry: which should you use?” →

    Catalog Search APIs are for editing only!

    If you are using Catalog Search APIs for any customer-facing features, you are doing it wrong!

    I have seen this problem a couple of times – the search feature on the site is “dead” – it is very slow, and the log file is usually filled with dead lock or timeout error. As it turns out, the search feature was implemented by Catalog Search APIs, which is a big no-no.

    To be clear, there are two builtin APIs related to searching in Episerver Commerce: the “fast” one, which can be done via SearchManager, ISearchCriteria and ISearchResults, is the SearchProvider APIs. It’s the indexed search (strictly speaking, you can make it not “indexed”, but that’s beside the point), and the actual search functions will be provided by providers, like LuceneSearchProvider, Solr35SearchProvider, or FindSearchProvider.

    Continue reading “Catalog Search APIs are for editing only!” →

    Episerver Commerce CustomerContact Events

    This post was inspired by this question: http://world.episerver.com/forum/developer-forum/Episerver-Commerce/Thread-Container/2016/9/commerce-manager-contacts-events/

    and is an excerpt from my book: https://leanpub.com/proepiservercommerce

    You might notice the lacking of events in some parts of the system. We have events for catalog system, for order system, for prices and inventories changes, but that’s not enough. You might want to have events – or at least – the ability to know when something happens. For example, when a customer contact is changed, or edited, or deleted, it would be very nice to do some extra actions.
    Sending emails, updating external systems, etc.

    Such events are not available out-of-box, so we have to implement our own. How? We don’t have ICustomerContactService (or something similiar) interface where we can write our implementation to replace the default service (and even if there is, it would be a big task to do so). So there’s no “ordinary”, framework-way to do that. However, CustomerContact is built on Business Foundation system, and BF, at its core, is all above extensible and pluggable. We don’t have ICustomerContactService interface, but we have IPlugin
    who can do the same, and even more. As we learned in previous chapter, CustomerContact is just another EntityObject and all operations are still done via BusinessManager.Execute(Request) – even we have some nice wrapper methods to make working with it easier. And when Execute(Request) is called, it also runs all registered IPlugin modules.
    Continue reading “Episerver Commerce CustomerContact Events” →

    The hidden danger of dot (Or why should your metafield not contain . in the name)

    A dot (.) – it is harmless. What harm can it do, it looks pretty innocent.

    And yet it can break your Catalog UI.

    Psyduck, from Pokemon Go
    A dot can look pretty harmless and innocent, just like a Psyduck. Frankly, its eyes are also two dots.

    Catalog UI relies on the Shell UI from CMS to render properties and such. Shell UI, in its hands, needs to know about the metadata of the properties. When you have dot in the metafield names, the MetaDataPropertyMapper will create an Property with that name on site start up. And then when you open All properties mode, Shell UI will request your content type models, and CMS Core will happily return those properties.

    Continue reading “The hidden danger of dot (Or why should your metafield not contain . in the name)” →

    How to check if a coupon was successfully applied

    When a customer add a coupon to his/her cart, it’s nice and best practice to show to him/her if the coupon has been applied successfully, or if it was an invalid/not applicable code.

    Coupon has been applied successfully
    Coupon has been applied successfully

    How can you do that?

    In old promotion system

    When old promotion system run, each successfully applied promotion will be presented by an instance of Discount, which has a property named DiscountCode – this is the coupon used for the promotion (it can of course be null if the promotion requires no coupon).

    Continue reading “How to check if a coupon was successfully applied” →

    The beauty of new promotion system

    This is going to be a relatively short post. If you are using Episerver Commerce 9, you probably know that we are working on a new promotion system. It’s still BETA, but some of our customers already use it, and from what I heard they are really happy with it.

    One of the reasons we create a new promotion system is the old one is not developer-friendly. Have you ever tried to create a promotion in old system, by code?

    This is an “simple” example of how to create a new campaign and a couple of promotions:
    Continue reading “The beauty of new promotion system” →

    Episerver Commerce MetaDictionary internals

    This is an excerpt from my book – Pro Episerver Commerce – which is now already 2/3 complete.

    Dictionary types.

    Previously we discussed on how properties work with catalog content. However – if you have dictionary types in your MetaClasses, they will work differently. In this section we will examine these special data types – this applies to Order system metaclasses as well.

    As we all know – there are three types of dictionary in Episerver Commerce:

    • Single value dictionary: editor can select a value from defined ones.
    In Commerce Manager, you can create new metafield with type of Dictionary, but without "Multiline" option
    In Commerce Manager, you can create new metafield with type of Dictionary, but without “Multiline” option

    Single value dictionary type is supported in the strongly typed content types – you’ll need to define a property of type string, with backing type of typeof(PropertyDictionarySingle)

     [BackingType(typeof(PropertyDictionarySingle))]
 public virtual string Color { get; set; }
    • Multi value Dictionary: editor can select multiple values from defined ones. The only different from Single value dictionary is it has the “Multiline” option enabled.

    Continue reading “Episerver Commerce MetaDictionary internals” →

    Quicksilver – ServiceApi: fixing issues

    From what I heard, developers seem to love both QuickSilver – as a template – and ServiceApi – as a REST server – very much. Despite of being relatively new on the field, they are being used quite frequently – QuickSilver is the preferred choice for MVC template while many sites are using ServiceApi to update the catalogs. What’s about the combination of these two? Would it be the best-of-bread for Episerver Commerce. I would say yes, but after you have fixed the issue.

    The installation of ServiceApi.Commerce package to Quicksilver site should be easy and painless. Update the database and build the project, you should be expecting to have a working site.

    Not quite. You should be seeing this error:

    A route named 'MS_attributerouteWebApi' is already in the route collection. Route names must be unique.
Parameter name: name

    It’s because

    MapHttpAttributeRoutes

    is called twice (as it’s called in ServiceApi as well). So naturally, let’s try by commenting that line in SiteInitalization.cs, and build it again.

    This can also be solved by adding this into appSettings:
    "episerver:serviceapi:maphttpattributeroutes"

    Which will signal ServiceAPI to skip calling

    MapHttpAttributeRoutes

    A new error would show up:

    Continue reading “Quicksilver – ServiceApi: fixing issues” →

    Never send me my password

    I’m not a security expert myself, not even close, but for more than once, I’ve been greatly concerned about the risks for having accounts in several websites. I wonder myself why did the developers there go with the decisions that bad.

    It’s already bad enough to use HTTP on your register/login page . It’s even worse when you send me my password in plain text. Either the one I chose or the one you randomly generated for me.

    Oh please, I know what my password is
    Oh please, I know what my password is

    And this has happened more than once. Each time, it raises my eyebrows higher and higher. I don’t want to rant here – but it takes great deal of ignorance or laziness, or both, do do such as bad practice about securities.
    Continue reading “Never send me my password” →