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
Paramchild element of theBinaryStorageelement, using the named parametersMaxSizeandCapacity.Now, you configure sizing settings in the application.properties file of Content Deployer. Note that the
Capacitysetting 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:Property Description spring.http.multipart.max-file-size Specifies the maximum size permitted for uploaded files. spring.http.multipart.max-request-size Specifies 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) orKb(to indicate kilobytes). -
Change to structure of Content Deployer configuration file:
ProcessorsbecomePipelines -
The old Content Deployer configuration file, cd_deployer_conf.xml) contained a
Processorssection containingProcessorsubsections withModulesubelements/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
Pipelinessection containingPipelinesections. EachPipelinesection contains aStepssubelement with one or moreStepelements inside it. EachStepcontains aModulesubelement. - 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
Poolelement 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
cachinginside the section calledsdl.web.delivery. The old way of configuring caching for .NET, which involved adding aservice-cachingkey and aservice-caching-expirationkey to theappSettingssection of Web.config, is now deprecated, but remains supported for backward compatibility. SDL recommends replacing your old caching configuration with the new one.