Tridion Content Broker - how and why we are using it at the RSPB (2007)
•Download as PPT, PDF•
0 likes•753 views
This document discusses the RSPB's use of Content Broker to dynamically assemble content from Tridion components. Some key benefits are faster publishing, less page maintenance, and more flexible authoring workflows. Initial issues included slow performance, limited sorting capabilities, and lack of documentation. Lessons learned include the need for load testing and caching. Future plans are to address performance and expand use of Content Broker to more content types.
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Tridion Content Broker - how and why we are using it at the RSPB (2007)
Similar to Tridion Content Broker - how and why we are using it at the RSPB (2007) (20)
Recently uploaded
Recently uploaded (20)
Tridion Content Broker - how and why we are using it at the RSPB (2007)
- 1. for birds • for people • for ever Content Broker – how and why we are using it at the RSPB Chris Wells & Graham Bird
- 2. Introductions • Chris Wells Information Systems Engineer chris.wells@rspb.org.uk Part of Information Systems who manage our Tridion installation • Graham Bird Senior Web Designer graham.bird@rspb.org.uk Part of Web Team who design, build and edit website
- 3. 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
- 4. 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
- 5. 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
- 6. 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
- 7. Without Content Broker Editors: • 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
- 8. With Content Broker Editors: • 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
- 9. 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
- 10. 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
- 11. 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 1. Changed component templates • “Published as a dynamic component” 1. Wrote query code for job list • Our own custom query (because of lack of sorting on non-system fields) • Used query for RSS feed 1. Changed workflow script • Publishes component and unpublishes when past job expiry date to reduce size of database (speed up queries) 1. Re-launched Example: Converting our jobs pages
- 12. 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)
- 13. 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
- 14. 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
- 15. 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>
- 16. 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
- 17. 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
Editor's Notes
- Introductions
- Chris
- Chris Not claiming to be Content Broker experts. We are just users of Content Broker. We are learning as we go. This is what we have learnt - our experience - we are still learning about Content Broker. This covers the use of Content Broker for dynamic publishing alone, not Personalisation or Profiling. Not suggesting that Content Broker was the best solution for our problems but it was the one we chose and this presentation is about what happened – not best practice.
- Chris
- Chris What relevant information should we include about tridion? No of components, Publications, Templates? We have used it since Dialog Server days? ASP.Net used for membership, donations, etc Replication between servers?
- Graham How does it work? Stores rendered component presentations in a database on your web server (Oracle, SQL Server or IBM DB2 according to Tridion docs). What does “rendered component presentations” mean? Not data in the database tables. Instead, chunks of pre-built HTML that can be pulled out of the database and put onto your pages. However there are keyword fields that allow you to filter your results. Multiple rendered templates for each component in the database (if you want data you could create XML/CSV templates) What does this enable you to do? Dynamic content assembly – components aren’t put on pages in Tridion. They are added to pages at runtime. Rather than you specifically choosing what components you want in the GUI, the pages on the web server ask for components based on a query. List pages are done in this way (eg latest news) You can also give Content Broker a component ID and a component template ID to drive pages that display a single item (eg full news story) What else? Personalisation – returning items based on explicit user preferences Profiling – returning different items based on user behaviour
- Graham Without Content Broker Tridion publishes static web pages out to the web server as normal. Very familiar publishing model. But…there are downsides Focusing on Editors: Put component on multiple pages – the index page with the link template and the details page with the full version. Publish pages in the correct order – full version first otherwise you end up with inactive dynamic links Create a new page for every component – time consuming (and they need access to pages and structure groups) Avoid unpublishing components – because they can inadvertently unpublish pages
- Graham With Content Broker Editors: Just publish component (faster to publish, simpler task) Don’t need to create pages to put the components on (less to forget, don’t need permissions, less time consuming) Can unpublish components (no risk of accidentally unpublishing pages) But…can’t be SiteEdited because the components are not actually on the page (there might be a way to do this, but we haven’t investigated it yet)
- Graham Our situation What we were doing before we started using Content Broker… Standard static publishing It’s difficult and fiddly to manage sections of the site that change often. Eg a latest news page has to be edited every time a news item is published (along with archive pages as well) Can be done with Workflow, but gets complicated and, if editors are finishing items in quick succession, Workflow can trip over itself (not finished previous activity when asked to start a new one). XML pages as data sources We were using this method to create database-driven dynamic pages. Publishing Tridion pages with XML page and component templates. But… Code was pretty complex (need to know how to process XML files and some XSL) Hundreds of components on a page meant it took a very long time to publish and everything had to be re-published if one component changed. With our Event components, we ended up having to break the XML file into several pages because there were so many components that it wouldn’t publish at all (hit a limit in Tridion that has now been fixed) Not tenable in the long run – we needed a front end database!
- Graham What we hoped to achieve Faster publishing – not republishing everything every time something changes Simpler workflows – since the workflow script only has to tell the component to publish, it won’t trip over itself anymore Can unpublish components (expired jobs, old events, etc) without worrying that it will delete parts of the website. A truly database driven site Less maintenance – only one details page rather than one for each component List pages update themselves as soon as a new component is published (in multiple places around the site – eg our new footer which has latest news on every page of the site) Better experience for our devolved authors – less to do, less to remember/forget. Now they only have to publish the component. Don’t have to add it to pages too. Improvements to website - Same keywords on different schemas allows us to create pages of aggregated content – like Near you (county-based page that returns local events, news, jobs, places to visit, etc)
- Graham Example of our most simple Content Broker-based area of the website – Job vacancies Really not much to do. Probably the bulk of the work was populating all of our components once we had made the schema more suitable for Content Broker. Schema changes – moved date fields to MetaData tab (otherwise not added to database) and created a county keyword for filtering purposes. Could have added other keywords - “Full time/Part time”, “Intranet/Website” but not necessary. Component templates stayed the same. Just had to change the dropdown to say “Published as a dynamic component”. Wrote new code for the list page and the full details page. Very straightforward once we understood the API – but not easy because documentation not great (talk about that later). Made workflow simpler – and added an Unpublish job for the day after the job expired (keep number of results down) Had to slightly re-train Editors but they were happy to learn that it was simpler. That was it.
- Graham What we achieved by using Content Broker No more huge XML pages sitting “In progress” for half an hour. Much less stress for Web Team (aren’t held to ransom by a devolved author fixing a typo on an Event). Because just publishing individual components, they’re done in only a couple of seconds. Increased satisfaction for devolved authors – less phonecalls about how long it’s going to take before their item is live. Easier to devolve and less training/support required. Has resulted in more devolved authors around the organisation. We can improve experience for visitors (Near you page, updates aren’t waiting for editors to create pages, no inactive dynamic links, filtering options) Bonus: reduced development time – code for new areas of the site using Content Broker is virtually identical Can also easily create alternative formats such as RSS – just copy and paste the query and change the template ID.
- Graham Key benefits Fire and forget publishing – the component will automatically go where it needs to go. Editors don’t have to think about it. Faster because not publishing several pages – just the component No danger of inactive dynamic links because the details page and list page are updated at the same time Can unpublish Fewer pages for Web Team to maintain – makes it easier to make changes Code can be reused easily. Workflows are as simple as can be. Handover to Chris…
- Chris Working with Tridion Support to try and deal with a number of these Performance – Initial performance was terrible until we discovered Caching Even with caching on the load that Content Broker puts on the server is significant. Heavy Database Use – Extremely high level of database transactions – multiple database calls per dynamic component presentation. Inefficient queries also requiring multiple database calls. Memory – appears we have a memory leak in cd-wai service. Failures – tends to fail invisibly – just brings back no data Documentation – very factual and technical – lacks overviews, best practice, strategies for implementation or checklists. Can be very confusing Cache Tuning – very little information about tuning the size of the cache Issues with Content Broker Caching has to be turned on otherwise performance is terrible. Intermittently brings back no results (under load/high traffic?). Memory use heavy. Documentation very sketchy and confusing.
- Chris Turn on Caching Cache Channel Service
- Chris Resolving Current Issues Easy to create RSS feeds Easy to move from one item to another - two similar micro templates. Custom Queries – develop custom optimised queries for most used Content Broker Queries – consider bringing back component presentations straight from SQL Server.
- Chris We have been using Content Broker in anger now for 8 Months Continuing to Learn about it Happy to answer questions at breaks or at lunch