Extending Content Delivery Storage in SDL Tridion 2011
This tutorial guides you through extending the new Content Delivery Storage Layer with Tridion 2011.
I was recently asked to perform a search integration where Tridion would publish content into a Search Indexer. Part of this integration consists in taking the published content and store it into a relational DB. The indexer would then pick it up from this DB and push it into the Indexer.
The tutorial below describes extending the Content Delivery Storage, such that a new storage type is created that uses a new storage media (another relational DB). The API to use is described on the SDL Live Content website (http://sdllivecontent.sdl.com/LiveContent), under section Implementing Content Distribution > Implementing Content Distribution on a Presentation Server > Storing content in the Content Data Store > Extending the Storage Layer. However, this tutorial gives a step-by-step description and in the end provides a fully working storage extension.
Part 1: The Concepts
Part 2: The Code
Part 3: Configuration and Testing
We want to have a new storage type that can interact with a new Database. This new type would be built on top of the JPA Storage framework that comes with Tridion Content Delivery 2011.
Following the JPA framework we will need to provide three classes:
Java Entity Bean � the object containing the actual data we are trafficking between the database and the actual application
DAO (Data Access Object) interface � the contract about which operations we are allowed to perform on the database with an Entity Bean
JPA DAO implementation class � the actual class implementing the DAO interface methods, which performs the database interaction
The entire model-above uses the Hibernate / JPA approach that Tridion Content Delivery 2011 uses. We are merely piggy-backing on top of this mechanism. This helps us in re-using the configurations defined by Tridion CD, such as storage configurations, Hibernate configuration, interfacing with JPA, DB, etc...
Our storage extension will use a new DB to store the new content type in. We will call new storage type "PublishAction" because it would record publish/unpublish actions to the new DB table. For simplicity reasons, the DB would use only one table called PUBLISH_ACTIONS with the following columns:
For SQL Server, column ID is defined as IDENTITY(1,1), so it increments automatically by one, without us having to specify value.
For Oracle, column ID needs to be defined using a Sequence (that generates the values), like this:
CREATE SEQUENCE SEQ_PUBLISH_ACTIONS MAXVALUE 999999999999999 CYCLE START WITH 1
CREATE OR REPLACE TRIGGER PUBLISH_ACTIONS_KEY
BEFORE INSERT ON PUBLISH_ACTIONS
FOR EACH ROW
IF :new.ID IS NULL THEN
SELECT SEQ_PUBLISH_ACTIONS.NEXTVAL INTO :new.ID FROM DUAL;
Note: We are going to use the Sequence SEQ_PUBLISH_ACTIONS later in the code. Remember this name!
Move on to
Part 2: The Code