Tuesday, May 20, 2014

10 things you did not know about SDL Tridion 2015

Last week (May 15th) we had our first ever Tridion Developer Summit, and man, was it good!

I've posted the slides I used for the keynote on slideshare - so share away. Below you'll find some additional background info for each of the changes introduced. To be clear, there is a lot more about SDL Tridion 2015, but 10 is a nice round number.




#1 - You will be able to load AppData from multiple items in bulk
One of the most expensive (in terms of cpu and database time) things to do with Tridion is extending Lists. Not necessarily the extension by itself, that part is easy, but the retrieval of the data to display in your extended list may be hard to achieve, because the data is "buried" deep in the CM. In one of the harder extensions I've built we had to load metadata from a keyword in a linked component and display it. Couple that with lists that contain 1000's of items, and this is a performance nightmare (and may get the DBA knocking at your door). So a common workaround is to use Event System to store this data in AppData, then read it from there, which removes quite a few database loops, but you still need to talk to the database at least once for each individual item. In Tridion 2015 we added the ability to load AppData from a collection of item IDs in one go, removing the biggest bottleneck in this scenario.

#2 - We will have a new item type (4096 - Business Process Type)
This is a new root-level Organizational Item that will allow you to define different sets of rules for different blueprint branches in terms of governance models. You will be able to use Business Process Types to associate Content Types, Page Types, Schemas, Target Types and Workflow Definitions to a specific Publication (and children) and "impose" rules for governance using standard Blueprinting. Because it is a Repository Local Object, normal rules apply to it - it can be localized, it can be inherited, etc.

#3 - Content Delivery will be able to load configuration from a repository (rather than File System)
As we move to this virtual, always-on, seamlessly scaled environments called "cloud", the requirement to have specific server configurations on the File System makes it unnecessarily complex to spin up new servers on demand. As of Tridion 2015 you will be able to manage CD configuration settings from a repository (for all your servers in a given CD Environment) and apply changes to all servers in the same "stack" centrally, reducing margins for error and improving manageability.

#4 - Content Delivery will expose a discovery endpoint to CM
Again linked to cloud and managing many sites with different functional or technical requirements from a Delivery standpoint, we need to improve how we decide that content of a given publication must be published to a given Content Delivery stack versus another. In order to achieve that, we need to first discover what is available in CD (think of it in terms of capabilities: search, SmartTarget, Experience Manager, etc). So, for instance, if you have a requirement that content published to "staging" has Experience Manager, this information could help us select an environment that provides such capability.

#5 - SDL Tridion 2015 will trigger Events on lists
 The current framework for List Extenders works great when you want to add/modify/remove information from a list in the Content Manager Explorer or Experience Manager. But if you want to do the same with WebDAV, or even lists requested by an external application via CoreService, we don't provide that same mechanism. With Tridion 2015 you'll be able to use the core Event System to extend any given list, therefore removing this limitation (while also making it easier to implement).

#6 - SDL Tridion 2015 will allow code to temporarily elevate a user's privilege
One of the most common scenarios I ran into as an implementer would be to write event system code that created objects or published items to areas where the user did not necessarily have access to. Since the user did not have access to it, we'd normally work around this by creating a new Content Manager session with an Admin account, creating/modifying/publishing our objects, and then hopefully disposing this session. We'd also run into many issues with these sessions not being properly disposed of, and of course the actions in version history would be logged as having been performed by the Admin account, which damages traceability. With the new release you'll be able to elevate the user's permissions, perform a given action, and you'll be able to trace it back to an action taken by that user while elevated (somewhat similar to sudo). Awesome stuff.

#7 - SDL Tridion will let you create "Site Types"
Site Types have actually been renamed to "Site Templates" in the past few days, but the principle is pretty much the same. This is not really new, as you already had this ability in the past via Blueprinting, but we're now making it explicit, and you'll be able to define several rules around this Site Template (like, for instance, which Business Process Type is applicable to it). By the way, a Site Template is a subtype of the Repository class (much like a Publication).

#8 - SDL Tridion 2015 will introduce a Topology Manager
This is one of the coolest things we're doing now, and it is used to tie back all this information that we have about Target Type purposes, Business Process Types, Site Templates and Content Delivery capabilities. This service exists between CM and CD and will be responsible for most of the logic tying CM and CD together, provide information about and configuration for Content Delivery, and in the future drive additional features about scaled-out environments, cloud integrations, etc. The Epic from which most of these features come from was called "Target Awareness" - this should give you a good idea about where we're trying to go with it.

#9 - SDL Tridion 2015 will have a default website and reference implementation
I don't know about you, but I for one am getting tired of the "we can do anything" approach we've had with Tridion in the past. Yes, it is true. I haven't yet found a file system or database that I can't publish to from Tridion, but this only works when the people driving the implementation actually understand Tridion's way of working and understand architectures in general. Basically, "we can do anything as long as you know what you're doing". Nothing wrong with that, and we won't change that. But we'll also give you a reference implementation, something like "this is how we think you should be doing it", something that new developers/implementers can use to learn the ropes with. I will be talking more & more about this in the near future, so I won't expand much more here than I did already.

#10 - Publication Targets will be deprecated in SDL Tridion 2015
And last, but certainly not least, we are revamping the publishing process pipeline, and how the configuration between CM and CD can be done - while doing this we realized that we don't actually need a Publication Target anymore. Yes, we still need the information stored in this (we need to know how to get to a given deployer, which target language, etc) but we could store this information in either our topology manager (for deployer endpoint) or the Target Type. And the Target Type can have additional information we need like the capabilities required for a given Site Template.

Yes, exciting times ahead. A lot of these 10 things are actually already developed and in our main dev branch, and everything else is currently in progress. As usual with process development, there are things that may drop, but as far as I can see this will not be the case for any of these 10. If you were at the Developer Summit I hope you had a blast! (I certainly did, even though it's a bit foggy after 2 AM). If you were not there... well, you should have!

1 comment:

Alvin Reyes said...

2015 sounds awesome with more defaults, practical scenarios, and CD-awareness on the CM-side.

As a business-focused feature, I can see the appeal of site "template," since that's what everyone calls "starter" documents in Knowledge Worker land (e.g. "PowerPoint template").

But where's Mr. P to argue semantics on "Site Type" versus "Site Template?" Oh wait, by Midas Rule I'll invite him.