Content providers

The content provider technology is one way of integrating information into an EPiServer CMS website. You can use EPiServer Custom Content Providers for the management of information from a site. This is a way of getting access to data in the Web solution without moving the data into EPiServer CMS. By building one or more Custom Content Providers, you can consolidate all data in one CMS. Users will have an integrated user experience and all the “normal” EPiServer CMS functions will work both for editors and developers.

The content provider acts as an intermediary connecting an EPiServer CMS site to an external data source. All the data appears as part of the EPiServer CMS website, though in fact the data resides at the data source. The data handled by the content provider can be displayed as EPiServer CMS EPiServer.Core.IContent instances only.

A sample content provider XMLContentProvider is shipped with EPiServer CMS, to be used as inspiration to developers when creating custom content providers.

Content providers are registered/configured in web.config or through EPiServer.Core.IContentProviderManager. Since there is no default content provider information in the web.config, you need to add this information manually. Concerning the capabilities a content provider instance can support, see Configuring Content Providers.

• Data resides in original store. The data is not stored in the local EPiServer CMS website database, the data source is integrated with EPiServer CMS.
• Requires coding and configuration. Registered content providers need to inherit from ContentProvider configuration/registration of a content provider shall be added to the web.config or registered through IContentProviderManager.
• Sample page provider available. You can download the XmlContentProvider sample page provider for EPiServer CMS.
• IContent only. The information/data from a content provider appears as EPiServer CMS content only.
• DefaultContentProvider technology. EPiServer CMS uses the content provider concept internally as well, that is the local pages/content served by the EPiServer CMS database is also delivered through a content provider: DefaultContentProvider. The sample XMLContentProvider is a custom content provider.
• Enable/Disable Content Provider Functionality. In order to be able to move content between content providers special permissions must be switched on in Admin mode: Permissions for functions: “Move between page providers”. A warning dialog is displayed as an extra precaution when attempting to move pages between providers.

Custom content providers and the ContentProvider class

Each content provider that is registered with EPiServer CMS must inherit from the ContentProvider class that resides in the EPiServer.dll assembly. When creating custom content providers there is only one abstract method that is required to be implemented:

• LoadContent. What is used to pull out one specific content instance from the data store and return it – an instance of an object that is implementing the IContent interface (for example PageData).

There are alot of additional methods in ContentProvider class that can be overridden and implemented to offer more functionality to the content provider. Below are some example on methods:

• LoadChildrenReferences. Only passing back the content references for all the children to one specific node. This should be implemented if provider is registered with an entry point and thereby displayed in page tree.
• ContentResolveResult ResolveContent(ContentReference). Needs to be implemented to support permanent links. From a ContentReference to a GUID and a Uri. If the passed in identifier corresponds with an identifier for a content served by the content provider instance then this method should return the internal ("classic" link to the content and the Guid based identifier for the content. The URI can be constructed by helper method ConstructContentUri(contentTypeId, contentLink, contentGuid). This maps to PageLink, PageGUID and LinkUrl properties for a PageData instance.
• ContentResolveResult ResolveContent(Guid). Needs to be implemented to support permanent links. From a GUID to a ContentReference/Uri. If the passed in identifier corresponds with an identifier for a content served by the content provider then the implementation should return the internal ("classic") link to the content and set ContentReference identifier. The URI can be constructed by helper method ConstructContentUri(contentTypeId, contentLink, contentGuid). This typically maps to PageLink, PageGuid and LinkUrl properties for a PageData instance.

Integrating the XMLContentProvider

This section describes how you can add the XMLContentProvider to an EPiServer CMS website, you only need to perform a few simple steps in order get the content provider working in the solution. Here with have used the XMLContentProvider as an example:

Step 1: Create a content provider entry point. Insert a content provider node in the site’s page tree (an empty page), an entry point for the content provider. Note the Page ID which shall be the entry point value in the page provider configuration.

Step 2: Add the SampleContentProviders Assembly to the solution. Add the assembly SampleContentProviders.dll to the projects references.

Step 3: Add the data source. You can download the externalpages.xml file, which is prepared as the data storage for this demonstration. The path and file name for the data file is stored in the attribute filePath in the path provider configuration in the web.config file.

Step 4: Add the configuration to web.config. See Configuring Content Providers.

Using the content provider

Now you can access and manipulate the information in the content provider node in EPiServer CMS. Which actions can be carried out on the content provider node is defined by the capabilities attribute in the configuration. Be careful when moving pages between one page provider to another – when the information is moved into another page provider it is deleted from the old page provider permanently.