Using AWS Services to Monitor Tridion

When you have a very important and bulk publishing is going on and you want to monitor each state then AWS service is a great way of doing it. Recently, I had this opportunity to implement AWS services to monitor SDL Tridion publishing and Broker Database spike.  We need to monitor the publishing state and Broker DB connections limit and for that I used the following AWS services.

All these activity is required and becomes almost mandatory when yon have Huge INFRA to manage.

1. AWS CloudWatch
2. AWS SNS (Simple Notification Service)
3. AWS lambda Function

To monitor the publishing I used the AWS Lambda function which is in python and some inline SQL script. Yes, just few lines of code gives you all the info.

This matrix is then used in the dashboard to generate the realtime GRAPH and Similarly, we have script for other publishing state which helps us in monitoring the progress of publishing. These scripts are very helpful when you have thousands of the items in queue and waiting for publishing.

Failed items

Published items

Next, is we need to implement the notification service to send the notification whenever the Broker Database DBconnectin limit reaches the higher side or more than expected so that we can take action pro-actively. To Implement this we used the AWS default Matrix and with the help of AWS SNS we are sending the notification, for notification you can use (EMAIL,SMS,HTTP,Notification etc) depending upon your requirement.

 You need to go to the CloudWatch--> Alarm and create a New Alarm. By Default in SQL Server the default DB connection is set to 0 which mean Unlimited, but using AWS CloudWatch you can monitor and can take pro.active steps when its starts increasing.   

Next is send the notification if the limit is crossed and for that we can use AWS SNS.

Configure SNS to send Notification. 

Where SNS is your notification service. We first need to create a Topics and based on Publisher and Subscriber model we can send the notification. Protocol supported by the AWS SNS to subscribe.

Protocol Available 

Or, you can configure the Auto Scaling of you EC2 instance, we only have notifications service configured but yes, we also have this options as well. It all depends on your requirements.

Auto Scaling option in case of Alarm 

We just saw how we can monitor SDL Tridion using AWS Service and takes pro-active steps. Configuring the AWS Service is pretty easy.

Happy Coding and Keep Sharing!!! 

Extending Content Delivery Storage in SDL WEB 8.5 - Part 3

In the last blog, we saw what happened when we publish a new component, it only calls the create method, but when we re-publish an item it first calls the remove method and then create.

Remove Method

public void remove(int publicationId, int componentId, int componentTemplateId, ComponentPresentationTypeEnum componentPresentationType)

throws StorageException

{

log.debug("Custom storage remove Method");

super.remove(publicationId, componentId, componentTemplateId, componentPresentationType);

log.debug("Custom storage remove Method :- "+componentId);

 

}

Re-Publish an item

As you can see when I re-published an item, we have remove method invoked first and then create method. Next, is un-publish an item and see how it works/ in what sequence.

Un-Publish an Item

When we publish a new item only create method is called, re-publishing will call the remove method and then create and finally in un-publish only remove method is called.   

In the last two blogs, we learned how to set up and configure the project to build storage extension and Publishing a new item and in this blog, we saw other functionalities as well and how they are invoked, in what sequence/order, with this approach we can add/update/remove DCPs in custom storage e:g SOLR, ElasticSearch, MongoDB, etc.

This data can further be used for analytics and for third-party applications.

Happy Coding and Keep Sharing !!!

Extending Content Delivery Storage in SDL WEB 8.5 - Part 2

In the previous blog, we set up the project and configured all the required config and based on that we published a DCP and saw custom logs are available which means everything is working fine.

Today we are going to read the content of DCP and will see how Storage Extension work when we publish, re-publish and un-publish an item.

The Content is available in the form of Bytes and we need to convert that, below is the code snippet that will allow you to access the DCP content in your custom code.

public void create(ComponentPresentation itemToCreate, ComponentPresentationTypeEnum componentPresentationType)

throws StorageException

{

          super.create(itemToCreate,componentPresentationType);

          log.debug("Custom Code Create Method COMID :- " + itemToCreate.getComponentId());

          log.debug("Custom Storage create Method:- "+ itemToCreate.getContent());

          log.debug(String.valueOf(itemToCreate.getComponentId()));

          byte[] dcpComponent= itemToCreate.getContent();

          try

          {

                  componentPresentation = new String(dcpComponent,"UTF-8");

                  log.debug("Custom Storage create DCP :- " + componentPresentation);

          }

          catch (UnsupportedEncodingException ex)

          {

                  log.error("Custom Storage create Unsupported " + ex);

          }

}

DCP content

Publish a new component and in the deployer log file, you will see the DCP content but what will happen when we re-publish the same component or un-publish this. How we are going to manage that in the custom code, will see in the next blog, until then.

Happy Coding and Keep Sharing !!!

Extending Content Delivery Storage in SDL WEB 8.5 - Part 1

In this blog, We are going to extend the Storage layer in SDL WEB 8.5 but first, we need to set up the project and will make sure that the custom code interacts with the default process.

Pre-Requisites

1. Eclipse or you can use your favorite JAVA IDE. You can also follow my previous blog on how to set up the Project in Eclipse and generate custom JAR. [here]
2. JAVA 8
3. Default SDL JARs

We can customize the way existing items are stored by the Storage Layer using the DAO "Data Access Object" implementation pattern. We also need to extend JPAComponentPresentationDAO and implement ComponentPresentationDAO and this will allow us to extend the Storage Layer for Dynamic Component Presentation.

Step 1. Create a JAVA class file and add the following Namespaces.

import com.tridion.broker.StorageException;
import com.tridion.storage.ComponentPresentation;
import com.tridion.storage.dao.ComponentPresentationDAO;
import com.tridion.storage.persistence.JPAComponentPresentationDAO;
import com.tridion.storage.util.ComponentPresentationTypeEnum;
import java.io.UnsupportedEncodingException;
import java.util.Collection;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

Step 2.  Extends the class JPAComponentPresentationDAO and implement  ComponentPresentationDAO. We also need to insert a @Component and a @scope("prototype") statement between import statements and class definition and the following line of code.

Custom Storage Extension

Step 3. Create a storage DAO bundle config file.

Step 4. Copy this config file in the Deployer config folder and open the cd_storage config file in your favorite editor and add the following element.

Edit storage config file.

Step 5. Copy the Custom JAR file in the deployer and restart the deployer.

Custom JAR.

Step 6. We are done with code and configuration, now we need to publish the DCP and check the logs.

Logs

In the log file, we can see the custom log is available and it's returning the Component ID which means the code is interacting with the default process.


In the next blog, we will see the difference between other Methods, how our code will change on Publishing, Unpublishing and re-publishing and how to read DCP content, Until then.

Happy Coding and Keep Sharing !!!

Custom Deployer Extension in SDL WEB 8.5 - Purge Cache Part - 2

In the previous post, we set up the custom deployer project, discussed its requirement and the use of deployer extension. Today, we are going to continue to use that same project and implement a real-life use-case.

Background:- In our current project we are using SDL WEB 8.5 and .NET DXA 1.8 and to improve the performance of the web application we implemented the custom caching with cache expires after 15 mins, but the business team has this requirement that they want to see the content "Real-time", no delay whenever the publish any new content.

Based on their requirement we came up with this approach and decided to write a custom deployer extension. So, whenever the author publish the page(s), the deployer extension will trigger and clear the cache of that particular page based on the URL extracted from PageMetaData.

In the below code snippet we are reading the page relative URL retrieved from PageMetaData and with the help of string manipulation we've created the absolute URL and based on the Query String parameter we trigger the code to purge the cache. Check the HTTP response code it should be 200 in the logs and refresh the web page to check the latest content.

 // This is called once for each Transport Package that is deployed.  
      @Override  
      public void process(TransportPackage data) throws ProcessingException   
      {  
            log.debug("This is custom logs");  
            String USER_AGENT = "Mozilla/5.0";  
            log.debug("PublicationId : " + String.valueOf(data.getProcessorInstructions().getPublicationId().getItemId()));  
           try  
           {  
            log.debug("Custom Code :- Entered in the try block");  
            PageMetaData pageFile = (PageMetaData)data.getMetaDataFile("Pages");  
            log.debug("Custom code :- Reading PageMetaData");  
            if (pageFile != null)  
      {  
        List<Page> pages = pageFile.getPages();  
        for ( Page page : pages )  
        {  
             log.debug("Custom code :- For loop to get the page url ");  
             log.debug("http://localhost:92"+page.getURLPath()+"?ClearCache=true");   
             String URL = "http://localhost:92"+page.getURLPath()+"?ClearCache=true";  
             URL obj = new URL(URL);  
             HttpURLConnection con = (HttpURLConnection) obj.openConnection();  
             con.setConnectTimeout(5000);  
             log.debug("Custom code :- timeout");  
             con.setRequestMethod("GET");  
             con.setRequestProperty("User-Agent", USER_AGENT);  
             int responseCode = con.getResponseCode();  
             log.debug("Response Code : " + responseCode);  
             if (responseCode == HttpURLConnection.HTTP_OK)  
             {  
              log.debug("Custom Deployer, Cache has been removed and the responseCode is : " + responseCode + "- for URL " + URL);  
             }  
             log.debug("Page ID :" + String.valueOf(page.getId().getItemId()));  
        }  
      }  
            log.debug("Purging is done !! Please check the web page!!");  
           }  
           catch (Exception e)  
     {  
        log.error("Could not get path for publication.", e);  
        return;  
     }  
  }  

Logs generated by the deployer.

Deployer Logs

With the help of the deployer extension, we were able to achieve and deliver the real-time experience and still managing the performance of the site using cache.


Happy Coding and Keep Sharing !!!

Custom Deployer Extension in SDL WEB 8.5 Part - 1

Today, we are going to see how to extend the default SDL Tridion deployment functionality, using Custom Deployer Extension. Before we move forward and start building/set up the project let's first understand the use of Deployer Extension. When a user publishes content, the Content Deployer unpacks the incoming Transport Package and processes its transport instructions and we can extend the default behavior of the Content Deployer by creating a custom Module and adding it to a Step, or by extending an existing Module.

Deployer Extension:- 

• Deployer Extension is used to inject additional functionality in the default SDL Tridion deployment process. 
• If you want to implement your custom logic/data. "Event System might be useful here as well 🤔 We need to be absolutely sure about it".
• If you want to use some specific data/info which is only available at the time of deployment.   
• Based on JAVA.
• You can extend the default behavior of the Content Deployer by creating a custom Module and adding it to a Step, or by extending an existing Module.

In order to set up the JAVA project for the Deployer Extension, I have used Eclipse IDE, default JARs provided by SDL and JAVA 8. 

First, we need to configure the JAVA project using Eclipse.

1. Click on File --> New --> Other Project and then select Java Project and click Next.

Create New JAVA Project

2. Enter the Project Name

Enter the Project Name.

3. Create a new folder called "lib" which will contain all the JARs.

Create new Folder lib

4. Copy all the JARs in lib, you can find all the default JAR files in the deployer microservice lib folder. Once copied then we need to Add the Build PATH.

Add JARs Build Path

5 Next, is create a Java package and then create a CLASS file.

Create a new Java Package

Create a New Class

6. Start Importing all the Namespace that's required in order to extend the deployer.

Tridion Default Namespaces.

7. Next is we must implement the abstract method  Module.process(TransportPackage)

 package com.tridion.deployer.extension;  
 import org.slf4j.Logger;  
 import org.slf4j.LoggerFactory;  
 import com.tridion.configuration.Configuration;  
 import com.tridion.configuration.ConfigurationException;  
 import com.tridion.deployer.Module;  
 import com.tridion.deployer.ProcessingException;  
 import com.tridion.deployer.Processor;  
 import com.tridion.transport.transportpackage.TransportPackage;  
 public class PurgeCache extends Module {  
      protected static Logger log = LoggerFactory.getLogger(PurgeCache.class);  
        
      public PurgeCache(Configuration config, Processor processor) throws ConfigurationException  
      {  
           super(config,processor);  
      }  
      // This is called once for each Transport Package that is deployed.  
      @Override  
      public void process(TransportPackage data) throws ProcessingException   
      {  
            log.debug("This is custom logs");  
            int publicationId =data.getProcessorInstructions().getPublicationId().getItemId();  
            log.debug("PublicationId : " + String.valueOf(publicationId));  
      }  
 }  

That's it Export this into a JAR and next is the configuration in the deployer_config.xml of Deployer Microservice. "Don't forget to restart the service".

Click Export

Click Jar file and then Next

Custom Deployer Extension JAR file is ready

Finally, we need to deploy the custom JAR in the deployer microservice lib folder and open the deployer_config.xml file in your favorite editor add the below configuration, save the file Don't forget to take a backup before you start editing.

 <Step Factory="com.sdl.delivery.deployer.steps.TridionExecutableStepFactory" Id="PurgeCacheSteps">  
   <Module Type="PurgeCache" Class="com.tridion.deployer.extension.PurgeCache">  
   </Module>  
 </Step>  

 We also need to edit the logback.xml

 <logger name="com.tridion.deployer.extension">  
     <appender-ref ref="rollingDeployerLog"/>  
 </logger>  

Let's do some publishing and see if everything is working fine. Ideally, we should be able to see the logs entries. If you see the custom logs in the log file that means your custom code is interesting with default deployment process and you've built the extension successfully.

Log File

In the next blog, we will use the deployer extension with a very interesting use-case, until then.

Happy Coding and Keep Sharing !!!

SDL Tridion sites 9 PCA with REACT - Part 2

In the previous post, we saw how to set up the project using Apollo Client, ReactJS and interact with Tridion Sites 9 PCA. We also build a new schema, Dynamic CT and published 3 components using the Dynamic CT in order to retrieve them via PCA (GraphQL).

In the last exercise, we rendered the list of Dynamic News Components on the Landing page. Today we are going to continue using the same code and build the Details page and later on will see the deployment process and how to deploy ReactJs App.

So, let's start with the News details page, we already created the landing page and while doing that we had sufficient information to get the DCP of that particular component. If you have noticed in the code or screenshot from my last blog the Href that I've created for each News and Article items contains the combination of ItemId and CT and we need that same combination to get the Component Presentation.

DCPs with ItemID-CT available on Landing Page

Here are the JSX and Graphql code to render the News details page

News Detail Page

Here is the News and Article Details page again not a very attractive UI 😊.

Details Page

Let's build the App and see how's the production-ready build looks like. The below commands build the deployment package after npm build we need to run serve -s from the build folder and this will spin the Website

 $ npm run build

 $ serve -s

Build Package

Final Output 

Final Build

The updated code is available on GitHub and in the next blog, we will see more features works until then.

Happy Coding and Keep Sharing !!!

SDL Tridion sites 9 PCA with REACT

Tridion sites 9 PCA is getting popular more and more every day, and today in this blog, we will be creating an app using Apollo Client to communicate with SDL Tridion GraphQL API. We will integrate Apollo Client with ReactJS, but you can use it with several other client platforms as well.

Setting Up The Project

To get started we first need to set up a new React project. The easiest way to do so is to use create-react-app. This script creates a new React project.

 npm install -g create-react-app react-graphql  
 cd react-graphql  
 npm start  

with this, you will have the default app up and running on port number 3000, This is initiating a new basic React project in the newly created project folder react-graphql. By using the npm start to command the live-reloading development web server is started and the output of the default React project can be accessed in the browser:

Default ReactJS

In order to work with GraphQL, we have to install Dependencies. The next step is to install the needed dependencies.

• apollo-boost: Package containing everything you need to set up Apollo Client
• react-apollo: View layer integration for React
• graphql-tag: Necessary for parsing your GraphQL queries
• graphql: Also parses your GraphQL queries

The installation of these dependencies can be done by using the following NPM command

 $ npm install apollo-boost react-apollo graphql-tag graphql  

Project Structure 

As you can see I've imported react-apollo in order to work with GraphQL. In today's demo, we will see how to get the Dynamic Component Presentation and reder the same in React based webapp. To start this I've created a new schema with Title and Description as content fields and used the default DXA standard Metadata Schema as well.

Based on this new schema I've created 3 new components and published them using Dynamic CT. They are now available via PCA.

3 DCPs for Demo Purpose

DCPs via GraphiQL

Next, is call PCA using Apollo Client and ReactJS and render the DCPs.

Here is the query to get all the DCPs to render them on the News and Article Landing page.

 const repoQuery = gql`  
  query  
 {  
  componentPresentations(namespaceId: 1, publicationId: 11, filter: {schema: {id: 789}}) {  
   edges {  
    cursor  
    node {  
     itemType  
     rawContent {  
      data  
     }  
    }  
   }  
  }  
 }  
 `  

Based on the query criteria we are getting 3 DCPs which is correct

PCA output

Next, Display the Data

Let's write some JSX to display the fetched data. I'm fetching/rendering the data from both Metadata and Content fields, just to test the feasibility/flexibility and syntax.

 class News extends Component {  
  render() {  
   console.log(this.props)  
   return (  
    <div>  
     <h2>News and Articles Landing Page</h2>   
     {  
      this.props.data.loading === true ? "Loading" :   
       this.props.data.componentPresentations.edges.map  
       (  
        data =>  
       <ul key={data.node.rawContent.data.Id}>  
       <li style={{fontWeight: 'bold'}}>  
         <a href={"newsdetails?ids="+data.node.rawContent.data.Id +  
          "&name="+data.node.rawContent.data.Content.title.replace(/[^a-zA-Z0-9]/g, '-')}>  
          {data.node.rawContent.data.Content.title}  
         </a>  
       </li>  
       <p>  
        {  
         data.node.rawContent.data.Metadata.metadata.description  
        }  
        </p>  
      </ul>  
       )  
     }  
    </div>  
   );  
  }  
 }  

And Finally, our News and Article Landing page with DCPs is ready, not the very attractive UI though 😊 

DCPs Rendering on ReactJS app

In the next blog, we will be creating News details page and will try to implement search and other features as well. 

Part -2 Create News detail page and Production Build

You can download the sample application from GitHub, don't forget to update the PCA URL 

Happy Coding and Keep Sharing !!!! 

Configure Workers, ActiveMQ and Redis for Scalable Deployment in SDL WEB 8.5

This is in continuation of my previous blogs where we discussed how to install CM and publisher on a dedicated machine and then, we saw how we can implement scale out content deployment using workers, ActiveMQ and Redis. Today, we are going to see how to configure Workes, ActiveMQ and Redis.

To read more about last two blogs in this series:-

1. Scaling SDL WEB 8.5 Installing CM and Publisher on Dedicated Machines
2. Scaling Deployers in SDL WEB 8.5

In order to configure the scalable content deployment, we need Deployer(Endpoint) and Deployer-Worker.

Deployer Installation Media

Pre-requisites, we need to install ActiveMQ and Redis

1. How to install Redis please check my previous blogs.
2. Download the Apache ActiveMQ
1. Unzip the package in a suitable location and from command line execute command activemq start.
2. Open your browser and navigate to the Admin Console at http://localhost:8161

Next step is to configure Deployer-Endpoint and Deployer-Workers Microservices.

1. Both these services are required to update the deployer_conf.xml and Deployer-Workers required cd_storage_conf.xml.
2. In the Deployer-Endpoint installation media open deployer_conf.xml.
1. Here we need to update the <BinaryStorage> node and point this to Redis data store.

   

   Configure Redis in Deployer-Endpoint

2. we need to configure the <State> node. so that workers know where to update the status of a job and the endpoint knows from where to get the status of the job.

   

   Configure State

3. Next, is we need to configure ActiveMQ, we also need to make sure that all the other <Queue> entries related to FileSystem are commented out.

   

   Configure Apache ActiveMQ JMS

4. Save and close the deployer-conf.xml file and use this same file for Workers as well.
5. Next step is to configure the cd_storage_conf.xml for Deployer-Workers only.
1. Here we need to update the <Storage> node with the Broker Database details. The worker will deploy the content on this DB.
2. Update the License file path.
3. Save and close the file and we can use this same file on the second Deployer-Worker.
6. Now, we need to configure the ports for Deployer-Endpoint and Deployer-Workers.
7. Last run the installService.ps1 from the Deployer-Endpoint folder and from Deployer-Worker. You need to run the command more than once depending upon the number of Deployer-Workers you want.

   

   Deployer-Endpoint and Deployer-Workers are installed  

8. We have all the services configure and up-running.
9. The final step is to register your Deployer (Endpoint) with your Discovery Service and run the discovery-registration.jar.

Happy Coding and Keep Sharing

Scaling Deployers in SDL WEB 8.5

This is in continuation of my previous post where we discussed how to set up Publisher and CM on a dedicated machine to improve the publishing efficiency click here to Read More.

Today we are going to see how to scale out Deployers, using multiple deployers and workers.

High-Level Achrciture diagram 

Steps:

1. Content is passed to the Deployer after a user Publishes an item in the CME.
2. The Deployer Endpoint passes the Transport Package (.zip file) to the defined Binary Storage (File System or Redis Database). We are using Redis right now.
3. The Deployer Endpoint also passes the item to the Queue in ActiveMQ (JMS).
4. ActiveMQ triggers an event that informs the Worker Deployers that a new package has been received.
5. The first available Worker Deployer picks up the job from the Queue and contacts the Binary Storage to get the respective Transport Package.
6. After rendering the Transport Package the Worker Deployer passes the item to the Broker Database.
7. The Deployer then gets the status of the job from the Broker Database, which is updated by the Worker Deployer responsible for that job.

In the next blog, we'll see how to configure Workers, ActiveMQ and Redis.

Happy Coding and Keep Sharing 

Multiple Destination Publishing Using - MIRROR strategy in SDL WEB 8.5

What is Multiple Destination Publishing?

Multiple destination publishing means that the transport service can publish to multiple deployer destinations (if you have more than one deployer).

DEFAULT strategy means that there will be only one deployer only one URL is registered in discovery-service).

MIRROR strategy means that you can have more than one deployer (multiple URLs are registered in discovery-service) and transport service will send the package to all of the deployer URLs register in discovery service.

How to configure Multiple Destination Publishing?

We can do this by defining the strategy for the DeployerCapability which is registered in the Discovery Microservice cd_storage.conf.xml:

If you have set up multiple Content Deployer destinations, do the following in order to setup MIRROR strategy:

1. Ensure that this Role element has a Strategy attribute, set to MIRROR.
2. Inside the Role element, insert a Urls subsection, itself containing two or more Url subelements. Each Url element must have a Value attribute, set to the URL of the destination, and can have a DestinationName attribute, set to the name of this destination

Strategy Attribute 

This Role has one Capability URL (value DEFAULT, to be specified in the Url attribute) 

or multiple ones value MIRROR, to be specified in the URLs subsection. Defaults to DEFAULT is not specified.

Happy Coding and Keep Sharing !!!

SDL Web Hackathon 2018 - Published Summary Plugin

Published Summary Alchemy-Plug In project has been conceptualized and initiated for SDL Tridion Developer Summit, Amsterdam Hackathon for the year 2018.

The entry for Hackathon has been entered with the team name - "CB Ke Cheete" and for the project "Published Summary" Alchemy plugin.

Team Members 
The team - "CB ke Cheete" - having meanings as "Cheetahs of CB", comprises of three young and dynamic Content Bloom professionals. The team has following members:

• Pankaj Gaur - Director, Content Bloom | SDL Certified Dev and BA | SDL Tridion/Web MVP
• Hem Kant - Consultant, Content Bloom | SDL Certified Dev and BA | SDL Web MVP
• Priyank Gupta - Consultant, Content Bloom | SDL Certified Dev

This plugin is intended to do the following:

1. Get all items within a publication, folder or structure group published to one or more Publishing Target Types.
• Let's say if we select Publication then the response will be all Published  Pages, Components, and Categories in that publication.
• If we select this plugin from Structure group, then we will have all the published pages in the structure group and same goes for Folder selection all Published ComponentTemplates and Components.
2. Republish, Unpublish and open a specific item.
3. Republish or Unpublish multiple items on their respective Publishing Target Types.
4. Export in CSV.
5. Filter based on Publishing Target Types, Item Type (Component, Pages etc.), and Published Date Range.
6. Sorting based on Title, Published Date, Published By, Targets, and TCM URIs.
7. Searching.
8. Summary of published building blocks across all publishing target types.

The Published Summary Alchemy Plug-in can help in following scenarios:

1. You want to export a list of all published items from Tridion for a specific website (or for a specific structure group/folder within a website) in CSV format.
2. You want to see/export all published items from Tridion for a specific Publishing Target Type and compare among all publishing target types for a specific CMS instance.
3. You need to know, what all need to be published from Tridion in order to make a specific website up and running similar to an existing website.
4. You need to know a summary of "how many" specific items are published from Tridion to individual publishing target types.
5. You need to know about "delta" of published items across publishing target types of a CMS instance.
6. You need to sync your non-live websites with the live websites in terms of content managed from Tridion.

Published Summary

Happy Coding and Keep Sharing !!!

Client Side Caching in SDL DXA using Redis

What is Redis?

Redis (Remote Dictionary Server)  is an in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs and geospatial indexes with radius queries.

Redis is good for cache, but it's much more than just a cache. It's high speed fully in-memory database.

Not just a cache:-

• In memory key-value storage.
• Support multiple datatypes (strings, hashes, lists, sets, sorted sets, bitmaps, and hyperloglogs).
• It provides an ability to store cache data into physical storage (if needed).
• Support the pub-sub model.
• Redis cache provides replication for high availability (master/slave).

SDL DXA comes up with the pre-defined configuration of Redis for client-side caching to improve the performance of Web-application.

Pre-requisites:-

• SDL Web 8.5
• SDL DXA 
• Redis
• Redis Desktop Manager
• Redis Server and Redis CLI
• And If you want to run this on docker run docker pull redis command. Check out the official Redis repository on the docker 

Installing the Redis

• Download the Redis and extract the zip file in a directory at any location.e;g in c:\redis

  

  Redis

    Next is open the command prompt and run following command

• redis-server.exe to start the Redis server

  

  Redis server

• redis-cli.exe to start the command line interface. redis-cli is the Redis command line interface, a simple program that allows to send commands to Redis and read the replies sent by the server, directly from the terminal.

  

  Redis CLI

Next, is configure DXA to use Redis for client-side caching go to DXA web.config and navigate to <sdl.web.delivery>  node and there we already have Redis configuration setup we just need to update the cacheName. You set the policy of expiry as per the requirement.

Redis Configuration in DXA Web.config

Restart the IIS and spin the DXA Website, the site will trigger the page caching and it will add it to the Redis database.

To test the data is saved in Redis or not install Redis Desktop manager and refresh the page to load the data. In the below image you see data is cached in the Redis.

Redis Desktop Manager

Happy Coding and Keep Sharing!!!