Working with the catalog as IContent

Introduction

This document describes how to work with catalog content using the same techniques as working with CMS content.

Accessing catalog content as IContent

EPiServer Commerce provides a content provider that can serve any catalog content as IContent. That means that you can use an IContentRepository to work with the content the same way you do in EPiServer CMS.

public ContentReference CreateNewSku(ContentReference linkToParentNode)
{
    var contentRepository = ServiceLocator.Current.GetInstance<IContentRepository>();
    //Create a new instance of CatalogContentTypeSample that will be a child to the specified parentNode.
    var newSku = contentRepository.GetDefault<CatalogContentTypeSample>(linkToParentNode);
    //Set some required properties.
    newSku.Code = "MyNewCode";
    newSku.SeoUri = "NewSku.aspx";
    //Set the description
    newSku.Description = "This new SKU is great";
    //Publish the new content and return its ContentReference.
    return contentRepository.Save(newSku, SaveAction.Publish, AccessLevel.NoAccess);
}

For more detailed information regarding how to work with IContent, see the CMS documentation.

For information on how to display your Commerce Content, see the Using a CMS-style rendering template article.

Content model

To get the full feature set you need to connect a content type to the meta class. That is done by creating a model class that inherits from the appropriate type in the EPiServer.Commerce.Catalog.ContentTypes namespace and decorate it with the CatalogContentTypeAttribute attribute.

using EPiServer.Commerce.Catalog.ContentTypes;
using EPiServer.Commerce.Catalog.DataAnnotations;
using EPiServer.Core;
using EPiServer.DataAnnotations;

namespace CodeSamples.EPiServer.Commerce.Catalog.Provider
{
    [CatalogContentType]
    public class CatalogContentTypeSample : VariationContent
    {
        [CultureSpecific]
        [Tokenize]
        [Encrypted]
        [UseInComparison]
        [IncludeValuesInSearchResults]
        [IncludeInDefaultSearch]
        [SortableInSearchResults]
        public virtual string Description { get; set; }

        public virtual int Size { get; set; }

        [DecimalSettings(18, 0)]
        public virtual decimal Discount { get; set; }
    }
}

The following types are available when creating Commerce models.

Type name	Description
VariationContent	A type for variant(variation)/SKU models.
ProductContent	A type for product models.
BundleContent	A type for bundle models.
PackageContent	A type for package models.
NodeContent	A type for category/node models.

There are a few types that you should not inherit from as they only exist to show various states in the system. They are the following types:

Type name	Description
CatalogContent	A type for catalog models.
EntryContentBase	A base type for VariationContent, ProductContent, BundleContent, PackageContent and DynamicPackageContent.
NodeContentBase	A base type for NodeContent and CatalogContent.
RootContent	The virtual root in EPiServers hierarchical representation of Commerce content.

During the synchronization process, specific CLR types will generate meta fields of a specific meta data plus type. You can modify the default mapping by using the BackingTypeAttribute, or creating the property manually in Commerce Manager before adding the code. Below you can find the mappings for all supported types:

CLR Type	Meta Data Plus Type
Byte	Integer (SmallInt, TinyInt and Int are also supported)
Int16	Integer (SmallInt, TinyInt and Int are also supported)
Int32	Integer (SmallInt, TinyInt and Int are also supported)
Int64	Integer (SmallInt, TinyInt and Int are also supported)
Double	Float
Single	Float
Float	Float
Decimal	Decimal
String	LongString (ShortString and Text are also supported)
Boolean	Boolean
DateTime	DateTime (Date and SmallDateTime are also supported)
Url	Url
XhtmlString	LongHtmlString
ContentReference	ShortString
PageReference	ShortString

Commerce-specific attributes

Any attribute you can use in CMS you can also use in your Commerce content type models. For more detailed information regarding the different attributes, refer to the SDK/Developer Guide for CMS. Look under the Developer Guides Pages and Blocks section and find the Attributes article.

There are a few Commerce-specific attributes you can decorate your model with:

• CatalogContentType attribute
• Encrypted attribute
• UseInComparison attribute
• IncludeInDefaultSearch attribute
• IncludeValuesInSearchResults attribute
• SortableInSearchResults attribute
• Tokenize attribute
• DecimalSettings attribute

CatalogContentType attribute

If you want to connect the content type to an existing meta class, the CatalogContentTypeAttribute can be used. You connect them by defining the name of the meta class that should be connected to the content type.

using EPiServer.Commerce.Catalog.ContentTypes;
using EPiServer.Commerce.Catalog.DataAnnotations;

namespace CodeSamples.EPiServer.Commerce.Catalog.Provider
{
    [CatalogContentType(MetaClassName = "WineSKU")]
    public class CatalogContentTypeAttributeSample : VariationContent
    {
    }
}

Encrypted attribute

Use this attribute to declare a property to have "Use Encryption" enabled. This will encrypt the value when stored in MetaData plus.

UseInComparison attribute

Use this attribute to declare a property to be used for comparison.

IncludeInDefaultSearch attribute

Use this attribute to declare a property to include the value in default search results. This will be used by the search provider system.

IncludeValuesInSearchResults attribute

Use this attribute to declare a property to be included in the search results. This will be used by the search provider system.

SortableInSearchResults attribute

Use this attribute to declare a property to be flagged as index sortable. This will be used by the search provider system.

Tokenize attribute

Use this attribute to declare a property to be tokenized (word breaking).

DecimalSettings attribute

Use this attribute to declare a property to have precision and scale.

Commerce-specific types

Certain types that can be represented in Meta Data Plus are not directly mapped to a CLR type. Properties that will be backed by meta fields of these Meta Data types need to be specified further than simply by the return type. The table below lists such Meta Data types and the additional requirements.

Meta Data Plus Type	CLR Type	Additional Requirements
Dictionary [New in 7.7]	string	Decorated with [BackingType(typeof(PropertyDictionarySingle))]
Dictionary, multiline [New in 7.7]	ItemCollection<string>	Decorated with [BackingType(typeof(PropertyDictionaryMultiple))]

Limitations in synchronization

The synchronization of catalog models works the same way as with content types in CMS, except that the data will be backed in Meta Data Plus. However, there are some limitations due to technical differences. The following will not be done automatically, but will require manual steps:

• Change the type of a property. Will cause an exception.
• Rename a model class. Unless specified by the CatalogContentTypeAttribute, a new meta class will be added, but the old one will be left in the system.
• Rename a property. Will add a new meta field, but the old one will be left in the system.
• Remove a property.

Different properties with the same name has to have identical definition. This means that you cannot have aproperty called "Description" on two different classes and make it culture specific on one, but not the other. The reason for that is that in Meta Data Plus meta fields are shared across meta classes. Hence, they can only have one definition. For more detailed information regarding the synchronization in CMS, refer to the SDK/Developer Guide for CMS.