One of the main new features in SDL Web 8 (the new version of SDL Tridion) is the Topology Manager. I’ve been trying to get my head around this since it was announced and I’m still not sure I get it. We finally got to see a sneak preview of Web 8 this week and have a proper play around and I’m hoping by writing this post I can learn WTF Topology Manager is, why we need it and hopefully communicate that to you.
So let’s analyse it: Topology
topology təˈpɒlədʒi (noun)
the study of geometrical properties and spatial relations unaffected by the continuous change of shape or size of figures.
a family of open subsets of an abstract space such that the union and the intersection of any two of them are members of the family, and which includes the space itself and the empty set.
- the way in which constituent parts are interrelated or arranged.
“the topology of a computer network”
We’re probably going for the second definition here. I assume Topology Manager then, is about managing how our SDL Web environments are organised.
Let’s see what SDL say. In the SDL Web 8 documentation (which went live this week), we can see where it sits in relation to the other core modules.
From this image we can learn a little bit more. Topology Manager sits between the Content Manager and Content Delivery. It is related to “Target Types” which are replacements for Publication Targets and Publication Target Types from SDL Tridion 2013 SP1 and below. There is a new Discovery Service which looks like it lives on the Content Delivery side.
The docs say we should:
Use Topology Manager to communicate information between a Content Manager environment on the one hand, and one or more Content Delivery environments.
Ok sounds great! But what information? It’s probably worth reading about the Topology Manager concepts in the documentation before continuing. Seems like we have a bunch of concepts: Web application, Website, Content Delivery Environment, Purpose, Topology, Topology Type, Business Process Type, Target Type. Some of these are familiar and some aren’t. I think the ones we need explaining are Purpose, Topology, Topology Type, Business Process Type. The others I don’t think have changed since previous versions of SDL Tridion. I had to read this a few times before I got it. Let’s see if writing it out helps make it a bit clearer.
- A Content Delivery environment has a Purpose. That’s good, no one likes not having a purpose. An example of a Purpose would be “Staging” or “Live”.
- Topology Type
- A Topology Type is a list of purposes. So this could represent all of your environments for hosting a Website e.g. “Staging, Live”.
- A Topology is an instance of a Topology Type. This is the actual concrete details of each Content Delivery Environment based on the Purposes contained within the Topology Type. So for example a Topology could represent a cloud environment or an on-premise environment. These Topologies would use the same Topology Type – still containing Staging and Live, but the Content Delivery Environment details i.e. server names, within each Topology would be different. There is a mapping between each Publication and a Topology which determines where content is sent for publishing. Phew, OK that makes a bit more sense. So what about the last one?
- Business Process Type
- This sounds like it relates to Workflow, in that it will only allow publishing to certain Target Types (which also have a Purpose) when an item has reached a minimum approval status.
OK, that’s the concepts. But why? This seems like a lot of new stuff to do something we could already do…
The next page of the docs shows why:
Because Topology Manager stores information about where to publish in its own database, you can back up a Content Manager database and restore it in another Content Manager environment without taking publishing targets along.
This is a really nice benefit of Topology manager. It will make content synchronisations between environments so much easier to perform and potentially automate. Since there was not an out of the box way to transfer Publication Targets there was a tedious process of decommissioning and/or updating settings and URLs for each environment in the synchronisation – or write some Core Service code (I assume you could have done that? Never tried it). Storing this information outside of the CM database is excellent news and should make everyone’s lives much easier!
We now know why we might want the Topology Manager. Hopefully we’ll find out how to configure our publishing next! Let’s have a look at these Components in the UI and on the servers. We used to manage our environments through Publishing Management which isn’t actually in the UI any more.
There’s a new Business Process Types tree underneath a publication though:
Let’s have a look at the Staging Only Business Process Type under the test site that our man Tom Simm has created for us.
So this has a title.
And a Target Types tab where we can select a Topology Type.
And Bundle Schemas for some reason. This all still seems a bit abstract though. Where are all the real settings? Where do I manage my publishing if there’s no Publishing Management? Installation for the Content Manager shows we need to install a Topology Manager database. What’s in that? It has one interesting table called EntitySets.
These look like information about our environments stored as JSON. Also on the Content Manager server we have a new website:
I get a 500 error if browse to it though. I guess that’s because I don’t have the right credentials or parameters. Interesting!
On the Content Delivery server there is a new service called the Discovery Service. This looks like a Java service hosted within a Windows Service. Interesting to note that all the services have been renamed too. Note: In my environment I have both Content Manager and Content Delivery on the same server.
On the Content Delivery side there is also a new database called the Discovery database which presumably drives the Discovery service. It looks like a Content Data Store (aka Broker) database with some additional tables.
We can see some configuration values here that look like they might have once been stored in the Publication target settings. The database looks quite generic and flexible in structure, probably to enable extension at a later date.
So let’s rewind a little bit and go back to the documentation. How do we get data in these databases and why would we need to? It’s important to note at this point that the standard publishing management framework is still available as a legacy feature. The node in the UI can be re-enabled by following the instructions in the documentation. You also need to install the old Content Deployer and other services.
Let’s try and create a Topology! As we know there is not a full GUI for Topology Manager at the moment. We have seen some elements are visible in the Content Manager Explorer. I assume a full GUI will come as part of a service pack or separate release very soon. However, I think most experienced system administrators and developers will value the opportunity for automation and the ease of content synchronisations enabled by having the publishing information stored separately over a GUI. I also think that managing of publishing is an infrastructure task and should sit outside of the remit of the Content Manager Explorer anyway.
Powershell scripts are used for manipulating the items in Topology Manager. In the initial set up, which Tom has performed for us he used the %TRIDION_HOME%\bin\Configure-NewStyle-Publishing.ps1 Powershell script which interactively prompts for URLs and other settings. This script will populate your databases above with the data required to set up a Topology.
In the next post, we will create our own publishing environment using the more specific Powershell commands so we can learn what it is.