Documentation Center

Content Delivery functionality introduced in SDL Web 8.5

A number of functional changes in Content Delivery were introduced to SDL Web.

Content Deployer sizing settings removed from the Content Deployer configuration file, new settings added to the application properties file

Previously, you would configure sizing settings for the Content Deployer in its configuration file, deployer-conf.xml, in the Param child element of the BinaryStorage element, using the named parameters MaxSize and Capacity.

Now, you configure sizing settings in the application.properties file of Content Deployer. Note that the Capacity setting is discontinued, and that the amount of free disk space is the only thing limiting the amount of package that can be received.

To configure sizing settings in the new setup, use the following settings:
PropertyDescription
spring.http.multipart.max-file-sizeSpecifies the maximum size permitted for uploaded files.
spring.http.multipart.max-request-sizeSpecifies the maximum size allowed for multipart/form-data requests.

Both new settings must have a value that is a number followed by either Mb (to indicate megabytes) or Kb (to indicate kilobytes).

Change to structure of Content Deployer configuration file: Processors become Pipelines

The old Content Deployer configuration file, cd_deployer_conf.xml) contained a Processors section containing Processor subsections with Module subelements/

In the new combined Content Deployer Role and Content Deployer Worker Role, in the new deployer-conf.xml file, this part of the configuration has changed into a Pipelines section containing Pipeline sections. Each Pipeline section contains a Steps subelement with one or more Step elements inside it. Each Step contains a Module subelement.

Publish undo feature discontinued

The "publish undo" functionality, which was introduced in SDL Tridion 2013, is discontinued as of SDL Web 8.5 .

Separation of Content Deployer role into endpoint and worker
The original Content Deployer performed two tasks: receiving incoming content on the one hand, and processing that incoming content on the other hand. These two distinct functionalities are now made explicit through two separate roles:
  • Content Deployer, which is now an endpoint only
  • Content Deployer worker, which performs the actual work of processing the content

This not only separates responsibilities, but also improves scalability options.

New configuration files related to Content Deployer
The existing Content Deployer configuration file, cd_deployer_conf.xml, is replaced with two configuration files:
  • deployer-conf.xml contains all configuration options previously found in cd_deployer_conf.xml (except for TCDL tag configuration), reorganized.
  • tcdl-conf.xml contains your TCDL tag configuration.

If you upgrade to SDL Web 8.5 and then start Content Deployer (either as a standalone microservice or as a Web application-based microservice), the cd_deployer_conf.xml is automatically replaced with deployer-conf.xml and tcdl-conf.xml. If you would like to verify the transformations performed on cd_deployer_conf.xml for yourself, refer to the XSLT stylesheets in the installation media folder Content Delivery\resources\xsl\.

Ability to publish Dynamic Component Presentations in REL format on Web pages in JSP or ASP.NET format

You can set a new property in tcdl-conf.xml called tcdl.page.target.language, which allows you to have SDL Web transform Pages into JSP or ASP.NET for your JSP or ASP.NET Web site, while leaving REL Dynamic Component Presentations on the Page unchanged.

Multiple Content Deployer destinations

In the Content Deployer Capability configuration in the Storage Layer configuration file, cd_storage_conf.xml, you can configure multiple destination URLs.

JMS support for scaled-out Content Deployer

If you scale out your Content Deployer, you can set up Apache ActiveMQ and configure your Content Deployers to use a JMS queue in order to make commands available to all Content Deployers.

New Claim scope configuration value STATIC

This new value preserves the Claim for the duration of the session, but does not serialize or deserializes the Claim once published by the microservice.

Storage of incoming content for Content Deployer in Redis database

If you scale out your Content Deployer, you can use a Redis database for storing incoming content temporarily, rather than a (shared) file system location. Using a Redis database is both easier and faster than file system storage.

Better recovery from Content Delivery database outages

In the Pool element of the Storage Layer configuration, you can now configure additional pool options to improve the robustness of the Content Data Store database connection in the event of temporary outages.

Similarly, you can configure more robust connectivity to the Context Service device database.

Product deliverable no longer ships with Java/JSP Web application-based microservices

WAR files that act as microservices are no longer included on the product deliverable, and can only be obtained through SDL Customer Support. It is strongly recommended to migrate your implementation to standalone microservices now.

Distributed caching for Java Content Interaction Libraries

You can now modify cd_client_conf.xml, the Content Delivery client configuration file, to use a Redis database for cache storage. Using Redis allows you to implement distributed caching.

Distributed caching for .NET Content Interaction Libraries

The Content Interaction Libraries (CILs) that you reference or include in your .NET presentation environment now support distributed caching. You configure CIL caching in the Web.config file of your .NET Web site, in a new section called caching inside the section called sdl.web.delivery. The old way of configuring caching for .NET, which involved adding a service-caching key and a service-caching-expiration key to the appSettings section of Web.config, is now deprecated, but remains supported for backward compatibility. SDL recommends replacing your old caching configuration with the new one.