Content providers

A content provider connects an EPiServer CMS site to an external data source so that the data appears to be part of the EPiServer CMS website, even though the data resides at the data source. You can build more than one custom content provider, consolidating the data into one CMS and giving users an integrated user experience. A content provider operates in the following ways.

• 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 must inherit from ContentProvider configuration or registration of a content provider. Add a registered provider to web.config, or through IContentProviderManager.  

• 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; that is, the local pages and content served by the EPiServer CMS database also are delivered through a content provider: DefaultContentProvider.

• Enable/Disable Content Provider Functionality.

  To move content between content providers, special permissions must be switched on in Admin view > Permissions for functions: “Move between page providers”. A warning dialog box appears when you attempt to move pages between providers.

NOTE: You can display the data handled by the content provider only as EPiServer CMS EPiServer.Core.IContent instances.

You register and configure a content provider through EPiServer.Core.IContentProviderManager or in web.config; you must add this manually to web.config because there is no default content provider information. See also Configuring Content 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 you create a custom content provider, you must implement only one abstract method:

• LoadContent.

  Pulls out one specific content instance from the data store and returns it–an instance of an object that is implementing the IContent interface (such as PageData).

You can override and implement many ContentProvider methods to offer more functionality to the content provider. The following methods are several examples.

• LoadChildrenReferences.

  Returns the content references for the children to one specific node. You should implement LoadChildrenReferences if the provider is registered with an entry point and thereby displayed in page tree.

• ContentResolveResult ResolveContent(ContentReference).

  Supports permanent links from a ContentReference to a GUID and a Uri. If the passed-in identifier corresponds to an identifier for a content served by the content provider instance, then this method returns the internal ("classic") link to the content and the Guid-based identifier for the content. You can construct the URI by the ConstructContentUri(contentTypeId, contentLink, contentGuid) helper method, which maps to PageLink, PageGUID, and LinkUrl properties for a PageData instance.

• ContentResolveResult ResolveContent(Guid).

  Supports permanent links from a GUID to a ContentReference or Uri. If the passed-in identifier corresponds to an identifier for a content served by the content provider, then the implementation returns the internal ("classic") link to the content and set ContentReference identifier. You can constuct the URI by the ConstructContentUri(contentTypeId, contentLink, contentGuid) helper method, which maps to PageLink, PageGuid and LinkUrl properties for a PageData instance.