SDL Web 8 has been around for a little over a year now. Its successor (SDL Web 8.5) was recently introduced. You’d think that to an old Tridion hand like me, by now Web 8.x would be as familiar as any of the earlier (Tridion) versions. The sobering fact is that today I ran into an issue caused by a poor understanding on my side of SDL’s new microservices architecture. Fortunately it proved easy to fix.
Category Archives: Architecture
A new approach for serving images from a broker database
A picture says more than a thousand words, right? That’s why a web site needs images. In the old days before DD4T, the approach was very simple: out of the box, Tridion would publish your images to the file system, where the web server could pick them up and serve them out to the world.
But in the era of dynamic publishing, who wants to deploy to a file system anymore? One of the advantages of DD4T (or DXA, or any other dynamic framework) is that you publish everything to one central delivery store: the broker database. It makes sense to use this approach for images (and other binary file types) as well. But how?
Tuning DD4T + REST
One of the deployment scenarios with DD4T 2.0 is to use a REST service. There are many advantages attached to this approach, but you have to be careful about one thing: the number of TCP connections between the web server and the REST server. In this article I will discuss the cause and provide a solution. Continue reading
Tridion and JMS: removing another SPOF
When you use Tridion’s content delivery API to retrieve dynamic content, resolve links, etcetera, you are well advised to use the built-in caching mechanism. Without it, every page request would result in dozens of queries on your broker database (or dozens of data files being opened, which is just as bad for performance). With caching, most requests can be handled completely from memory, which makes your site a lot faster.
There is one catch to caching: Tridion being a content management system, it is highly likely that the content and links will change from time to time. That is why Tridion offers a notification system, so that your web application will always show content which is up to date and links that lead to the correct destination.
Actually, Tridion offers not one such notification system, but two. Most implementations use the so-called Cache Channel Service. This is a proprietary service which runs as a windows service or a stand-alone java process. Its job is to notify the broker instances when a new version of an item has been published to the broker repository. The Cache Channel Service uses the RMI protocol to communicate between the different virtual machines (which contain the broker instances).
Although this is certainly the most popular notification mechanism, it has some drawbacks:
- RMI is not a messaging protocol, so things might go wrong when the Cache Channel Service is temporarily down. Fortunately, Tridion has solved this by some clever programming in the broker, but it is still a work-around which makes the CCS slightly unstable at times.
- RMI uses unpredictable ports, which means that all ports > 1024 must be open between all your machines running a Tridion broker and the one running the CCS.
- There is no easy way to handle multiple channels (like a staging site, a live site, a mobile site, development environments, etc). You can only achieve this by running more than one CCS instance, which means running multiple processes, each on a different port, or even running the CCS on multiple machines.
- The CCS is a single point of failure (SPOF), since it cannot be scaled up.
As a solution architect, I find these disadvantages quite unsettling. Especially the last one: removing single points of failure from a solution is what we architects drool over.
Fortunately, SDL has come up with an alternative notification system. Instead of installing the CCS, you can also install a JMS instance. JMS – Java Message Service – is Java’s messaging system. There are many implementations available, including free ones like Apache’s ActiveMQ.
JMS is designed to pass messages from one application to another. These messages are organized in containers called ‘topics’. Applications can subscribe to a topic. Whenever a message becomes available in this topic, it will be passed on to all subscribing applications.
JMS addresses each of the problems of the Cache Channel Service mentioned above:
- JMS can work over http on a fixed port (typically 61616, but it can be configured to run on any port including 80)
- Multiple channels can be accommodated on a single JMS instance by simply configuring extra topics
- Since JMS works on http, it can easily be accessed through a load balancer. This removes the single point of failure from the architecture.
There is a common idea about JMS, and that is that it would be unsuited for a .NET presentation stack. This idea is incorrect. I can guarantee that the solution will work just as fine if your web site is on IIS. After all, the content broker core is always Java, and it is this core that does the communication through JMS.
Where’s the catch then? Well, there isn’t any, other than the lack of awareness of this solution in the Tridion community, and the lack of configuration examples in Tridion’s product documentation. But with some perseverance, the help of this excellent post by Julian Wraith and – if necessary – the assistance of Tridion customer support, it can certainly be done. The end result is a more stable and more robust solution.
Mixing content and functionality with DD4T
Today I received a question from a developer who is just starting on DD4T. He wants to have a page which consists of regular Tridion content but also contains a form. Being a .NET MVC developer he naturally wants to handle this form with a controller and various actions to handle GET and POST and perform validation as well as sending an email on successful submission.
I call this type of web page, which combines plain content with application logic, a ‘mixed’ or ‘hybrid’ page. DD4T was designed to handle such pages (as well as the more simple content pages). To understand how DD4T does this, you need to know that the framework uses controllers and actions on two different levels:
- The level of the page (just like in any MVC app)
- The level of the component presentation
Let’s start by looking at a very simple page, which does NOT contain any forms or other application logic:
As you see, there are two views involved to build this rather simple page. The controller and action are predefined by the framework – unless you override them, which I will explain later. The controller/action for the page retrieves the page from the Tridion broker and uses that as its model. The controller/action for the component uses the component as its model. All YOU need to do is write the views.
You may wonder how DD4T knows which views to call. This is achieved by configuring the name of the view in the metadata of the page template and component template.
Now I’m coming back to the question of mixed pages. A mixed page has application logic as well as plain content. To handle application logic in MVC, you need a controller and an action. For example: you might want to display a form when the method is GET, and validate it when the method is POST.
In a diagram, this is how it will look:
The page now contains two component presentations: one that represents (and contains) just plain content and another one that represents the form. The neat thing is that your custom action will automatically be called by DD4T. All you need to do is configure your custom controller and action using metadata on the component template. So instead of just specifying a view, you will now have to specify a controller and action as well.
Advantages of this ‘mixed page’ approach:
- Tridion stays in control of the URL
- Editors can decide where to put a form, and which other pieces of content to put next to it
- The placement of the form and other pieces of content is handled by the exact same view as on normal pages, so you do not have to do extra coding.
- All MVC functionality like model binding and validation are fully supported
Happy coding!