Skip and go to main content

Design & Technology February 14, 2017

SDL Web 8.5 Developer Bootcamp

Image

I recently headed over to SDL Amsterdam to learn about the latest features and functionality of SDL Web 8.5 in a two day workshop.It was great to see a few past SDL Web MVPs and Community Builders, and was chance to catch up with Robert Curlette (organiser of Tridion Developer Summit) and Alvin Reyes.  I also met internal people from SDL’s various departments including R&D, Professional Services and Pre-Sales, and caught up with folks from the SDL US offices who Dept has worked with in the past.

Firstly, thanks to SDL for the invite –  the event was really well run and organised, and there was a great bunch of people in attendance. I hope I can attend more events like this in future.

Right, on with what was covered. Day one focused on Content Delivery features and the UI notification framework with a sprinkling of workflow…

Content Delivery

Renze De Vries presented the Content Delivery changes. SDL are planning a lot of changes for the future. The first step is changing the deployer so that it can scale – this was a bottleneck in the past so this is a great new feature.

This does seem to be quite a significant rework but, as always with SDL, they’ve maintained backwards compatibility. It has three possible configurations:

  • Single machine (deployer combined role – special configuration).
  • Single machine multi-worker (deployer endpoint and workers on the same machine).
  • Scaled out (deployer endpoint one machine, workers on different machines).
Image

In order to use the full benefit of scaling out, there are three storage components required:

  • State store (also known as ‘Yet Another Broker Database’).
  • Deployer queue (or Q-E in the words of Renze). SDL recommend that this is Active MQ or Amazon SQS but should work with any JMS implementation, but they said your mileage may vary.
  • Binary Storage (this is where deployer packages are stored, not related to images etc.) This can be either Redis or the filesystem, but you need to use Redis if you scale to multi-machines or multi-workers. Redis also has a limit of 512MB on the packages, so you need to be careful with large binaries in the CMS and resolving logic.

Another interesting development was Renze noting that SDL could be bringing a built in Search solution to content delivery based on the SI4T project.

A returning feature is multi-destination deployment, which was removed in SDL Web 8. This is a useful feature which enables you to send images to multiple servers, for example. This avoids the need for filesystem replication (although SDL still recommend this approach), but can be a dangerous one, as it can result in incomplete transactions since it’s not possible to roll back the whole deployment if it fails on one machine but not the others. So, potentially, files could go to one server and not the other. However, this is reported in the Publish Transaction info screen so I think it’s still a good feature.

The caching in Content Delivery has been improved massively; there’s now an option to use a distributed cache in the web app layer, which means a time-based cache will now invalidate on all presentation servers simultaneously. This is Redis out of the box but it looks like you can write your own provided. The sliding cache (a bad design choice for Published content!) is still present, but should always be overridden by the absolute expiration, in my opinion.

caching overview.jpg

SDL mention moving towards an Eventual Consistency model, so there is no invalidation of client side caching when an item is published. I can see the reasoning behind this, but am not convinced it is the right approach. Rick P (DXA developer) pointed out that with the centralised caching model, it could be possible to receive deployer notifications – we just need to understand the cache keys. It would be good for SDL to publicise this information so that the community can have a go at implementing this.

Parameterised configuration files partially came in with Web 8, but now should work for all Content Delivery files.

UI Notification Framework

Arno van Nijnatten presented the new UI Notification Framework. This is based on a popular framework called SignalR which handles the low level asynchronous comms.

SDL do not support interacting with SignalR directly, in order to give freedom to change frameworks later without breaking integrations.

Arno implemented an example: GUI extension and some events code to show the user when an item was published. Architecture prevents targeting specific clients.

There’s a nice API for raising notifications with Events code (or any code in a TOM.NET context).

What’s new in SDL Web 8.5 and recap of Web 8, Deployer Exercise

On day two, we had a quick intro to what was new in Web 8 and Web 8.5. Alvin pointed out that many times when customers ask what’s new, they are currently on 2011 SP1 or 2013 SP1, so it’s important to include those features which were released. Jeff Wisor provided a presentation showing gap analysis from 2009 – Web 8.5

We then did an exercise to implement the new scaled out deployer which Renze had shown us the architecture of:

  • There’s a new config file deployer-conf.xml
  • We had to take the pre-installed Combined Deployer Role and scale it with one endpoint and two workers.
  • This involved installing ActiveMQ and then configuring the workers correctly. Many config files!

There seems to have been some confusing decisions in the configs for this. For example, the licence element in the new deployer-conf.xml (note the hyphen instead of the underscore), has a different attribute to set the licence location than the cd_storage_conf.xml, but both need to be set in the endpoint and both workers in order for the set-up to function.

Overall this does seem like a great feature though, and should allow for much faster publishing as the deployer is no longer a bottleneck.

Renze did warn us that a maximum of four workers should be used in the current set-up because of database contention – any more is likely to result in locks. This is due to the way that the items are stored in the Broker database.

There was some discussion about moving to a NoSQL database to store Broker content to avoid this, but that seemed to be a far future possibility.

Topology Manager Revisited, Workflow, ETW & Privileges

Topology Manager is one of the hardest topics to come from SDL Web 8. Whilst I’ve had the, *ahem*, pleasure of configuring it quite a few times, Topologies are a complicated topic and requires a lot of brain power to set up (as our Sys Admin team discovered with our Web 8 implementations), so a recap was good for everyone. It was interesting to note that SDL don’t have a common way of documenting a Topology yet.

Image

 

In Web 8.5, SDL have introduced a UI in the CME which allows you to see the Content Delivery environments and other information in Topology Manager. This is very useful as it allows you to see at a glance whether an environment is correctly configured.

Image

 

Another nice feature that has been introduced is ‘Privileges’ – this enables giving system-wide settings management to users, without giving them full administrative access.

Image

 

Privileges will help to avoid a common problem where many users ended up being set as System Admins, just to provide them access to do a specific part of the admin process, such as being able to undo checkout items which had been locked by another user. This is a big step forward. The permissions model is also now extensible in this respect.

SDL have introduced a new Workflow mode called ‘Collaborative Workflow’ which allows users to see content which is still being worked on (i.e. you can see versions before 1.0).

This enables users to use content much more quickly and should considerably ease the creation of content when a workflow is in place, allowing content editors to be much more agile.

The old style ‘embargo’ mode is still the default. It is recommended to be used when there are many technical details in the content, or the content is sensitive and it needs to be thoroughly checked before it can be used on a page.

Later in the session, we had a play around with the new workflow feature. The Visio plugin is still around – I think SDL really need to move this into the CME. There are many online drawing tools and frameworks which do the job just as well – moving into the CME would reduce total cost of ownership if the client didn’t use MS Office or have Visio in their subscription.

Finally, Likhan showed us the Event Tracing For Windows (ETW) integration for the CME. This allows in depth analysis of what is happening on the CME. Likhan had built a prototype tool which shows the data collected in a graph and tree view: web-tracevisualizer. He was quick to point out that this is a PoC.

My thoughts on it all…

Thanks to SDL for having me at their office to learn about the new features in SDL Web 8.5. The new release is great and I look forward to being one of the first to implement it.

Dept has a couple of projects in the pipeline which will enable us to get our hands really dirty with it, and hopefully provide some more insight for the community.

SDL seem to be moving much quicker, adding new functionality and positioning themselves as a much stronger cloud provider. However, I feel they need to work on the way that they release updates to the software for on premise customers, or those hosting on their own cloud accounts (of which there are many).

I also feel that there is not a lot of real new UI functionality for editors in this update – aside from the Workflow and Translation improvements. Much of the work seems to, once again, be in the architecture, e.g. scaled deployer and caching updates. While this is great for implementors like us, and has benefits for SDL’s cloud offering as it makes for much more scalable code, it does nothing for improving the content entry experience.

I think the SDL community’s efforts with GUI extensions and Alchemy have shown us that there are many small things that could be implemented to improve life for editors. I would have expected SDL to be looking at what was popular and bringing those features into the Content Manager Explorer by now.

Overall, the future is looking promising as SDL continue to focus on the dynamic approach to building sites, meaning implementors like us can follow a traditional software development approach and provide value to our customers more quickly, confidently and efficiently.

Questions? We are here to help!