Designing an Ektron Content Delivery and Provider Mechanism (Part 1)

As your designing your Ekron Content Management System (CMS) you need to design the level of interaction your enterprise will have with the CMS.

From the design of Ektron you can see it prefers to be the center of your offering. Most of the controls, pages, API and other components are geared towards building a site. In that regard, it seems to be competent.

For the project I am currently working on, the idea is something very different. It's to use Ektron for management of the content, with the idea of pushing (or pulling) content from this system to be consumed by a host of other sites (and potentially applications).

In some regards, Ektron is not designed to do this type of work. The out-of-the-box offering for exporting content supports PDF, and a synronization utility integrated with the product called ESync is designed to move content through the environments, and for content generation. Their marketing literature describes ESync as: "Automate the secure provisioning of web content, code, assets, and templates from development through production. Deploy only the necessary changes, from a single content update to an entire site, speeding time to Web and eliminating site downtime.".

Based upon Ektron's functionality and the desire to use it as a content repository there is a need to:
1. Design a way to generic render XML (SmartForm) content into Html, Text, Csv
2. Design a way to extract content information (SmartForm) into Xml, JSon
3. Design a way to extract html (or Ektron rendered content) in it's native format
4. Develop an Intermediate/Proxy API capable of extracting content on demand, providing caching of that content at the destination, and providing the content when requested.
5.

These deliverables combined with Ektron as a system itself (including the best practices documentation) generated these additional constraints or parameters:
1. The content delivery and provider mechanism should not interact directly with Ektron's data-storage.
2. The system should rely heavily on using the Ektron website for content extraction, and avoid direct interaction with the database, or Ektron APIs where possible.
3. The delivery mechanism should be extremely flexible and should scale with demand.
4. Any development should wrap Ektron, and not involve changing the core application or product.
5. The strategy support upgrading Ektron at any time.

In order to achieve the deliverables and system requirements, I designed a series of extraction templates (to be included within the Ektron site), and an API for use by these templates, and for extraction of the content (in it's various forms).

This is the high-level design:

Each of the sites consuming the content access Ektron's information via the API, and then store the content within one of the caching mechanisms (file/IO, HttpContext caching, RavenDB) and retrieve any missing content on demand.

Since the API capable of retrieving, caching and filtering content it supports on-demand requests, pull-requests from sites. The next goal is to add content-push from Ektron into the caching mechanisms (proactively staging updated content for the sites to consume).

In my next post:
1. Designing Data Templates for Content Extraction with Ektron (JSon, XML)
2. Designing a Generic Meta-Data Driven Transformation Template with Ekron

References:
Ektron
ESync