Note: This feature has been obsoleted in the latest version of the product.
This document describes how content providers are used in EPiServer Commerce. The content provider technology as a powerful integration method to extract content from different sources and make it available on a website, providing an integrated user experience.
In EPiServer Commerce, you can for instance make product catalog data available inside the EPiServer CMS Edit view. Editors can drag-and-drop product content into content areas of a page or a block. They can also edit and manage the catalog content through an interface that has the same look and feel, as well as similar interaction patterns, as the CMS Edit view.
Classes referred to here are available in the following namespaces:
Basic concepts
In EPiServer Commerce, the Content Provider builds the integration between the catalog system and EPiServer CMS. Basically, the ECF Catalog system consists of the following parts:
- Catalog, the biggest element in the Catalog system. Catalog can contain either NodeContent or EntryContent.
- NodeContent, can be the child of a Catalog or another CatalogNode, and can be the parent of CatalogEntries or other CatalogNode(s).
- EntryContent, must be the child of a Catalog or CatalogNode, and cannot be the parent of anything else. CatalogNode and CatalogEntry can only be moved/copied/linked within a Catalog.
To integrate the ECF Catalog system, the Commerce content root concept was introduced, which is the root content of whole catalog system in EPiServer CMS. The Commerce content root can include only Catalogs, no CatalogNode/CatalogEntry are allowed here.
The general idea is that you should use standard EPiServer API's to work with your commerce content in CMS. The provider will handle the mapping to/from ECF for you.
Load a product
C#
var contentLoader = ServiceLocator.Current.GetInstance<IContentLoader>();
var referenceConverter = ServiceLocator.Current.GetInstance<ReferenceConverter>();
var productIdFromCommerce = 1;
var productLink = referenceConverter.GetContentLink(productIdFromCommerce, CatalogContentType.CatalogEntry, 0);
var productContent = contentLoader.Get<CatalogContentBase>(productLink);
var productName = productContent.Name;
Get children of a category
C#
var contentLoader = ServiceLocator.Current.GetInstance<IContentLoader>();
var referenceConverter = ServiceLocator.Current.GetInstance<ReferenceConverter>();
var nodeIdFromCommerce = 1;
var productLink = referenceConverter.GetContentLink(nodeIdFromCommerce, CatalogContentType.CatalogNode, 0);
var children = contentLoader.GetChildren<CatalogContentBase>(productLink);
Determining the catalog content type
In the ECF catalog system, Catalog/Node/Entry are stored in different tables, which means they might end up having the same ID. To resolve this, the Commerce content provider reverses the two most significant bits (MSB) to determine which type of catalog content is being used.
When converting from a Commerce content ID to a content link, we add two more bits to the left of the ID. When converting from a content link back to a Commerce content ID, the two MSB:s are cleared out. The ReferenceConverter can be used to perform these actions.
C#
public void ConversionSampleCode(CatalogContentBase content)
{
var catalogContext = CatalogContext.Current;
var referenceConverter = ServiceLocator.Current.GetInstance<ReferenceConverter>();
if (content is EntryContentBase)
{
var entryId = referenceConverter.GetObjectId(content.ContentLink);
var entry = catalogContext.GetCatalogEntryDto(entryId,
new CatalogEntryResponseGroup(CatalogEntryResponseGroup.ResponseGroup.CatalogEntryFull));
var contentType = referenceConverter.GetContentType(content.ContentLink);
var contentLink = referenceConverter.GetContentLink(entryId, contentType, 0);
}
}
EntryContent can be one of four different subclasses depending on what kind of entry it is:
See also
Do you find this information helpful? Please log in to provide feedback.