“WOAH! Thanks for the warning!! Is that one of the subjects? Or are you doing 45 mins on that one?”

Written by my colleague Ian (@IanTruscott) in reply to a discussion on what our Innovate session was on, I was slightly offended at first. Not least because he seemed to question that anyone could talk for 45 minutes on that topic alone… Stepping back from his laptop at the pure geekiness that he saw in our slides, no doubt Ian spilt his coffee and stepped on the cat (if he had one, which I think he does not. He looks more like the dog type).

But, in a moment of defiance (yes, I am talking it up to make myself feel better), I am proud to be a Tridion geek and one that will present on Friday, together with my colleague Nuno Linhares (@nunolinhares). Forming the final presentation of the the day, the session that separates once willing participants from the bar/plane/hotel bed/dinner, we’ll talk about SDL Tridion, Amazon and Mongo DB all in one 45 minute action pack roller coaster of a presentation. You must see this, even if it is just to see our demonstration fail terribly – I must remember to pray to the demo gods on Friday morning!

SDL walks us through the Customer Journey

On Tuesday the SDL Tridion Benelux User Group had it’s first session in Belgium. Historic Leuven, to be exact, is home to Amplexor who where hosting the event for the evening. The group was small but the discussion was lively and interesting. The opening session was by SDL, walking us through the customer journey in a whiteboard session; the picture slowly building to show the touch points, challenges and opportunities in that customer journey for both the visitor and the organization alike.

Following this session, Davy Moortgat from Amplexor presented SDL Tridion and the mobile web. A good presentation highlighting different approaches to mobile with SDL Tridion. You can find the slides at the bottom of this post.

And finally, what meetup would not be complete with some drinks and networking!

Many thanks to Amplexor for hosting the event, I look forward to many lively and interesting user group meetings in Belgium!

Slides:

• SDL Tridion and the mobile web

Our master or ceremonies was Ingmar Umans who did a great job in making sure the group moved between drinks and the next presentation. The evening was opened by HintTech CEO Egbert Hendriks with a view on why HintTech does not do SDL Tridion but still does. Following that Bjorn van Dommelen gave us an overview of how to deploy SDL Tridion onto Azure. A great presentation filled with insight, practical tips and dry humor! With Quirijn Slings (and his DD4T presentation) falling out due to sickness, Bart Koopman stepped in to show the group a new feature of SDL Tridion 2013, External Content Libraries.

All presentations were well received and for those who missed it, you can find links to the presentations at the bottom of the page. Following that lots of drinks and networking made the evening very much worthwhile and I, for one, am looking forward to the next event.
If you’d like to join the user group events in the future or just interact with your peers in the Benelux, you can join the SDL Tridion User Group Benelux on LinkedIn

Slides

• External Content Libraries
• Tridion in the Cloud – Using the Microsoft Azure Platform

In SDL Tridion 2009 particularly and 2011 less so, the deployer can be a bottleneck when you are trying to publish large volumes of content to your websites. Since the outset of SDL Tridion, customers have been growing in volume demand for updates to their websites. Moreover, the timeliness of the updates is become more and more important. The major difference between 2009 and 2011 is that 2011 is multi-threading, meaning that a single deployer can deploy more than one item at a time. Does not sound like much, but the multi-threaded change allows an ever larger amount of content to be published. However, it does need to be setup well and more over tested. If you want the best out of your publishing you must test the setup well.

Typically, when you ran up against the deployer bottleneck in 2009 you implemented multiple deployers. This you can still do in 2011 to get yet more throughput (because you add multi-threaded, multi-deployers). However, there are various things you need to take into account in order to ensure that you don’t run into problems.

If you read Chris’ article you get the idea of how you do this. However, I must make some corrections. The overall setup is fine but as Chris notes you can run into race conditions of multiple deployers trying to update the same content at the same time. For this reason, the setup described is not supported; you will get failures. However, there is hope! To avoid the race conditions you need to modify the setup as described in the blog post.

What is described in the post is that you have multiple deployers that are deploying all content from all publications. Instead you must have multiple deployers that are in their own right dedicated to publishing content of given publications. For instance, if you have 10 deployers you must split the publications you are publishing over each of the ten and not have any duplication. For example:

• deployer 1
  • publication a
  • publication b
• deployer 2
  • publication c
  • publication d
• etc…

This configuration you do in your publishing targets on the Content Manager and for simplicity sake  each of your deployers can be configured 100% the same.

For the SDL Tridion User Group (STUG <- do we like that?), we held our first user group for the Benelux. There have been two user groups springing up in the last year elsewhere in the world and this is the first for the Benelux. Dominic Cronin, of Indivirtual, and I decided to see if we could start one up for the wider community. Not really with a view to run it ourselves forever but to see if the community would like one and if there was enough enthusiasm to continue to hold events and sessions. Our first event – sponsored by Indivirtual and SDL, went well and around 20-25 people attended which was spot on for our target of attendees. We introduced the session and then let SDL Product Manager, Alexandra Popova, give us an overview of the 2013 release. After that we dived, in groups, into what we want from the user group going forward. Below you will find the results of that session which gives us great input into the future of the user group.

• Experiences
  • Implementation Experience
  • Presentations real user experience
  • Find out what people are doing
  • Input from users
  • workshops
  • business cases
  • coding conventions/best practices
  • knowledge sharing
  • report ERs and discuss
  • users feedback / ichallenge!
  • Share Roadmap
  • Share Project Information
  • Share Technical/Functional Implementation
• Motivation
  • Free stuff / goodies!
  • Curiosity
  • Turn listeners into contributor
• Grow
  • More “real” users
  • Reach out, promote to functional
• People
  • Who is who
  • interaction
  • networking
  • More functional
• Event
  • Time of day?
  • Technical sessions
  • Inside info SDL
• Peers
  • Peer review/advice
• Product
  • Roadmap
  • hands on workshop
  • pre-configured VMs

Going forward, we plan to hold one evening session per quarter and perhaps additional sessions on other topics (technical deep dives) or social events in-between the quarterly events.

To be involved you just need to turn up to one of the events we hold and you can find out about those by joining our SDL Tridion User Group Benelux LinkedIn group.

View from the hotel

Day 3 was short as it was the fun, event day for the MVPs. In the morning we continued with our development activities and then wrapped up on the MVP sessions so far as well as the work on the projects.

After lunch we headed to the sea to take a ride on an old Dutch style sail boat. The traditional boats in this area of Portugal, are in fact shared with the Dutch traditional boats that the two used to trade salt in centuries past. The boat trip was a slow cruise, under sail, along the coast which ended in anchoring near the shore for three enthusiastic swimmers to have a dive. It was really nice and super relaxing. Tomorrow, we can relax and continue with the coding.

Via Chris Summers (@UrbanCherry)

Team Content Bloom and random Spanish MVP

Day 2 has ended… at some point on Day 3. The majority of the MVPs worked a 12 hour shift of coding and creating new and fantastic pieces of code and some spent the same time trying to add a button. It was, I will be honest, not a place where a button normally should go but they were in the end, successful.

The group split into three teams and worked on three separate things; Gamification, Workflow Notification and Extending the dashboard (needed for the first two projects). Progress was good and work will continue into day 3 and 4.

The evening was the highlight, MVP drinks are often fun and this time we spent most of the time inventing SDL Tridion related cocktails. In no particular order I managed to write some of them down but it is not the complete list;

• The MVP – Vodka (2 parts), a dash of Pims and a dash of Martini Bianco. Review: it’s strong (owing to the fact that it’s mostly vodka) but tasty
• The Cache Channel Service – Cognac, Coca Cola and a splash of Bourbon (“slightly wild”, bourbon is the “S”) Review; really tasty and most definitely the most popular drink of the evening
• The TCM – Tequila, Cachaça and Peach Juice. Review: sweet but very tasty
• The Nude (named after Nuno) – Tia Maria, Baileys and Milk. Review; like a milkshake so one is enough for me
• The TCDL – Tequila, Drambuie, Coke Cola served Long
• The TDSE – Tia Maria, Tequila, Sour Domingo (I wrote this, not sure if it is correct) and something else I forgot to write down…

And needed to say there was much frivolity which from time to time turned into a jam session:

View from the hotel

From yesterday, in a castle somewhere near Lisbon, the SDL Tridion MVPs have come together to discuss the year past and the year to come. The SDL Tridion MVPs are selected by a community panel and they come yearly, from across the global, to mostly Lisbon to attend the meeting. Everyone flew in on Thursday, with some coming a long way and others making a short hop from near by European destinations and I can say everyone was tired from their travels.

The day was started after lunch with a review of 2012 from Nuno Linhares which covered what the community has produced as well as the work done on Stack Overflow and the campaign to have a dedicated Stack Overflow site for Tridion. There was a brief touch on the community webinars and what, if any changes, are needed for 2012-2013.

From a technology perspective Bart Koopman gave us an overview of External Content Libraries (ECL) for SDL Tridion 2013, which is a way of connecting external content into SDL Tridion for use with your regular Tridion content. This is a further development for the Documentum connector that SDL released some time ago.

It does not sound like much but it took a long time for us to cover and was all interesting. From the sessions, I have many questions and changes that I need to think about. High on my mind is how to expand the reach of the community past the size we have right now, a strong community but it is those on the fringe of the community and how we can get them strong as individuals in SDL Tridion. Not an easy question to answer but something to work on in 2013.

© barkbud (Flickr)

Granted, most of these chasms we created ourselves when we created silos between channels – competition even. When executives asked the online channel to compete with the call centre, the mobile channel with the good old websites…. They cooked the soup they now have to eat. (this is a German idiom that doesn’t translate well but I just love the picture…)

Some companies are doing an excellent job at connecting all channel touchpoints in a smooth and consistent way. These are companies who figured out the customer journey and took a good hard look at themselves through the customer’s eyes. KLM is one of those companies who “get it” and I am always impressed how well KLM executes on their customer experience strategy.

When I travel for business, my tickets usually get booked via travel agency through our office management – either online or with the agency call centre. I then get a confirmation and eticket from the agency via email. At pretty much the same time, connected via the loyalty program, the booking shows up in the KLM mobile app on my phone. From here – or, if I chose, from the KLM website – I can trigger status updates for my flights via email or SMS – it is MY choice. And, on a side note, in the language that I chose.

I check in online, of course, and send the fancy barcoded boarding pass to my phone. And to my tablet, because I am a bit paranoid about losing or forgetting either one of them. Sometimes, I have problems with the check-in and then I call the hotline and they know right away what’s going on and help me through.
At the airport, I tend to ask for a print-out of the boarding pass. That’s because once my phone ran out of battery power and I had left my tablet in the office. And that made me look really stupid at boarding – thus the paranoia.

Just recently, I was coming back from London to Amsterdam, and the fog in Amsterdam meant that we ran late by about an hour or so. I knew straight away from my mobile updates and hit the airport’s retail therapy, which at LHR is a pleasure. But when we landed on the furthest runway in Amsterdam (which is soo far away that it’s almost Belgium and taxying takes 20 minutes… For a 1 hour flight..) and I got home just after midnight, I was a little bit cranky. Not really with KLM, because they neither made the fog nor the Polderbaan runway (or did they?), but just with the situation as such.

And then, at home, my phone beeps at me and there was an email from KLM. It said that they are sorry about the delay and that they hope it didn’t cause me any inconvenience. And somehow that really made it better for me. It was so nice they cared. So I tweeted how cool I thought that was. And guess what, KLM replied straight away to say thank you and that they were glad it all worked out in the end.

Wow. Seriously, how awesome is this? The entire customer journey glued together by e-ticket, booking code and customer loyalty program. Customer Experience Management at it’s best.

What is KLM doing right?
Firstly, they understand what’s going on with their customers at the different stages of their journeys.

Secondly, they invested some serious thought and money into making this journey more pleasant for their customers.

Thirdly, they make use of all the channels they got, employing each channel for the right thing – forming one consistent brand image.

Last but not least, they encourage dialogue through their social channels – and by that create brand ambassadors who share how awesome KLM is.

Thank you, KLM, for this great example.

Guest Post

Sonja Keerl 
Sonja is in the online business since 1999 and a passionate voice for Customer Experience Management. She has helped many large global companies with CMS implementations, global rollouts and multichannel strategy. Sonja frequently speaks on industry events. Sonja currently works for SDL WCM as Senior Product Marketing Manager and is engaged to Julian.

There are allot of use cases that might be applicable to you using the information stored with all publishing jobs so it might be worth while picking up the documentation and taking a look. Between 2009 and 2011 .NET APIs there have been allot of improvements but the main one is that in 2011 you can access all data from API calls rather than loading up the publish transaction XML and surgically picking out what you want to know.

One use case that I know the best here is measuring the performance of the content being rendered. For a customer, we wanted to know how quickly everything was being rendered on a per item basis. We also wanted to gather data for longer term analysis (e.g. are we improving the overall performance on a day to day basis). To do this, we extract the data from the queue for a given day in a pipe separated format for import into excel. Overtime we have built a very complete picture of the growth and performance of publishing.

Now before I dive into code I have to declare that I am not a programmer, I am a Technical Account Manager which was likened last week to being retired from being a consultant. So my skills are not as good as some people I could mention (in fact those that implied that I was retired from useful things). However, it works! And for this that is the most important thing.

So, to look into the queue items you need to do the following steps:

1. Get the queue transaction list and loop it
2. For each transaction get the transaction itself
3. Dig around for details

In detail this looks something like…

Get the queue transaction list and loop it…

We need to start a session, get the list, get the XML document and then the nodes. This is the only XML related thing you have to do which is the plus over the 2009 API.

Session TridionSession = new Session(RemoteUser);
XmlElement QueueTransactionElement = TridionSession.GetList(typeof(PublishTransaction), QueueFilter);
XmlDocument QueueItems = QueueTransactionElement.OwnerDocument;
QueueNodes = QueueItems.SelectNodes(“tcm:ListPublishTransactions/tcm:Item”, GetNamespace(QueueItems.NameTable));

Lastly we loop the QueueNodes in a nice For loop.

Get the transaction

To get the transactions we need the TCM URI of the publish transaction (job) and then get the transaction object:

transactionId = tpq.QueueNodes.Item(i).Attributes["ID"].Value;
PublishTransaction publishTransaction = (PublishTransaction) TridionSession.GetObject(transactionId);

Digging Around in the mud

The transaction

So now we can see what we can get from a transaction. Let’s start with the basics and let’s assume we are just looking at successful publishing jobs.

So starting with some general details:

The Transaction ID: publishTransaction.Id

The ID of item being published: publishTransaction.Items.First().Id – This reveals the development path of the API, this is only ever one item but still there is an collection of items.

The Item Type being published: publishTransaction.Items.First().Id.ItemType

The title of the item being published: publishTransaction.Items.First().Title.ToString()

The priority: publishTransaction.Priority.ToString()

The purpose: publishTransaction.Instruction.ResolveInstruction.Purpose.ToString() – This is either publish or unpublish. According to the documentation, it should have a “re-publish” state but I can’t see to get this to work

Who published: publishTransaction.Creator.Title.ToString()

Duration:

dateTransactionStart = publishTransaction.Instruction.StartAt;
dateLastStatusChange = publishTransaction.StateChangeDateTime;
tsDuration = dateLastStatusChange – dateTransactionStart;

The tsDuration is now how long our job took to complete from start (the time it went into the queue) to the end (the time it’s status was changed to “success”).  If you submitted allot of jobs at once, then for some this time would be long because it includes queuing time.

The job itself

Within the transaction is the context. The context is holding the actual job itself; so for instance it contains details on the items the job resolved to.

To get the context is available as publishTransaction.PublishContexts

We can then…

Get the count of the processed items: transactionContext.ProcessedItems.Count

The publication: transactionContext.Publication.Title.ToString()

The Publication Target name:  transactionContext.PublicationTarget.Title.ToString()

The processed items

Then within the context we have processed items which we can loop around and get yet more details:

The processed item id: processedItem.ResolvedItem.Item.Id

The time it took to render: processedItem.RenderTime.Milliseconds

The template id it was rendered against (if applicable): processedItem.ResolvedItem.Template.Id

The item type of the processed item: processedItem.ResolvedItem.Item.Id.ItemType.ToString()

We can of course do things like add all the render times up and make some more numbers and if we subtract it from our duration I mentioned higher up, we can get an estimate on how much time was take to deploy (everything else but rendering).

Summing it up…

As you can see there is a wealth of information in the publishing transaction data and this was just the detail I needed for my purposes. I suspect there is allot more in there and playing around with the API is somewhat like Digital Archeology. To help you out I’ve added the scripts I use for measuring publishing on SDL Tridion 2011 SP1 which you can download, play with and even use to collect your readymade statistics!

Download QueueView2011_v0.3. This is an alpha release and requires additional work to make it production ready.