for birds • for people • for ever

Content Broker – how and why we are using it at the

RSPB

Chris Wells & Graham Bird

Introductions

• Chris WellsInformation Systems Engineerchris.wells@rspb.org.ukPart of Information Systems who manage our Tridion installation

• Graham BirdSenior Web Designergraham.bird@rspb.org.ukPart of Web Team who design, build and edit website

Before we begin• We’re not claiming to be Content Broker experts

– We’re users• About our experiences with Content Broker

– May not be best solution for everyone• Just dynamic content assembly

– Not Personalisation or Profiling

Background - RSPB

• UK charity• Aim: to conserve wild birds and the environment• Over a million members• Over 1,600 staff and 13,000 volunteers

• www.rspb.org.uk• 2,000,000 page views per month• 14,000 visitors per day

Background - Tridion• Current installation is R5.2

– Using Tridion since September 2002– 3 active publications (Master, Website, Intranet)– 172,000 components created so far– Around 90 active devolved authors– Average of 125 items published per day (during Sept 07)

• Website is ASP-based with some ASP.NET applications– 2 presentation servers (Windows 2003 with IIS6)

• Load Balanced with ServerIronXL– Database - Windows 2000 with MS SQL 2000

• Windows Clustering

What does Content Broker do?• Stores rendered component presentations in database on

web server– eg list version, full version, RSS version– Also stores keywords and custom metadata

• Dynamic content assembly– Add components to pages at runtime (components aren’t actually on the

page)– Simple queries (eg 10 latest news items)– Plus keyword/custom metadata queries (in Bedfordshire)– Return one item by specifying combination of Component ID & Component

Template ID

• As part of WAI, also does Personalisation and Profiling– We are not using these yet

Without Content BrokerEditors:

• must put component on multiple pages

• need access to Structure Groups

• must publish pages in the correct order

• need to create a new page for every component

• should avoid unpublishing components

With Content BrokerEditors:

• just publish the component (faster and simpler)

• don’t need to create any pages (less to remember, simpler permissions)

• can unpublish components (aren’t on pages so no risk)

• but no SiteEdit

Our situation• Standard “static” publishing

– Difficult to create dynamic and/or date-based designs– Workflows can be complex (placing component on multiple

pages and publishing them all)– Need to publish at least two pages to put something live

(index version and full version)

• Also XML pages as data sources for jobs, events, etc– Using this method to create dynamic functionality– Hundreds of components on each XML page– Publishing takes a very long time– A single text change requires a re-publish

of everything

What we hoped to achieve• Faster publishing

– Publishing individual components (much faster than XML page)– Simpler, more reliable workflows– Unpublish components without risk

• Less maintenance of web pages– List pages and RSS feeds take care of themselves– Less pages to worry about (just one full version page)

• Increased ownership outside Web Team– Less for editors to learn/remember– Editor permissions easier to set up

• Improved user experience– Near you: multiple types of keyworded content– Search and filter with keywords

1. Added keyword field (county) to schema and moved date fields to MetaData tab• Ran custom script to populate keyword

and date fields in existing components

2. Changed component templates• “Published as a dynamic component”

3. Wrote query code for job list• Our own custom query (because of lack

of sorting on non-system fields)• Used query for RSS feed

4. Changed workflow script• Publishes component and unpublishes

when past job expiry date to reduce size of database (speed up queries)

5. Re-launched

Example: Converting our jobs pages

What we achieved• Faster publishing

– No more XML pages clogging up the Publishing Queue

– Components publish in a fraction of the time

• More devolved ownership– And less training/support required

• Improved functionality for visitors– Filtering, “Near you” page

• Bonus: reduced development time– Adding new “Brokerised” sections to the site

– Creating alternative formats (eg RSS)

Key benefits• Fire and forget publishing

– Editors don't have to remember to add components to multiple pages

• Faster than publishing pages• No danger of inactive dynamic links• Can unpublish safely• Fewer pages to maintain (easier to change)• Re-use of code for future “Brokered” areas

– Queries likely to be very similar

– Easy to create alternative formats (eg RSS)

• Simpler workflows

Issues we have encountered• Cannot sort on non-system fields

– Only Created, Modified, Published, etc. Not your own fields.– Can get around this by sorting in ASP or custom queries

• Performance– Not as fast as we would like– Memory usage grows– Significant load on database– Sometimes no items returned (could be our replication?)

• Documentation– API confusing/not documented well enough– Not enough examples

• Can only query MetaData fields and keywords– Would be nice to indicate CB fields in Schema

• 255 char limit on MetaData fields– But can be changed in database

Lessons learnt• Need to load test and performance test

– Were foolish to assume that performance on staging would be similar on live, but didn’t expect such a big drop in performance

• Turn on caching– cd_broker_conf.xml

• <ObjectCache Enabled="true">

• Cache Channel Service– syncs caches

• Dynamic Component Presentation Storage– Cd_broker_conf.xml

• <Publication><Dcp><Asp Location>

Our plans for the future• Resolve our current issues

– Busiest time of year in January (up to 10x normal traffic)

• Refine custom queries– For even more speed

• Roll out to more content types– Conservation Projects– Intranet Directory

Conclusion• Content Broker

– is a convenient, fast way to publish content– can simplify devolved authoring and workflows

• But…– watch out for performance issues– documentation could be better– you may need custom queries– no SiteEdit because components

aren’t actually on the page