What has changed the most – or rather the most obvious change – is the Content Manager Explorer also known as the Tridion GUI. In 2011, apart from running on all the major browsers and also an iPad, it features a redesign that will be familiar to existing users but also taking on board lots of new usability features.

One of the nicest features of the new interface is the ribbon toolbar. On the current version of Tridion, the buttons on the toolbar are somewhat hard to see and can make it difficult to see what the particular button is supposed to do. The ribbon features a big icon and some text as well which should make finding the function you want easy.

If you don’t like the ribbon you can always collapse the ribbon down to the more traditional row of icons.

Two more features I would like to highlight. Gone are the tabs on the publishing queue and it now shows you all options in the same area. It’s common for me to forget that I have other options on the other tab, so having them all in one place is better for the old folk like myself.

And then lastly I want to show you another nice feature. Error messages in-line to the interface, so now the option to feed more back to the user about what is going on. If you missed a message, you can also get a list back of the message history.

What is publishing?

In short, Publishing is the mechanism SDL Tridion uses to put content on a presentation environment. Content and Templates are rendered together and HTML, XML, JSP etc. comes out the other side. When you chose to publish something, you start a chain reaction that sees your content successfully published on your website. During that process SDL Tridion makes sure all your dependencies are taken care of. That single item you chose to publish might lead to a few more items being published so that the website has no errors or inconsistencies in the content.
There are a number of factors that influence how publishing behaves and how you, as a user, can get along with it. The basic factors are:

• The implementation
• The content
• The hardware

So what do we want from publishing?

Mostly you want content there as soon as possible so you can move onto the next task. However, there are allot of other people doing the same thing and on large scale environments or environments with challenges on performance you might have to queue up.

So what can you do?

You need to publish content in a way that ensures the least stress and maximizes the available time for publishing. So I have gathered here some tips that might help you.

Publish Structure Groups

When you publish anything in SDL Tridion, the number of items you select in the Content Management Explorer equals the number of jobs in the publishing queue. Each job in the queue must be completed separately and therefore has all the overhead of being treated as a separate job. However, if you want to publish allot of pages, for example; part of your site, then it makes sense to publish the Structure Group rather than all the individual pages. It will take just as long to get the task done, just with less overhead. If you are worried about failures then use the failure tolerance setting on the Advanced tab of the publishing dialog.

Use priority publishing

Most users have found the priority option in the publishing dialog. It allows you to change the standard priority to change how the publisher will pick up your publishing job. High = it goes first, Low = it goes last. Normal is everything in between. Using Low priority is handy to be able to use the available publishing time of your servers without getting in the way of normal work. So for example, you need to roll out a future site to Staging; then use low priority publishing. It will get there as soon as the publishers have time to deal with it.

Publish on off peak hours

I looked at the number of items published per day for one of my customers recently. It went like this.

• Wednesday: 16952
• Thursday: 21829
• Friday: 13279
• Saturday: 1
• Sunday: 14
• Monday: 1527
• Tuesday: 2681
• Wednesday: 357

Notice anything? Many items that could have been published were not because they did not use the weekend. The servers were not turned off; they sat there wasting that publishing time for nothing. So, scheduling a task for the weekend (or even evening) could make better use of the time available.

Publish to staging or live but not to both

Too often I see publishing jobs in a queue that are the same item but going to two different places and those two places are often Staging and Live. The staging site does need to be up to date, but Live is much more important and the process should be that once you are satisfied with your content you publish it to live, so why republish it to staging? If you must publish to staging then make it low priority or maybe schedule a complete republish to Staging in the weekend (see above). To enable low priority publishing all the time you can set the default priority to low on a Publication Target. That way all jobs going to Staging would be low priority and you never need to remember to set it.

Check the details of what you are about to publish

Before you publish, take a look at what will publish and make sure it is what you expect. You can do this using the “See items to Publish” button in the bottom left of the publishing dialog.

Plan your roll outs

When rolling out websites, plan how you are going to do it and leave enough time to get everything done without impacting regular business.

A watched pot never boils

Refreshing the publishing queue frequently might give us the satisfaction that we know that the job was completed as soon as its status is changed to “success”, but in reality it does not make the job go quicker. You might also want to change the filtering options so you only see your own successful tasks.  And do not forget, if it is in the queue, it will get published; it just has to wait its turn.

I extend my congratulations to my fellow MVPs and hope for good things in the future…

You can learn more about the MVP awards for SDL Tridion and see the full list of recipients on SDL Tridion World.

Last week I attended a seminar organized by Hinttech on Agile Tridion Development. The seminar and its participants discussed the use of Agile development methods when creating sites with SDL Tridion. Agile development is something more and more customers are asking for but then how does that fit into a Tridion project? Laurens Bonnema was on hand to give his view on Agile development and how it should and should not be used. Robert Quaedvlieg from SDL Tridion was also on hand to give a view on where Agile might fit into the SDL Tridion Implementation Methodology. The Implementation Methodology is essentially a SDL Tridion variant on the traditional Waterfall model. This is the traditional project methodology and lends itself very well to projects where we need to (or do) know what we are going to build up front. Agile tends towards situations where we do not know the requirements at the start. My aim here is not to explain Agile development – you need to read one of the many good books or even Wikipedia to get a good short explanation – However, I will lay down some very basic concepts so that the rest of this document is clear. Typically, you do not know the complete requirements up front and part of the Agile process is to define the requirements or backlog. These backlog items are organized into sprints and at the end of each sprint the development team has a working product (with the features worked on for that sprint). In theory that means you have something deliverable at the end of each sprint and, in my view more importantly, you are fully away of the progress you are making. There is more to it than that but the important factor is that the priority of development can be changed at anytime without having to go back and change a monolithic requirements document. At the end, you should have a product that is what you want at the time you want it. Rather than a product which you wanted when you made the requirements.

So how does a Tridion project fit into this?

Looking at any regular Tridion project, there are a number of things that look to fit well into an Agile process and others which do not. Some of the things that do not, I do not think every really could fit well into Agile development, probably because there is nothing to develop, more something to be worked upon. However, even those things can be injected with Agile juice to make them flow easily next to the sprints.

Ignoring the Tridion Implementation Methodology, I will outline some of the various parts of a Tridion project and whether or not I think you should approach them in an Agile (A), Semi-Agile (S) or Waterfall (W) way.

Organisational
Organisational aspects of a Tridion implementation are key to ensuring a successful project in the long term. Like any organizational structure it should focus on the long term and will be the foundation on which this and future projects are built.

Content Management
There are two parts to any CMS implementation, the creation of a Content Management environment and then the application to consume the content. In creating our Content Management environment we decide how we are going to manage content both functionally and structurally.

Content Consumption
Consuming the content is a very general topic; it can take any form from a simple .NET application to a MVC framework or webservice. The consuming application’s job is to take deployed content and present it to the user or another application. It is very much a technical coding exercise

Infrastructural & Integrations
These sorts of activities tend to involve a large amount of people and a very rigid process model. It makes agile work in this area very difficult and you would generally meet stiff opposition.

Additional Thoughts
Many standard engineering practices should be implemented that will help you in being agile. These practices stem from traditional development practices but are often overlooked. What is important in each sprint is that all the work you have done has broken nothing from any previous sprint, so structured testing can help you achieve this. Unit and UAT testing can both aid the development process and ensure a quality product. UAT testing can also ensure that the content management environment will work well for the content editors. Getting the editors in and letting them have a play early on might just ensure that they accept the application when the last sprint is complete.

Overall you need to use common sense (in this I very much agree with Laurens). Agile is not the way to solve all evils. Not only are some things just not possible to do Agile but some people cannot (yet) do agile.

On SDL Tridion’s website they have released information on the upcoming release SDL Tridion 2009. Together with that there are some screenshots of the new interface. Here is one of them, go along to the website to see the rest of the screenshots and read the rest of the information on the new release.

I would be interested to hear thoughts on the new interface. If you want to comment, feel free below.

You can view these articles on SDL Tridion World and they are:

What is the SDL Tridion Object Cache?

and

Using SDL Tridion Object Caching With Apache Active MQ

Now, next to Day the CMS vendors have been posting their scores. Currently the leaderboard looks like:

1. 44/45 – e-Spirit ***
2. 43/45 – Jahia
3. 43/45 – Hippo CMS
4. 42/45 - Magnolia
5. 42/45 – EPiServer
6. 42/45 – GX *
7. 42/45 – Midgard
8. 42/45 – Nuxeo **
9. 41/45 – infopark
10. 41/45 – KnowledgeTree
11. 40.5/45 – Enano
12. 40/45 - Day
13. 40/45 – Alfresco
14. 40/45 – GX
15. 40/45 – CoreMedia
16. 40/45 – Sitecore
17. 40/45 – Alterian
18. 40/45 – OpenText
19. 40/45 – Ez Systems
20. 38/45 – dotCMS
21. 37/45 – Vignette
22. 37/45 – Autonomy Interwoven
23. 36/45 – Escenic
24. 33/45 – Sense/Net

• bold scores are where the vendor did not score themselves but it was subsequentally worked out by Jon Marks
• * Score adjusted to reflect original scoring system
• ** Vendor does not seem to be able to add up
• *** Was 45, now 44

Many of the answers to the checklist are very tongue in cheek but many of the questions do not really go deep. Mostly the questions surround how available software is either to download, easy it is to install or how clear the pricing is. These are indeed important things but I do feel the list missing something more concrete. Only two of the questions (3 & 7), for instance, address something to do with content editing. Surely this is one of the most important areas to cover and thus deserves more attention?

Of course this list is not a complete check list, but it seems more tuned towards vendors such as Alfresco as most of these types of vendors will probably score highly. However, it is nice to see the vendors interacting together and at least, it seems, giving honest scores.

Update 19/03/2009: Adding the meme ID 9c56d0fcf93175d70e1c9b9d188167cf suggested by Bertrand Delacrétaz. Find more related pages on Google.

Update 19/03/2009: Added infopark

Update 19/03/2009: Added dotCMS and Midgard (no scores yet though)

Update 19/03/2009: Added Vignette (no score either)

Update 20/03/2009: Added Nuxe (finally a score!)

Update 20/03/2009: Updated Escenic’s score

Update 21/03/2009: Added Sitecore’s, EPiServer’s & OpenText’s scores

Update 22/03/2009: Added Autonomy Interwoven (no score)

Update 23/03/2009: Added Alterian & Hippo CMS

Update 25/03/2009: Updated scores according to Jon Marks blog

Update 27/03/2009: Added KnowledgeTree

Update 02/04/2009: Added Enano

Update 03/04/2009: Added Ez Systems

Update 09/04/2009: added e-Spirit & Sense/Net

Update 15/04/2009: Updated e-Spirit score

Why monitor publishing?
Publishing is critical to an organization’s ability to respond to changes in their online presence. It is crucial that the workload of the publisher is monitored for performance and load. In this case we will look at one part of the publishing, the length of the queue.

Backlogged Queue
In the event of a failure the publishing queue is likely to become backlogged with publishing requests; in this case the total number of items waiting will only rise. However, it can also be that allot of items have been submitted to the queue either by mistake or as part of a republish process. In that case we might want to take action (remove or monitor) and in order to take action we need notification.

Application Monitoring allows you to extend the features of its monitoring; one such way it to add a HTTP Service Health Monitor. Basically this calls a URL and processes the response for a known string. This string does not have to say much just it has to be what Application Monitoring is expecting. If the response does not say what it is expected and error is raised. That error can be trapped using SNMP and after that System Administrators can be notified.

So in our example we want to raise an alarm when the number of items in the queue gets above, say, 100. To do this we need to check, through the Tridion API, what the current count on the queue is and then respond accordingly. When everything is fine I want my page to say “Monitoring TestPage”. When the queue is too long I want it to say something else and in this case I want it to tell me what the state is. So something like: “Error, number of items in the queue exceeds limit. Queue is now at: 4000000 of a max of 100 items”.

The code
Using the COM Interop for .NET you can do this from a .NET application. As we are using a webpage to display this result it should be an ASP.NET page but it could equally be written in any language.  For this example I will cover the basics of what you can do. For the complete example, see the download.

I start by importing the namespaces of the COM Interop as well as the XML handler:

<%@ Import namespace="TDS" %>
<%@ Import namespace="System.Xml" %>

Next we want to create a new TDSE object of Tridion, XML Document and Node List:

TDSE tdse = new TDSE();
XmlDocument itemsXmlDoc = new XmlDocument();
XmlNodeList itemNodes;

Next we set the user we want to use for accessing Tridion, in this case the REMOTE_USER and initialize TDSE.

tdse.Impersonate(Request.ServerVariables["REMOTE_USER"]);
tdse.Initialize();

From that we are authorized to Tridion and can then get a ManagementInfo object which will enable us to look into the queue of Tridion:

ManagementInfo managementInfo = tdse.GetManagementInfo();
ListRowFilter filter = tdse.CreateListRowFilter();
filter.SetCondition("InfoType", queue);

List row filters (above) enable us to filter the results, in the case the variable queue specifies a string which is the queue we want to look at. Using the filter we can call GetListPublishTransactions and load the resulting string as XML:

String itemsXml = managementInfo.GetListPublishTransactions(filter);
itemsXmlDoc.LoadXml(itemsXml);

Once we have done that we can select the elements that represent the publish tasks and display our text:

itemNodes = itemsXmlDoc.SelectNodes("tcm:ListPublishTransactions/tcm:Item", namespaceManager);
int itemsCount = itemNodes.Count;
if (itemsCount > maxItems) {
%>Error, number of items in the queue exceeds limit. Queue is now at: <%=itemsCount%> of a max of <%=maxItems%> items.<%
} else {
%>Monitoring TestPage<%
}

Once we have created and tested our page we need to add it to Application Monitoring so it monitors this page for changes.

Configuring Application Monitoring
Application Monitoring is configured through the configuration file cd_monitor_conf.xml which is located in the directory %TRIDION_HOME%\bin. To monitor a queue we need to add the following to the ServiceHealthMonitors section:

<HttpServiceHealthMonitor ServiceType="Publishing Queue Length - WaitingForPublish" ServiceInstance="local" PollInterval="5m" TimeoutInterval="30s">
<Request URL="http://localhost/MonitoringView/Monitors/publishqueue.aspx?queue=1&amp;max=100"/>
<Response SuccessPattern="Monitoring TestPage"/>
<Authentication Scheme="NTLM" Host="host" Domain="myhost" Username="administrator" Password="tridion"/>
</HttpServiceHealthMonitor> 

This element tells Application Monitoring to periodically monitor the URL specified for the specified text. Of particular interest are the ServiceType (the name of the service which you can change) and the PollInterval.

The PollInterval specifies the amount of time between checks of the status of this queue. It should be short enough for you to react to any change in state but long enough not to overload the server.
Our URL can also be configured. The URL has two parameters, queue and max. Queue is the string (actually an integer but this is a URL so it is actually a string) that identified the queue being monitored and is specified as follows:

• 0 = Scheduled for Publish
• 1 = Waiting for Publish
• 2 = In Progress
• 3 = Scheduled for Deployment
• 4 = Waiting for Deployment
• 5 = Failed
• 6 = Success

The max value simply indicates what the maximum number of items to allow in the queue before the alarm is raised.

Once configured you should restart the Tridion Monitoring Service and check the URL of the Application Monitoring webservice:  http://localhost/monitoring/TridionMonitoringAgent.asmx. If you do this from the localhost you will have the option to invoke the webservice and get a XML response back. In this response you can check your new monitor is responding correctly.

Using this Monitor
There are two basic ways to use this new monitor together with your standard monitors:

• Write a application to read the Application Monitoring Webservice
• Setup a monitoring application that can catch SNMP traps

In the case of the latter, all the monitors including the one we have setup will send SNMP traps when the state changes. This allows you to integrate this monitor into any existing infrastructure management processes.

Download
Download the files for this article here.

More information
You can find more information on Application Monitoring by checking the R5.3 documentation or visiting the SDL Tridion Forums or SDL Tridion’s community World. You can also find this article on SDL Tridion World.