SDL Tridion R5 Content Management Implementation Guide 5.3 SP1 Read this document to implement and learn about the following Content Manager features: Publications Blueprint Publication structure Users and Groups Publishing configuration and behavior Categories and Keywords Schemas Content configuration Custom Pages Event Log Metadata Workflow Outscaling
Content Management Implementation Guide 5.3 SP1 R5_CMIG_53SP1 1999-2009 SDL Tridion Development Lab BV NOTICE: The accompanying software package is confidential and proprietary to SDL Tridion Development Lab BV or its respective licensors. No use or disclosure is permitted other than as set forth by written license with the authorized distributors of SDL Tridion Development Lab BV. Trademarks SDL Tridion and SDL Tridion R5 are trademarks of SDL Tridion Development Lab BV or its respective licensors. All other company or product names used herein are trademarks of its respective owners. Suggestions Your suggestions and comments about SDL Tridion R5 functionality, documentation, and course material are highly valued and may be used to further enhance our offerings available to you. We will be glad to receive your suggestions at: SDL Tridion Development Lab BV Product Management P. O. Box 22709 1100 DE Amsterdam The Netherlands fax: +31 (0)20 20 10 501 Email: PMsuggestions@sdltridion.com Additional Licenses Please contact your SDL Tridion sales representative to order additional licenses of SDL Tridion R5 software. www.sdltridion.com offers you a complete overview of SDL Tridion's sales offices and further contact details.
Preface About this Project Planning Guide SDL Tridion R5 Content Delivery allows you to take content from the Content Manager and present it to the Web site visitor. This document explains how to plan, set up and organize Content Delivery. Read this document if your are a project manager or software architect planning to implement SDL Tridion R5 Content Delivery, preferably before you start using SDL Tridion R5. This Guide does not explain implementation details. To learn how to configure and implement Content Delivery and to find the API reference, refer to one of the Content Delivery Implementation Manuals: Content Delivery Implementation Manual (ASP) Content Delivery Implementation Manual (ASP.NET) Content Delivery Implementation Manual (JSP) How to use this guide Use this guide when you are planning and designing Content Delivery for your implementation of SDL Tridion R5, both in the functional design stage and the technical design stage. Chapter 1 Tridion Content Delivery Explains Content Delivery and the overall implementation plan of Content Delivery. Chapter 2 Implementing Content Distribution Explains how to plan the implementation of Content Distribution, that is, getting content from the SDL Tridion R5 Content Manager on to a Presentation Server. Chapter 3 Developing the Web site Explains how to plan the development of your SDL Tridion-based Web site. Chapter 4 Profiling and personalization Explains how to discover which visitor visits which type of content (profiling), and how to use that information to customize a Web site visit (personalization). iii
Chapter 5 Designing the infrastructure Explains how to design Content Delivery to multiple target machines. Chapter 6 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 Related documents This guide is one document from the documentation set for SDL Tridion R5. The full documentation set consists of the following documents, organized by the SDL Tridion R5 project phase in which they are used: Planning phase The Content Delivery Project Planning Guide (a PDF document) helps project managers prepare for an implementation of Content Delivery. Setup phase The Installation Manual (a PDF document) explains how to get SDL Tridion R5 modules up and running. The Product Prerequisites (a PDF document) explains which hardware and software SDL Tridion R5 supports or requires. Implementation phase The Content Management Implementation Guide (a PDF document) explains how to set up Blueprint structure, configure security and workflow, and similar broad implementation topics. The Templating Manual (a PDF document) explains how SDL Tridion R5 templates work, and how to use the Template Builder to create them. The Templating Implementation Manual TOM.NET (a Windows help file) explains how to interact with the.net version of the Tridion Object Model to create Template Building Blocks written in C# or another language supported by.net. This Guide also includes a complete reference of the TOM.NET API. The Templating and Customization Manual TOM (a Windows help file) explains how to interact with the COM+ version of the Tridion Object Model to create Templates written in VBScript or JScript, and how to perform other customizations of the Content Manager. This Guide also includes a complete reference of the TOM API. The Content Delivery Implementation Manual (ASP) (a Windows help file) explains how to implement Content Delivery functionality for an ASP Web site. iv The Content Delivery Implementation Manual (ASP.NET) (a Windows help file) explains how to implement Content Delivery functionality for an ASP.NET Web site. SDL Tridion R5
The Content Delivery Implementation Manual (JSP) (a Javadoc Web site) explains how to implement Content Delivery functionality for a JSP Web site. The Business Connector Implementation Manual (a PDF document) explains how to implement the Business Connector, which enables external applications to access the Content Manager. The Security Manual (a PDF document) explains the minimal user rights and privileges required for the Content Management and Content Delivery system parts to function correctly Usage and Maintenance phase The User Manual (a PDF document) explains to content authors and content editors how to work with content in the Content Manager Explorer Web interface. The WebDAV Connector User Manual (a PDF document) explains to content authors and content editors how to work with content using a WebDAV interface. The Upgrade Manual (a PDF document) tells system administrators how to upgrade to the current version of SDL Tridion R5 from a previous version. The Release Notes (a PDF document) explains how the current version of SDL Tridion R5 has changed compared to previous versions, and which open issues remain. The Maintenance Guide (a PDF document) helps you maintain, troubleshoot and monitor your implementation of SDL Tridion R5. 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. v
vi SDL Tridion R5
Table of contents 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 vii
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 viii SDL Tridion R5
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 1
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: 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 (optional) 4 Set up a Presentation Server infrastructure Implement profiling and personalization, using the Presentation Server to verify the results. Create a more elaborate Presentation Server infrastructure. Chapter 5 "Profiling and personalization" on page 31 Installation Manual 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 2 SDL Tridion R5
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 3
Chapter 1 Content Delivery 4 SDL Tridion R5
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 5
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. Table 2-1 Content Distribution process Subprocess Publisher Transport Service Sender Receiver Deployer Broker Description 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. The Transport Service assembles this item, together with any other items on which it depends, into a transport package. 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. On the Presentation Server, a Receiver receives the package, using the same protocol as the Sender. 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). 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. 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? 6 SDL Tridion R5
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 Chapter 2 Implementing Content Distribution 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. 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. 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 7
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. 8 SDL Tridion R5
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. Chapter 2 Implementing Content Distribution 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. 9
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 Web Folder In a normal file folder In database Rendered Pages binary data (images, PDFs) Any Component Presentation with scripting Static Component Presentation without scripting Dynamic Component Presentation without scripting a XML Component Presentations 10 SDL Tridion R5
Table 2-2 Types of content and where to store them Item type 2.2.f Caching incoming content In Web Folder In a normal file folder Metadata Categories and Keywords Link information 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 dependencies to make sure that the cache is never out of sync. In database a.your Application Server may restrict where the Broker can store the Dynamic Component Presentation. For example, Tomcat demands that you store the Dynamic Component Presentation in a folder that Tomcat can access. Chapter 2 Implementing Content Distribution Cache Bindings: you can configure which types of items you want to cache by specifying Cache Bindings. By default, cache all types of items by following the sample CacheBinding fragment provided in the Content Delivery Implementation Manual. Synchronization: if, say, your Deployer and Broker run on different virtual machines, you can start a Cache Channel Service to make cache synchronization across virtual machines possible, or use JMS to synchronize caches. Some application servers require that you flush the content cache after you deploy new content. To do this, you can build a custom Cache Flusher Module and add it to the Processor of the Content Deployer. The Content Delivery Implementation Manual explains how to do this. Refer to the Content Delivery Implementation Manual, specifically the Content Broker API reference, for more information about object caching and flushing, and how to configure it. 11
Chapter 2 Implementing Content Distribution 2.3 Content Distribution implementation plan To implement Content Distribution, go through the following steps: Table 2-3 Content Distribution implementation plan Implementation Step Description 1 Set up Presentation Server Choose and install a machine to use as a Presentation Server. This machine must be a Web Application Server. See the Installation Manual for details. 2 Set up data store Choose and, if necessary, install a data store in which the Presentation Server can store its content. See the Installation Manual for details. 3 Configure publishing In the Content Manager, specify where you want to publish content to by defining a Target Type and a Publication Target for this Presentation Server. See the Content Delivery Implementation Manual for details. 4 Configure Transport Service In the Content Manager, configure the Transport Service. See the Content Delivery Implementation Manual for details. 5 Configure Deployment On the Presentation Server, configure content deployment, possibly adding customized deployment behavior. See the Content Delivery Implementation Manual for details. 6 Configure Brokerage On the Presentation Server, configure both the storage and caching of content in the Content Broker configuration file. See the Content Delivery Implementation Manual for details. 7 Test Content Distribution Test Content Distribution by publishing content from the Content Manager and verifying that it appears on a Web page on the Presentation Server. 12 SDL Tridion R5
Chapter 3 Developing the Web site This chapter explains how to develop a Web site that is based on content managed in the Content Manager. SDL Tridion R5 allows for the development of many different types of Web sites, from purely static (HTML only) to purely dynamic (all content assembled from the database). To help you design your Web site, four different Web site models are presented here, with benefits and drawbacks for each model. Finally, the chapter describes how to integrate common Web development functionality (such as search and navigation) in the Content Manager. 3.1 Web site development concepts This section presents a number of Content Delivery concepts that are relevant to the development of an SDL Tridion-based Web site. 3.1.a Content Manager items and Web site items A Content Manager Publication contains different items than the resulting SDL Tridion-based Web site. When you publish content, items in the Content Manager combine to form the content of the Web site. Here is an overview of which items exist in the Content Manager and how they produce Web content. Components are the basic building blocks of Web content. They represent the content (without look & feel) of a part of a Web page. Component Templates visualize (some or all of) the content contained in a Component. Component Templates can also include scripting that adds dynamic behavior to the Component. 13
Chapter 3 Developing the Web site Components and Component Templates combine to form Component Presentations, fragments of HTML and possibly script code, that can be part of a Web page. Pages are used to produce Web page on the Web site. A Page almost always contains one or more Component Presentations. Page Templates visualize Pages to produce Web pages. A Page Template may contain a database query that results in a set of Component Presentations being added to the Page. Structure Groups are containers for Pages. They correspond to Web folders on the Web site and may also be used in the automatic generation of menus. 3.1.b Web site models When you design your Web site, one of the main questions to consider is how dynamic you want the Web site to be. The answers to that question depends on what you want to do with the content you manage in the Content Manager. This section shows you four increasingly dynamic Web site models: Table 3-1 Web site models Model Static HTML Static ASP/JSP Dynamic Component Presentation Model (DCP Model) Application Model Description The data store contains fully generated Web pages. All the Web site needs to do is retrieve a Web page from the data store and show it to the Web visitor. Web pages refer to a specific set of Dynamic Component Presentations. These Component Presentations are stored in the data store and retrieved when a visitor visits the Web page. Web pages retrieve Dynamic Component Presentations from the data store based on a database query on the Page. The entire Web page is assembled by a custom Web Application that you develop. Publishing simply puts pieces of content into the Broker data store, but provides no structure of any kind. Note Many sites will combine the Static ASP/JSP and DCP models: all Component Presentations are saved separately in the data store. Some are retrieved directly, while others are collected on the basis of a database query. The four Web site models are at various points on the static-dynamic spectrum, as Figure 3-1 illustrates. Figure 3-1 Static-dynamic spectrum 14 SDL Tridion R5
3.1.c Linking In the Content Manager, authors can create links to Components. You use Linking to transform these Component Links into actual hyperlinks to Web pages. Linking serves two purposes: If the target of the Component Link is not present on the Web site, Linking removes the link (and, optionally, also the link text). If the Component Link is ambiguous (that is, if the link points to a Component that appears on more than one Web page), Linking chooses which Web page to link to. Priority To determine how Linking resolves ambiguous links, you can use priorities. You set priority in a Component Template. The Component Template combines with a Component to create a Component Presentation. Linking always causes a hyperlink to point to the Component Presentation with the highest priority. Linking resolves all internal links within your Web site. Chapter 3 Developing the Web site Dynamic Component Linking If a link points to a Component that is not embedded on any Web page, but only appears as the result of a database query, the Component Link you create will by default always be considered dead. To resolve these Dynamic Component Links, you must construct a Page that accepts two parameters: The URI (unique identifier) of a Component The URI of a Component Template The Page combines the Component and the Component Template to produce a Component Presentation, and displays this Component Presentation. If Linking finds the target Component in the database, you can then pass the URIs of the Component and Component Template to the Page to display the Component you linked to. 3.2 Web site development decisions Before you start developing your Web site, you must make a number of decisions: In which scripting language do I develop my Web site? Which Web site model or models do I choose to develop? Do I use static or dynamic navigation? Do I integrate search in SDL Tridion R5, or implement it separately? 15
Chapter 3 Developing the Web site 3.2.a Choosing a scripting language Content Delivery currently supports the following scripting environments for your SDL Tridion-based Web site: JSP ASP VBScript ASP JScript ASP.NET The choice of scripting language depends on what kind of expertise your Web developers have. 3.2.b Choosing a Web site model To decide on a Web site model, consider the following rules of thumb: The more you reuse content, the more dynamic your Web site should be. The more often you update your Web site, the more dynamic your Web site should be. The bigger your Web site, the more dynamic your Web site should be. The more resources you have at your disposal (both human resources and hardware resources), the more dynamic your Web site can be. Static HTML model In the static HTML model, Web pages containing specific Component Presentations are generated at publish time. The Web pages may contain scripting. Table 3-2 Benefits and drawbacks of the static HTML model Benefits The Web site puts minimal load on the Web server, because the Web server can directly retrieve the entire page in HTML from the Web site itself and present it to the visitor. Maintenance is easy because the Web site is ready and assembled. The site is easy to host and can use proxies. Drawbacks Updating the Web site can take a long time because one change in the content can mean regenerating enormous amounts of Web pages. The more content you have, the longer it will take. While the site is being published, it either has to go offline or be inconsistent (the Web visitor sees updated content on one Web page, and outdated content on another). The site runs more risk of becoming inconsistent, especially if you do not republish all the content every time you make a change. 16 SDL Tridion R5
Static ASP/JSP model In the static ASP/JSP model, Web pages containing specific Component Presentations (known as embedded Component Presentations) are generated at request time. Each Component Presentation is stored individually in the data store and retrieved by a piece of script code on the Web page. Table 3-3 Benefits and drawbacks of the static ASP/JSP model Benefits The pieces of content that are most reused on the Web site, such as the navigation, are published only once, and included on every Web page. A Component always looks the same on every Web page, because all these pages refer to the one Component Presentation in the data store. The Web site does not need to go offline when a Component has changed, because no new Pages need to be generated. Drawbacks The model puts a fairly heavy load on the Presentation Server's resources and requires more space in the data store. It is not possible to determine dynamically what a Web page will contain. More work is involved in maintaining the site. Chapter 3 Developing the Web site Dynamic Component Presentation model In the Dynamic Component Presentation model, Web pages assemble Component Presentations from the data store through a process called Dynamic Content Assembly. Dynamic Content Assembly means that the Web page queries the metadata of Components and collects the results of that query on the page. For example, the page may query the publishing date of the Components to find the most recently published Components. Table 3-4 Benefits and drawbacks of the Dynamic Component Presentation model Benefits You can create truly dynamic Pages, the content of which is not predetermined. Drawbacks The model puts a heavy load on the Presentation Server's resources, and requires more space in the data store. It is more difficult to predict which content a Web page will contain exactly. More work is involved in maintaining the site. 17
Chapter 3 Developing the Web site Application model In the application model, all content is stored in the data store and assembled at request time. Table 3-5 Benefits and drawbacks of the Application model Benefits Maintenance of the Web site is easy and cost-effective. The model implements the "Model View Controller" design pattern, a software design principle that makes the three parts of a Graphical User Interface separate from each other. You can use your Web Application server to integrate the SDL Tridion content with other applications and/or systems. It is easier to implement profiling and personalization. Drawbacks This model requires a relatively high initial investment, in terms of both time and money. Developing a Web site according to this model requires more advanced development and design skills. Editors have virtually no direct control over the way in which content appears on the Web site. Note Building a dynamic Web site according to the Application model is very much influenced by the specific Web site you are trying to build. Therefore, this Guide cannot explain this model in greater detail. 3.2.c Dynamic navigation If your Web site contains a lot of content, your navigation is likely to be comparably large and can no longer be managed efficiently by hand. If this is the case, you can generate your navigation structure dynamically, based on information in the Content Manager. The benefit of dynamic navigation is that your navigation is never inconsistent. The drawback of dynamic navigation is that you must ensure that the organization of your content in the Content Manager corresponds with the navigation you want to display on the Web site. 3.2.d Integrating search SDL Tridion R5 does not include search functionality for your Web site. However, you can acquire a third-party search engine and integrate it with your Content Distribution implementation, so that your search index is updated as soon as new content is published to the Web site. The benefit of integrating search into Content Distribution is that your search index is always up to date. You do not need your search engine to periodically crawl your Web site. The drawback of integrating search is that it involves a certain development effort. 18 SDL Tridion R5
3.3 Web site development implementation plan To develop a Web site for SDL Tridion R5 content, go through the following steps: Table 3-6 Content Distribution implementation plan Implementation Step Description 1 Choose a scripting language Choose the scripting environment in which you want to develop the Web site. 2 Choose a Web site model Decide which Web site model(s) you want to develop. 3 Organize content for navigation (optional) 4 Install, implement and integrate search If you want to generate navigation automatically, design a content organization that corresponds to the navigation you want to generate. Install and configure your third-party search engine. If you want to integrate search into SDL Tridion R5, you can do so by creating a custom Deployer module. Chapter 3 Developing the Web site 5 Develop Component Templates and Page Templates 6 Write queries for Dynamic Content Assembly (optional) 7 Customize Linking (optional) 8 Publish Dynamic Component Presentations (optional) Create Component Templates and Page Templates that present the Components and Pages in the way that you want them to be displayed. If your Web site model requires queries for Dynamic Content Assembly, create a Page Template that executes such a query and processes the results. SDL Tridion R5 ships with a standard implementation of Linking. You may wish to change the default behavior. If the Web site model requires it, make Component Templates dynamic in order to create Dynamic Component Presentations. 9 Test the Web site Perform tests to verify that the site itself, as well as the search, hyperlinks and navigation, all work as expected. The following subsections provide more detail on the following implementation steps: Organizing content for navigation Integrating search Writing queries for Dynamic Content Assembly Implementing Linking 19
Chapter 3 Developing the Web site 3.3.a Organizing content for navigation You can use information in the Content Manager to create a navigation menu on the Web site dynamically. There are several ways in which you can do this. Here is a possible implementation: 1 In the Content Manager, you organize your Pages in Structure Groups. Create a hierarchy of Structure Groups that corresponds to the menu hierarchy that you want to show on the Web site. The names of the Structure Groups should be the names of the menu items. 2 Create a metadata schema that contains a number field and use it to add metadata to each Structure Group. The number indicates the position of this menu item in the menu. For example, a Structure Group with metadata set to '400' appears below a Structure Group with metadata set to '300'. 3 Add the same metadata to the Pages of your Web site. 4 Create a "menu Page Template" to generate this menu. The menu Page Template navigates through the Structure Group hierarchy and the Pages in it, and creates a menu structure in the order specified by the metadata. 5 Create an empty Page and associate it with the menu Page Template. Use scripting in each of the various regular Page Templates to include this menu Page on each Page. 6 Use the SDL Tridion Event System to make sure that whenever a Page is (re)published, the menu is also republished. 3.3.b Integrating search To allow Web site visitors to search your SDL Tridion R5-managed Web site, you need: third-party search software a search index that this search software can use The best moment to update your search index is when new content enters the system. This saves you the time and effort of building a search index by crawling through the site at regular intervals. You can create an Update Search Index Module and add it to the Processor as the last Module. The typical procedure for implementing search, then, is: 1 Select and purchase third-party search software. 2 Create a custom Module (Java class) that adds items to the search index based on the content and/or metadata of Pages and/or Components. Most search software includes a Java interface; if yours does not, you can use the Java Native Interface (JNI) to communicate with your search software. 3 Add this Module to the Processor of your Content Deployer that actually deploys the content. 4 Build up a search index by adding content to your Web site s data store. 20 SDL Tridion R5
Note The above procedure explains how to implement a free-form search interface in which the users enters a string and clicks a search button. For more structured searching (by picking items from a list, checking options and so on), refer to "Writing queries for Dynamic Content Assembly" on page 21. 3.3.c 5 Add a search interface to your Page Template(s) that uses the search software to perform the filtering for you. 6 Test to see if search works to your satisfaction. Writing queries for Dynamic Content Assembly Normally, you add specific Component Presentations to a Page in the Content Manager and publish them to the Web site. The resulting Web page always shows the same Component Presentations. In some cases, however, you may want to determine which Component Presentations to pick based on dynamic criteria. For example, you may want to display the five most recently published Component Presentations, or all Component Presentations that have been marked 'sports'. This is known as Dynamic Content Assembly. Chapter 3 Developing the Web site To implement Dynamic Content Assembly, you do not specify a fixed set of Component Presentations to add to a Page. Rather, you specify a query consisting of content criteria and then include (some or all) Components that meet those criteria. Using queries to select a number of Dynamic Component Presentations is known as filtering. Important: Any query you produce can only examine the metadata of a Component Presentation. It cannot look at the actual content. To implement Dynamic Content Assembly: 1 Decide what type of filter you want to make. Some typical types of filters are: Related Items filter: select Component Presentations based on one or more Keywords. Most Visited Components filter: select Component Presentations based on the number of times they were accessed (this requires implementation of Tracking, see Chapter 5 "Profiling and personalization" on page 31). Most Recently Published Components filter: select Component Presentations based on their Initial Publication Date. Note Do not use Dynamic Content Assembly to create a search filter. Use a third-party search application instead, as it is optimized for speed. 21
Chapter 3 Developing the Web site To implement Dynamic Content Assembly: (Continued) 2 If the type of information you are filtering on is not included in the standard metadata of a Component, create custom metadata (for example, Categories and Keywords) for this information. 3 Publish the Component Presentations you want to filter on as Dynamic Component Presentations. 4 Create a Page Template that uses the Query class to create a query, and the SearchFilter class to execute it. Refer to the Broker API documentation for more information. The query returns an array of Component URIs. Combine these Components with a Component Template of your choice to produce the Component Presentations you want to show. Note Be sure to handle the eventuality that the query returns no results at all. 5 You can configure the results of the query in the following ways: You can restrict the number of Components to a specific number. You can sort the result on a specific metadata field. You can specify a sort direction (ascending/descending). 6 Create a Page without adding any Component Presentations to it, and associate it with the Page Template you just created. 7 Publish this Page and examine the result on the Web site. 3.3.d Implementing Linking Linking resolves all internal links on your Web site. Linking requires you to obtain and install a Linking license key (see the Installation Manual for more details). SDL Tridion R5 ships with a standard Template Building Block that implements a default implementation of Linking, so that your links are resolved without any coding on your part. The behavior of this default implementation is as follows: Dead links: If a hyperlink points to an item that does not exist, the hyperlink itself is removed, but the text of the link is still displayed. Ambiguous links: If a link in the Content Manager points to a Component that can be found on more than one Page, the hyperlink on the published Page will point to the Page is that is 'nearest' the referring page. Refer to the Content Delivery Implementation Manual to learn the details of this behavior. You may decide to change this behavior. As for dead links, you can configure on a per-link basis whether you want the text of the dead link to be displayed on the Page or not. See the Content Delivery Implementation Manual, specifically the Linking API reference documentation, for details. 22 SDL Tridion R5
As for ambiguous links, you can use priorities to determine which Page a link will point to. You set priority in a Component Template. The Component Template combines with a Component to create a Component Presentation. Dynamic Linking always causes a hyperlink to point to the Component Presentation with the highest priority. The following rule for setting priorities usually produces the best results: The Component Template that displays more Component content has higher priority. For example, suppose that you have two Component Templates for a news article Component. One Component Template shows only the headline of the news article, and the other Component Template shows the entire article, including images. By giving the 'full content' Component Template a higher priority, links to this Component will now always point to the longer version. Chapter 3 Developing the Web site 23
Chapter 3 Developing the Web site 24 SDL Tridion R5
Chapter 4 Implementing dynamic functionality Depending on the dynamic model you wish to implement (see "Web site development concepts" on page 13), implementing dynamic functionality involves one or more of the following tasks: Implementing search Implementing dynamic navigation Implementing Dynamic Component Presentations Implementing Dynamic Linking Implementing Dynamic content assembly The following subsections provide an overview of the implementation of each of these features. Apart from planning which feature to implement, there is also the technical decision of which scripting environment to use. 4.1 Implementing search To allow Web site visitors to search your SDL Tridion-managed Web site, you need: third-party search software a search index that this search software can use The best moment to update your search index is when new content enters the system. This saves you the time and effort of building a search index by crawling through the site at regular intervals. You can create an Update Search Index Module and add it to the Processor as the last Module. The typical procedure for implementing search, then, is: 1 Select and purchase third-party search software. 25
Chapter 4 Implementing dynamic functionality 2 Create a custom Module (Java class) that adds items to the search index based on the content and/or metadata of Pages and/or Components. Most search software includes a Java interface; if yours does not, you can use the Java Native Interface (JNI) to communicate with your search software. 3 Add this Module to the Processor of your Content Deployer that actually deploys the content. 4 Build up a search index by adding content to your Web site s data store. 5 Add a search interface to your Page Template(s) that uses the search software to perform the filtering for you. 6 Test to see if search works to your satisfaction. Note This procedure explains how to implement a free-form search interface in which the users enters a string and clicks a search button. For more structured searching (by picking items from a list, checking options and so on), refer to "Dynamic Content Assembly" on page 28. 4.2 Implementing Dynamic Component Presentations There are various reasons for publishing Dynamic Component Presentations: To make Dynamic Linking possible (see "Implementing Dynamic Linking" on page 27). To make Dynamic Content Assembly possible (see "Dynamic Content Assembly" on page 28). To speed up the publishing process and improve the Web site consistency (explained in this section). If one Component Presentation appears on many static Web pages, republishing the Component causes all of these pages to be regenerated and republished. This is a problem for various reasons: It slows down the publishing process. It creates Web site inconsistency: during publishing, one page may show the updated Component Presentation, while another shows the outdated Component Presentation. It takes up disk space: copies of the same Component Presentation occur in multiple Web pages. To solve this problem, you can implement Dynamic Component Presentations. SDL Tridion R5 publishes Dynamic Component Presentations to the Content Broker data store, but does not embed them on a Web page. If you add a Dynamic Component Presentation to a Page, SDL Tridion R5 does not insert the contents of the Dynamic Component Presentation. Rather, SDL Tridion R5 now inserts a piece of script code to the Page. This script code retrieves the Dynamic Component Presentation from the data store when the Page is visited. Using benefits of this approach are: Publishing is faster, because SDL Tridion R5 does not need to republish Pages when a Dynamic Component Presentation changes. 26 SDL Tridion R5
The Web site is consistent at all times, because all Pages refer to one and the same Dynamic Component Presentation. Less disk space is used, because there is now only one instance of the Dynamic Component Presentation, and it resides in the Content Broker database. The disadvantage of using Dynamic Component Presentations is that you need a faster Web server and/or faster data store access, because the page is created 'on the fly'. Refer to the Content Delivery Implementation Manual for details on how to publish Dynamic Component Presentations. 4.3 Implementing Dynamic Linking In the Content Manager, authors can create links to Pages, Components and Multimedia Components. By implementing Dynamic Linking, you can resolve those links dynamically on the published Web site. Dynamic Linking requires that you store data in a SQL-type database (rather than publish content to a local file system). Using Dynamic Linking has the following advantages: By default, the published Web site does not contain dead links to items within the site, because dead links are not displayed. The Content Manager author can create a link to a Component and rest assured that on the published Web site, the link will point to a page that contains the Component. Chapter 4 Implementing dynamic functionality To learn more about implementing Dynamic Linking, refer to the Content Delivery Implementation Manual. 4.4 Implementing dynamic navigation Because your navigation appears on virtually every page of your Web site, changing the navigation in a static Web site model causes every page of the site to be republished. Additionally, if the navigation part of the page contains is scripted (for example, it is a DHTML tree), every page must re-execute the same DHTML code again and again. A dynamic Web site can solve these problems by allowing you to perform a server-side include of the navigation on every Page. The most common way of implementing dynamic navigation is to create a special Page Template that collects all the information needed to generate the navigation menus. This usually means copying the tree structure of the Publication's Structure Groups down to some level. The Page Template is then applied to an empty Page, so that the result is a 'navigation Page' that can be included in any published Web Page. 27
Chapter 4 Implementing dynamic functionality 4.5 Dynamic Content Assembly Normally, you add specific Component Presentations to a Page in the Content Manager and publish them to the Web site. The resulting Web page always shows the same Component Presentations. In some cases, however, you may want to determine which Component Presentations to pick based on dynamic criteria. For example, you may want to display the five most recently published Component Presentations, or all Component Presentations that have a certain Keyword set to 'sports'. This is known as Dynamic Content Assembly. To implement Dynamic Content Assembly, you do not specify a fixed set of Component Presentations to add to a Page. Rather, you specify a query consisting of content criteria and then include (some or all) Components that meet those criteria. Using queries to select a number of Dynamic Component Presentations is known as filtering. Important: Any query you produce can only examine the metadata of a Component Presentation. It cannot look at the actual content. To implement Dynamic Content Assembly: 1 Decide what type of filter you want to make. Some typical types of filters are: Related Items filter: select Component Presentations based on one or more Keywords. Most Visited Components filter: select Component Presentations based on the number of times they were accessed (this requires implementation of Tracking, see Chapter 5 "Profiling and personalization" on page 31). Most Recently Published Components filter: select Component Presentations based on their Initial Publication Date. Note Do not use Dynamic Content Assembly to create a search filter. Use a third-party search application instead, as it is optimized for speed. 2 If the type of information you are filtering on is not included in the standard metadata of a Component, create custom metadata (for example, Categories and Keywords) for this information. 3 Publish the Component Presentations you want to filter on in combination as Dynamic Component Presentations (see "Implementing Dynamic Component Presentations" on page 26). 28 SDL Tridion R5
To implement Dynamic Content Assembly: (Continued) 4 Create a Page Template that uses the Query class to create a query, and the SearchFilter class to execute it. Refer to the Broker API documentation for more information. The query returns an array of Component URIs. Combine these Components with a Component Template of your choice to produce the Component Presentations you want to show. Note Be sure to handle the eventuality that the query returns no results at all. 5 You can configure the results of the query in the following ways: You can restrict the number of Components to a specific number. You can sort the result on a specific metadata field. You can specify a sort direction (ascending/descending). 6 Create a Page without adding any Component Presentations to it, and associate it with the Page Template you just created. 7 Publish this Page and examine the result on the Web site. Chapter 4 Implementing dynamic functionality 29
Chapter 4 Implementing dynamic functionality 30 SDL Tridion R5
Chapter 5 Profiling and personalization As a part of creating your Web site, you may want to find out how your Web site visitors interact with your content. This is known as profiling. Profiling gives answers to the following questions: Which Page or Component is popular with a specific user? Which type of content is popular among which types of users? When you have collected this information, you may then want to use these results to show each visitor content that is tailor-made to his or her personal preferences. This is known as personalization. To improve this personalization, you may also want to include additional information about your visitors. Such additional information may come from a consumer database, for example, or from a form on your Web site. By offering a Web visitor a more personalized experience, you increase the likelihood of the visitor staying on your Web site longer and of visiting again later. 5.1 Profiling and personalization concepts To perform profiling, you can use Tracking, Tracking Keys, Categories and Keywords. Tracking Tracking measures which content a visitor accesses during a specific period of time. Tracking Keys, Categories and Keywords Tracking Keys measure which types of content are accessed; that is, which Components and Pages are requested and which Component links are or are not clicked. To implement Tracking Keys, you must analyze your (existing and planned) content to determine the types of content you offer. You define these content types in Categories and Keywords, which content authors then use to categorize the content they produce. 31
Chapter 5 Profiling and personalization Target Groups You can choose to hide or show content for a specific visitor (personalization) based on their membership of a Target Group. Membership of a Target Group depends on a combination of the following criteria: Customer Characteristics: these are properties of your customers that you have collected in some way and stored in the Broker database. For example, if your Customer Characteristics include the user s age, you can specify that this Target Group should only contain users in the 19-to-24 age bracket by saying that the Age property must have a value larger than 18, and lower than 25. Tracking Keys: these are the Keywords whose popularity you have been measuring. Tracking Keys have a numerical value that represents how often the user looked at that specific type of content. For example, you might specify that this Target Group should only contain users for whom the value for 'Sports' is higher than 100 (indicated a strong interest in sports). 5.2 Profiling and personalization implementation decisions To make profiling and personalization work, it is important to first consider what you want to do with the data you collect, and how much additional information you can provide about the people who visit your Web site. The decisions to make are: Do you want to implement Tracking profiling (that is, collect data about which content is accessed by which visitors)? Do you want to implement Tracking Keys profiling (that is, collect data about which type of content is accessed by which visitors)? If you implement Tracking Keys profiling: Which Categories and Keywords do you want to define to categorize your content? Which weight do you want to assign to a visitor accessing or not accessing a specific type of content? Do you want to implement personalization? If you implement personalization: Which kinds of Target Groups do you distinguish among your Web site visitors? When you create Target Groups, do you want to involve external data about the people who will be accessing your Web site? 5.2.a Choosing to implement Tracking Tracking gives you basic measurements about which parts of your Web site are popular and which are less popular. You can choose to modify, add or remove content from the Web site based on these measurements, or to make content more prominent (for example, by moving a Component to the Web site's front page). 32 SDL Tridion R5
5.2.b Choosing to implement Tracking Keys Tracking Keys give you more insight into what type of content visitors access or ignore. Not only does that give you more useful measurements about what content is interesting or uninteresting to your visitors, it also provides the basis for personalization. The drawback of implementing Tracking Keys is that you must first perform a content analysis in order to be able to define Categories and Keywords. Defining Categories and Keywords A common type of Category to define is the type of topic. You then create Keywords in this Category and make each Keyword a specific topic, such as 'sports' or 'business'. But you can also use Categories and Keywords to, for example, mark items as specific to visitors from a certain part of the world. Setting weights on Tracking Keys You can set increment weights (added when a visitor selects content with this Keyword) and decrement weights (subtracted when a visitor fails to select content with this Keyword). Generally the increment weights should be much higher than the decrement weights (a ratio of 50 to 1 is recommended). Chapter 5 Profiling and personalization 5.2.c Choosing to implement personalization Personalization can help you create a Web site that is tuned to the wishes or needs of the Web site visitor. But there is some development effort involved. Defining Target Groups The simplest way to determine Target Groups is to base them solely on the Tracking Keys you have defined. The drawback of this approach is that you must collect data about a visitor's browsing behavior before you can offer him or her personalized content. Involving Customer Characteristics Another way to create Target Groups is to involve Customer Characteristics when you create a Target Group. Customer Characteristics are taken from customer databases or forms on the Web site, and often contain important information about your visitor such as their age group, area of origin, and interests. The drawback of this approach is that not all of your customers may want to submit such information. 5.3 Profiling and personalization implementation plan Before you start implementing profiling and personalization, note that: Personalization and Profiling requires Dynamic Component Presentations (see "Developing the Web site" on page 13). Personalization and Profiling requires a Broker data store that is a relational database (Microsoft SQL, DB2 or Oracle). 33
Chapter 5 Profiling and personalization 5.3.a Implementing Tracking and Tracking Keys This section gives an overview of how to implement Tracking and Tracking Keys functionality. For more details about these implementations, consult the Content Delivery Implementation Manual. Implementing Tracking To implement Tracking, simply configure the Tracking section of the WAI configuration file. Implementing Tracking Keys To implement Tracking Keys: 1 Perform a content scan of your (planned) Web site to determine which types of content you offer to your Web site visitors. 2 Use the result of this content scan to create Categories and Keywords. For example, if you are setting up a news site, you may create a Category "contenttype" and add Keywords such as "sports", "music", and "politics". 3 Add the Category or Categories to your Schemas as a field, so that content authors can pick one of the Keywords to indicate the type of content they are adding to the Web site. 4 Associate the Schema with a Content Template and add the Category you created as a Tracked Category to the Content Template. 5 Configure the Tracking Keys section of the WAI configuration file. 5.3.b Implementing personalization Implementing personalization consists of several steps: 1 If you have customer data that you want to involve in the personalization process, add it to the Broker database as Customer Characteristics. 2 Using Tracking Keys and possibly Customer Characteristics, organize types of Web site visitors in Target Groups. 3 Finally, associate Component Presentations on a page with one or more Target Groups. Adding Customer Characteristics You may already have a collection of customer data that you want to involve in personalization, stored in some external database. Alternatively, you may also have a form on your Web site that visitors can use to enter customer data. You can store this information in Customer Characteristics as a combination of a user ID, a property and a value. For example, if a customer with ID 43537 fills in a form and fills in 'Canada' in the Country field, you would add a Customer Characteristic with the value "43537, Country, Canada". 34 SDL Tridion R5
To add Customer Characteristics to the system, use the WAI API (refer to the Content Delivery Implementation Manual for the reference documentation for this API). Creating Target Groups You can create a Target Group in the Content Manager by defining a set of criteria that your Web site visitor must satisfy in order to see a Component Presentation. See the Content Delivery Implementation Manual for the specifics of creating a Target Group. Associating Component Presentations with a Target Group The last step of the personalization procedure is to associate a Component Presentation with a Target Group or Target Groups. You do this in the Content Manager when you assemble Component Presentations onto a Page. By associating a Component Presentation with a specific Target Group, you ensure that the Component Presentation is only shown to users who meet the criteria of that Target Group. Refer to the Content Delivery Implementation Manual for the specifics of adding a Target Group to a Component Presentation. Note Include at least one Component Presentation that is shown to every visitor; otherwise, some visitors may get to see an empty page. Chapter 5 Profiling and personalization 35
Chapter 5 Profiling and personalization 36 SDL Tridion R5
Chapter 6 Content Delivery use case This Content Delivery use case shows you an overview of the design, planning and implementation of a sample Content Delivery implementation. In this example, you have been hired to build Content Delivery for a news site that is managing all of its content in the SDL Tridion R5 Content Manager. The use case takes you through the various stages of the implementation, explaining which decisions are made and why at each step of the way. 6.1 Project definition and constraints You have been asked to implement Content Delivery for a company called "What s News?" At this company, reporters use the SDL Tridion R5 Content Manager to produce content on a wide range of news topics, such as sports, the arts, economic affairs and international news. At the project kick-off meeting, you meet the project manager for the project. He explains that he would like to have the following features on the finished Web site: A working search engine that is always up-to-date A separate page for each type of news A page with the latest news items At this same meeting, you also meet the software architect. She gives you the following information: The company has obtained a third-party search application. The company wants to have a staging server that authors can publish to; only after the content is approved by an editor can it then go live. The company has two Windows 2003 Server machines available, both running IIS and an FTP server. One of these machines is on the local network, this is to be their staging server; another is at their Web hosting company and is intended as the live server. Transport to the live server must be secure. The company also has two database servers running Microsoft SQL Server. 37
Chapter 6 Content Delivery use case The Content Manager has been used to enter news articles. There is also a Page Template as well as two Component Templates: one to show the summary of a news article, and another to show the full content of the article. Based on this information, you create an implementation plan and start implementing it. 6.2 Setting up transport To get transport up and running, you decide to configure and test transport to the staging server first, and set up a proper infrastructure later. Your implementation of transport goes as follows: 1 Using the SDL Tridion R5 Installation CD-ROM and the Installation Manual, install Content Delivery on the staging server machine, turning it into a Presentation Server. Additionally, install a Content Delivery database (Broker database) on a Microsoft SQL Server machine. 2 In the Content Manager, create a Target Type for the Web site. 3 In the Content Manager, create a Publication Target for the staging server with the following properties: The Target Language is ASP VBScript. The Destination points to the staging server through a (non-secure) FTP connection. The Publication that contains the news content can publish to this Publication Target. The Target Type that you just created is associated with this Publication Target. 4 Edit the transport configuration file on the Content Manager machine to send out content using an FTPSender (see the Content Delivery Implementation Manual for details). 5 Edit the deployer configuration file on the Presentation Server to receive content using a FileReceiver (see the Content Delivery Implementation Manual for details). 6 Edit the Broker configuration file to store all incoming content except Pages and binaries in the MS SQL Server database, by changing the Broker bindings. 7 Test transport by publishing a page with Component Presentations to the Target Type and checking if you can view the result on the Presentation Server. 38 SDL Tridion R5
6.3 Implementing dynamic functionality Based on the functional requirements for this project, you conclude that a Dynamic Component Presentation model (see "Dynamic Component Presentation model" on page 17) for the Web site is the best way to go. You implement the following: Search functionality Linking Dynamic Content Assembly Implementing search functionality The search application provided to you has a Java interface for updating its index. You program a custom deployer Module that feeds the titles of the news articles being deployed into the search engine, and add it to the Processor that deploys content in the Content Deployer configuration file. Linking Chapter 6 Content Delivery use case To implement Linking, you simply add the license key for Linking to the Content Delivery license file on the Presentation Server, and include the default Template Building Block called "Default Template Building Block" in your Component Templates. Dynamic Content Assembly From the functional requirements, you conclude that you need to: publish your Component Presentations as Dynamic Component Presentations to a database create Pages that perform Dynamic Content Assembly To store your Component Presentations in the SQL Server database as Dynamic Component Presentations, edit the Component Templates so that all Component Presentations are dynamic and can be dynamically assembled onto a Page. Then, create the following Pages that perform Dynamic Content Assembly: Pages for each news category. You create each Page as follows: You make a separate Page Template with a query in it. You program the query to returns all Component with their content type set to this specific news category. In the Page Template, you combine the Components returned by the query with the 'summary' Component Template. You create a Page without Component Presentations and associate it with this Page Template. a Page showing the last 10 news items (displayed as summary). You create the Page as follows: You make a separate Page Template with a query in it. You query for all Components, sort them (descending) by the date on which they were initially published (standard Component metadata), and limit the number of items returned by the query to 10. 39
Chapter 6 Content Delivery use case In the Page Template, you combine the Components returned by the query with the 'summary' Component Template. You create a Page without Component Presentations and associate it with this Page Template. 6.4 Setting up the infrastructure After you have finished developing the Web site and have tested it so confirm that it is ready to go live, it is time to add the Live server as a Publication Target. 1 Using the SDL Tridion R5 Installation CD-ROM and the Installation Manual, install Content Delivery on the live server machine, turning it into a Presentation Server. Do not make it publicly accessible yet. Additionally, install a Content Delivery database (Broker database) on a Microsoft SQL Server machine. 2 Set up a workflow for your content that involves a workflow status 'Ready for Live' that only properly authorized SDL Tridion R5 users can set. 3 In the Content Manager, create a Publication Target for the live server with the following properties: The Target Language is ASP VBScript. The Destination points to the live server through an SFTP connection. Make sure that SSH is installed on the live server. The Publication that contains the news content can publish to this Publication Target. The Target Type that you created when you set up transport is now also associated with this Publication Target. The Minimal Approval Status for this Publication Target is 'Ready for Live'. 4 Edit the transport configuration file on the Content Manager machine to send out content over secure FTP by adding an SFTPSender (the existing FTPSender remains unchanged). 5 Test transport to the live server by publishing a page with Component Presentations and the workflow status set to 'Ready for Live' to the Target Type and checking if you can view the result on both the staging and live servers. Publish all approved content it to create a complete Web site, then make the live server go public. 40 SDL Tridion R5