Content Delivery use case

Presents a basic use case scenario (Content Delivery project) and describes its implementation

Chapter 7 Advanced topics

Covers a number of advanced topics that are not part of a standard Content Delivery implementation

Version history

This version history list outlines the changes to the Content Delivery Project Planning Guide 5.3 SP1 since it was last released.

Product version Document number Changes

5.3 R5_CDPPG_10 New release and book.

5.3 SP1 R5_CDPPG_11 Minor changes, version number updated.

Content Delivery Project Planning Guide 5.3 SP1

Chapter 1 Content Delivery ... 1

1.1 Content Delivery concepts ... 1

1.2 Implementation plan ... 2

1.3 Licensing ... 2

Chapter 2 Implementing Content Distribution ... 5

2.1 Content Distribution concepts ... 5

2.2 Content Distribution implementation decisions ... 6

2.2.a Choosing the Web Application Server technology ... 7

2.2.b Choosing a type of data store ... 7

2.2.c Choosing a transfer protocol ... 7

2.2.d Customizing content deployment ... 8

2.2.e Configuring where to store incoming content ... 9

2.2.f Caching incoming content ... 11

2.3 Content Distribution implementation plan ... 12

Chapter 3 Developing the Web site ... 13

3.1 Web site development concepts ... 13

3.1.a Content Manager items and Web site items ... 13

3.1.b Web site models ... 14

3.1.c Linking ... 15

3.2 Web site development decisions ... 15

3.2.a Choosing a scripting language ... 16

3.2.b Choosing a Web site model ... 16

3.2.c Dynamic navigation ... 18

3.2.d Integrating search ... 18

3.3 Web site development implementation plan ... 19

3.3.a Organizing content for navigation ... 20

3.3.b Integrating search ... 20

3.3.c Writing queries for Dynamic Content Assembly ... 21

3.3.d Implementing Linking ... 22

Content Delivery Project Planning Guide 5.3 SP1

Chapter 4 Implementing dynamic functionality ... 25

4.1 Implementing search ... 25

4.2 Implementing Dynamic Component Presentations ... 26

4.3 Implementing Dynamic Linking ... 27

4.4 Implementing dynamic navigation ... 27

4.5 Dynamic Content Assembly ... 28

Chapter 5 Profiling and personalization ... 31

5.1 Profiling and personalization concepts ... 31

5.2 Profiling and personalization implementation decisions ... 32

5.2.a Choosing to implement Tracking ... 32

5.2.b Choosing to implement Tracking Keys ... 33

5.2.c Choosing to implement personalization ... 33

5.3 Profiling and personalization implementation plan ... 33

5.3.a Implementing Tracking and Tracking Keys ... 34

5.3.b Implementing personalization ... 34

Chapter 6 Content Delivery use case ... 37

6.1 Project definition and constraints ... 37

6.2 Setting up transport ... 38

6.3 Implementing dynamic functionality ... 39

6.4 Setting up the infrastructure ... 40

Chapter 1 Content Delivery

Content Delivery is the process of getting content out of the Content Manager and presenting it to a Web site visitor.

1.1 Content Delivery concepts

Content Delivery consists of three parts:

• Content Distribution

• Dynamic Publishing

• Profiling and Personalization

Content Distribution

Content Distribution refers to the transportation of content from the Content Manager, where content is created and maintained, to the Presentation Server, where content is stored and presented.

Dynamic Publishing

Dynamic Publishing refers to the implementation of functionality that require scripting on the Presentation Server, such as:

• search functionality

• automatic navigation

• dynamically assembled content

• dynamically resolved hyperlinks

You can choose to implement all, some or none of this functionality, depending on what kind of Web site you would like to build.

Profiling and Personalization

Chapter 1 Content Delivery

Profiling and Personalization refers to two processes:

• Profiling: collecting information about the browsing behavior of the visitors of your Web site

• Personalization: using the information collected during Profiling to customize the experience of the Web site visitor.

You can choose to either not implement Profiling and Personalization at all, to only implement Profiling, or to implement both.

1.2 Implementation plan

To implement Content Delivery, follow these steps:

Note that the order of these implementation steps is not rigid. For example, setting up the Presentation Server infrastructure may be done in parallel with the development of the Web site.

1.3 Licensing

The various functionality in Content Delivery has different licenses:

• Content Distribution consists of two different parts:

Rendering and resolving content: this is covered by the license of the Content Manager.

Transporting content: the Transport Service license covers all Table 1-1 Implementation plan for Content Delivery

Implementation step Description Explained in 1 Set up Content

Distribution

Implement basic Content Distribution to ensure that you can publish content from your Content Manager to one Presentation Server.

Chapter 2

"Implementing Content Distribution" on page 5

2 Develop the Web site Choose a Web site model and develop dynamic publishing for the Web site. Use the

Presentation Server to verify the results.

Chapter 3 "Developing the Web site" on page 13

3 Set up Profiling and Personalization

Chapter 5 "Profiling and personalization" on page 31

4 Set up a Presentation Server infrastructure

Create a more elaborate Presentation Server infrastructure.

Installation Manual

Chap ter 1 C o n tent Deliv e ry

transport protocols offered by SDL Tridion R5.

• Web site development can involve one or both of the following:

Dynamic Publishing, which requires a Web and Application Server Integration (WAI) license

Dynamic Linking, which requires a Linking license.

• Profiling and personalization requires the Web and Application Server Integration (WAI) license.

Chapter 1 Content Delivery

Chapter 2 Implementing Content Distribution

Content Distribution (also known as Publishing) involves a number of processes, each of which performs a specific task. This chapter explains the Content Distribution process in an overview, then explains how to implement Content Distribution, and then explains which parts of Content Distribution you can configure or adjust, and why you would want to.

Note This chapter describes how to implement Content Distribution from the Content Manager to one Presentation Server. The decisions listed here must be made for each Presentation Server to which you want to distribute content. To learn how to organize an infrastructure of Presentation Servers, refer to the Installation Manual.

2.1 Content Distribution concepts

Figure 2-1 shows the various parts of Content Distribution.

Figure 2-1 Content Delivery overview

Chapter 2 Implementing Content Distribution

The purpose of Content Distribution (or Publishing) is to get content out of the Content Manager and on the Presentation Server. The Presentation Server is a Web and Application Server. This section describes the sequence of subprocesses that make up Content Distribution.

Not all of these processes can be configured or customized. Implementing Content Distribution consists of setting up the Presentation Server and making

customizations and configurations where needed. This is described in "Content Distribution implementation plan" on page 12.

2.2 Content Distribution implementation decisions

Before you start implementing Content Distribution, you must make a number of decisions. Most of these decisions depend on technical factors, such as the technical expertise of your Web developers or the type of database you commonly use.

The following implementation decisions must be made:

• Which Web Application Server technology will the Presentation Server use?

• Which type of data store will the Presentation Server use?

• Which transfer protocol will Content Distribution use?

• Which, if any, customizations will you make to content deployment?

• Which content will you store in the data store, and which content in the Web folders?

• Will you implement caching?

Table 2-1 Content Distribution process Subprocess Description

Publisher In the Content Manager, either a user or some automated event triggers the publishing of an item. The Publisher offers this item to the Transport Service.

Transport Service The Transport Service assembles this item, together with any other items on which it depends, into a transport package.

Sender A Sender sends the package to one or more destinations using a specific protocol. Each destination represents a Presentation Server (usually a remote machine). At this point, the content leaves the Content Manager.

Receiver On the Presentation Server, a Receiver receives the package, using the same protocol as the Sender.

Deployer Upon arrival, the package is processed by a Content

Deployer. By default, this means that the items in the package are sent on to a Content Broker. But you can add your own custom processing ("Customizing content deployment" on page 8 explains how).

Broker The Content Broker stores the data it receives from the Deployer. The Broker stores data in a data store (a database or the local file system) and in a Web folder.

Chapter 2 Im plementi ng Content D istributi on 2.2.a Choosing the Web Application Server technology

Your Web Application Server can be one of the following:

• Microsoft Internet Information Services (IIS)

• ASP.NET Framework

• Java-based Web and Application Server (Tomcat, for example) You choose a technology based on the expertise you have available for

implementing that technology. That is, if you have a team of Java gurus, using an IIS-based Web Server is not the most logical choice.

Also note that an ASP.NET implementation is somewhat different from the IIS or Java-based implementations. Refer to the Content Delivery Implementation Manual (ASP.NET) for details.

2.2.b Choosing a type of data store

SDL Tridion R5 supports data storage in a variety of data stores:

• A file system

• SQL type databases:

Oracle

Microsoft SQL Server

DB2

To choose between these options, use the following guidelines:

• Publishing to a file system is generally only a good idea if you are publishing to a corporate, local intranet.

• SQL type databases are the most commonly used. The choice between them depends on the expertise of your database administrators.

Regardless of the type of database you choose, always make sure that your Presentation Server data store has ample space to store all the published content.

2.2.c Choosing a transfer protocol

More often than not, the Presentation Server to which you publish your content will dictate the protocol or protocols you can use. Your choice of protocols is:

• FTP

• SFTP (that is, FTP over SSH tunnels)

• SSHFTP (that is, SSH2 with a file transfer protocol subsystem)

• HTTP Important:

The Presentation Server must be able to connect to the data store. If the data store is a database, this means that you need a JDBC driver on the Presentation Server that can connect to this database.

Chapter 2 Implementing Content Distribution

• HTTPS

• Local file system

• A custom protocol

Depending on the protocol you choose, you need different Sender/Receiver pairs.

See the Content Delivery Implementation Manual to learn which Senders and Receivers are required for which protocol.

FTP or SFTP

The File Transfer Protocol is the easiest to implement and also the fastest in most cases. However, your Web Application Server may not allow you FTP access for security reasons, which means that HTTP is the logical alternative.

A secure FTP connection, if possible, helps to prevent third parties from intercepting and reading your transported content.

SSHFTP

If you are allowed to use an SSH2 server on your Presentation Server, but not allowed to use an FTP server, SSHFTP (that is, SSH2 using a file transfer protocol subsystem) is a good choice.

HTTP or HTTPs

If you transport over HTTP or HTTPs, you will need a small Web application on the receiving end:

• If your Web Application Server is based on IIS or ASP.NET, you must create a Web site, put an ASP page on it and register a DLL.

• If your Web Application Server is based on Java, you must deploy a Web application (.war file) that contains a servlet to receive incoming content.

A secure HTTP connection, if possible, helps to prevent third parties from intercepting and reading the content that you transport.

Local file system

If you are publishing to a machine that the Content Manager can access as a network drive, publishing to local file system is a (fast) option. (Note that the local in "local file system" refers to the local network, not to the local machine.) The local file system protocol is especially useful for publishing to an intranet.

Custom protocol

If you cannot use any of these protocols, a final option is to implement your own custom protocol to transport the content over. This advanced topic is described in

"Creating a custom transport protocol" on page 39.

2.2.d Customizing content deployment

When SDL Tridion R5 publishes content to a Presentation Server, the Content Deployer always unpacks the incoming Transport Package and processes the transport instructions included with the package.

Chapter 2 Im plementi ng Content D istributi on

You can configure what it does next. By default, it runs through a list of item types (Pages, Components and so on) and for each type, it deploys all the items in the package. "Deploying" here means sending them to the Content Broker for further processing. Each step of the deployment process is called a Module, and the deployment process as a whole is called a Processor.

You can change this default behavior of the Content Deployer in several ways:

• You can create a custom Module and add it to the Processor

• You can extend an existing Module

• You can create a custom Processor (by extending the default one)

Custom Modules: flushing cache, updating search index

In general, you would implement a custom Module and add it to a Processor if you want to do something more than simply storing the content in your data store. For example, you can use a custom Module for the following tasks:

• flushing the cache (see "Caching incoming content" on page 11)

• updating the search index (see "Integrating search" on page 20)

Extending an existing Module: adding metadata

The existing deployment Modules all perform a deploy or undeploy of all items of a certain type in the Transport Package. If you want to add certain information to items of a specific type, you can extend an existing Module.

The most common reason for extending an existing Module is to add custom metadata (for example, a keyword) to an item. A dynamic Web site uses custom metadata to filter Component Presentations (see "Implementing Dynamic Component Presentations" on page 26).

Extending the Processor: Module interdependencies

You can also modify the deployment process as a whole by extending the

Processor class. By default, the Processor class simply feeds the entire contents of its Transport Package to each of its Modules, which take turns processing the Package.

You can implement most custom deployment functionality by extending or creating a Module. The only reason to extend the Processor itself is if there are interdependencies between two Modules.

For example, say that you want to add the metadata of a Structure Group to each of the Pages contained in this Structure Group, or, similarly, add all Folder

metadata to the Components in that Folder. In both scenarios, the result of one Module analyzing one item type (Structure Groups or Folders) must be fed into another Module for another item type (Pages or Components). Such

interdependence of Modules calls for a custom Processor, which communicates data between Modules.

2.2.e Configuring where to store incoming content

The Content Broker can store incoming content in a number of different places.

However, not all types of content can be stored in all types of storage locations.

Chapter 2 Implementing Content Distribution

Storing all content in a Web folder

By default, the Content Broker stores all content in the Default Root Location, a configurable disk location in the Content Broker configuration file. If you set this disk location to a Web Folder, the Content Broker stores all your content in that Web folder. Only Categories and Keywords cannot be scored in a Web folder.

The benefit of storing all your content in a Web folder is that all your data is in one location. But the drawback is that everything you publish, including, for example, metadata, is accessible through the Web site.

Storing Web content in a Web folder and other content in a normal file folder

As Table 2-2 shows, you only need to store rendered Pages, binary data and Component Presentations with scripting in a Web folder. All other types of content can be written to a data store.

One possible data store is the local file system, that is, a location on disk that is not a Web folder.

In this scenario, you do not use one Default Root Location, but rather, you make a distinction between your Web folder (known as the Document Root), where you store Web content, and your normal file folder (known as the Data Root) where you store other types of content.

The benefits of using the local file system for storing non-Web content is that this content is now no longer directly accessible through the Web site. A drawback of using the local file system for storing non-Web content is that it is often slow.

Storing Web content in a Web folder and other content in a database Instead of storing non-Web content on the file system, you can also store your non-Web content in a relational SQL-type database. This can speed up your Web site considerably, and you can use the database to store Categories and Keywords.

Consult Table 2-2 to learn which types of content you can store in a database.

Then consult the Broker Bindings in the Content Broker configuration file and the Content Delivery Implementation Manual to learn how to store content in your database.

Table 2-2 Types of content and where to store them

Item type In

Rendered Pages D U U

binary data (images, PDFs) D U U

Any Component Presentation with scripting D U U

Static Component Presentation without scripting D D D Dynamic Component Presentation without scripting D D^a U

XML Component Presentations D D D

Chapter 2 Im plementi ng Content D istributi on

2.2.f Caching incoming content

To speed up your Web site, you may want to implement object caching (caching for short). Caching stores the most commonly used objects in the cache.

SDL Tridion R5 offers a default implementation (switched off by default) which works as follows:

• Policy: when the cache is full, the least recently used objects are removed from the cache.

• Features: when an item is removed from the cache, it is checked for

In document Content Management Implementation Guide 5.3 SP1 (Page 4-48)

Related documents

Version history

Content Delivery Project Planning Guide 5.3 SP1

Table of contents

Content Delivery Project Planning Guide 5.3 SP1

Chapter 1 Content Delivery

1.1 Content Delivery concepts

Chapter 1 Content Delivery

1.2 Implementation plan

1.3 Licensing

Chap ter 1 C o n tent Deliv e ry

Chapter 1 Content Delivery

Chapter 2 Implementing Content Distribution

2.1 Content Distribution concepts

Chapter 2 Implementing Content Distribution

2.2 Content Distribution implementation decisions

Chapter 2 Im plementi ng Content D istributi on 2.2.a Choosing the Web Application Server technology

2.2.b Choosing a type of data store

2.2.c Choosing a transfer protocol

Chapter 2 Implementing Content Distribution

2.2.d Customizing content deployment

Chapter 2 Im plementi ng Content D istributi on

2.2.e Configuring where to store incoming content

Chapter 2 Implementing Content Distribution

Chapter 2 Im plementi ng Content D istributi on

2.2.f Caching incoming content