SDL Tridion Sites 9.1 New Feature Integration Framework

Today SDL released the latest version SDL Tridion Sites 9.1 and in this release we have so many new features, but today we are going to discuss the SDL Tridion Integration Framework. These features enable you to quickly connect with your DAM, CRM, ERP, Marketing Automation, Commerce, PIM, Portal technology, Analytics, and Social Media platforms.

In this blog we will see how Unified Extensions/Connectors build using this framework will simplify the process of deploying multiple extensions in SDL Tridion Sites it combines multiple extensions that should be deployed together as a single solution. We can pack all together Content Manager, Content Manager Explorer, Dynamic Content Delivery and External Content Library extensions.

With EMS the problems that it solves is, we don't have to do configuration on multiple places, no need to restart services and IIS, one single package for multiple extensions and one of the biggest advantage is it supports scaled out environments - so if you have 3 x CM, 5 x publishers, etc. it's a one drop shop.

The package that is built contains.

• Single zipped file
• Manifest.json in the root of the zip
• All reference to jars, dlls and other resources in the manifest.json file will be relative to the root of the zip
• Dependent jars and dlls should be in the same folder as the source jar or dll

SDL released number of ready made connectors for us, we can download it from  https://appstore.sdl.com/

1. Adding existing connector [Read More] If the Connector you are adding is written in C# (.NET Core), ensure that version 2.2 of the .NET Core Runtime is installed on the host machine the Content Service. Download the .NET Core Runtime for either Windows or Linux from the following location: https://dotnet.microsoft.com/download/dotnet-core/2.2
2. Build a new connector [Read More]

In the next blog, we will be creating Extensions until then. 

Happy Coding and keep Sharing!!!

  

Manage SDL Microservice using Jenkins

As a developer, if have the access to servers, to monitor, start/stop, reading logs of SDL Microservice your life is very easy, but when we work in a cage environment and you don't have access to servers due to policies or your client has to follow certain standards such as "PCI" and stuff like that as a DEV you don't get the direct access on those machines.

Using Powershell, Yes we can do that, but what will happen when you don't have the permission to run Powershell as well and I worked on a project where, as a developer, I didn’t have the permission to run Powershell as well.

Well, In that case, we ask the DevOps to do this job for us because they are the one having all the access, but this could be a time-consuming process as well, log a ticket and then someone from DevOps address that and as a developer, we might be required to start/stop and see logs of Microservice multiple times.

There is another scenario where you have your content delivery on the Linux box, not all your developers are very familiar with the Linux commands. 

As a best practice, we should always use proper tools in such a scenario, and today we will see how we can configure Jenkins to start/stop/restart SDL Microservices.

Installing Jenkins is really quick and it takes very less time to configure it.

1. Download Jenkins.
2. Open up a terminal in the download directory.
3. Run java -jar jenkins.war --httpPort=8080. Refer screenshot 1
4. Browse to http://localhost:8080.
5. Follow the instructions to complete the installation.

Run the Jenkins.war

Jenkins is installed successfully and We have the initial password to login 

Next is let's configure the Jenkins

Hit the URL in the http://localhost:8080 this is the default port on which Jenkins runs you can change that. It will ask you the first time login secret key.

Initial password 

Next is select the defaults option to configure the Jenkins

Default feature

You can always install other plugins as well from the Manage Jenkins section

Once everything is configured you will see this screen

Jenkins is ready!!

Next is create a job that will start/stop/restart the SDL microservice

Click on create new job

I have created the following three jobs to stop/start and restart Tridion microservice using  Powershell commands we can sh commands in case of LINUX.

Tridion Services

Console output of Restart Deployer Service

Output

For monitoring the health and traffic on the machine we can use Jenkins Monitoring feature.
Go to:- http://localhost:8080/monitoring

Here you will get the necessary information related to the system health using Jenkins,  you can always use any other tool to do this.

Happy Coding and Keep Sharing!!!

Extending Storage Type in SDL Tridion DOCS 2013 SP2

Recently, I got the opportunity to explore and work on SDL Tridion Docs 2013 SP2 where I need to develop an extension. The client is using their own ElasticSearch instance and wants us to continue using the same instance to index DOCS data in it.

To start with I first explored the SDL DOCS documentation to understand if at all storage extension is supported or not and yes Extension is available not just storage but you can extend the Deployer as well :). "Maybe in the next blog".

After, spending some time on Documentation I was clear what I need to do in order to extend the storage type.

For the initial steps "How to set up the JAVA project and generate custom.JAR" you can follow my previous blogs. In SDL Tridion DOCS, we have the following Content Delivery roles and with that data is published into UDP (Unified Delivery Platform).

• Discovery Service
• Content Service
• Context Service
• IQ Service for Indexing and Querying data In/From Elastic
• Contextual Image Delivery
• UGC Service

Coming back, to Extending the Storage we need to configure the Deployer, here we need to deploy custom jar, customDAO.xml and configure the cd_storage file, similar to what we do when extending the storage with Tridion WEB/SITES.

Below is the output captured in the log file in the JSON format after we deployed the custom jar file that contains code to extend and published the item from SDL Tridion DOCS 2013 SP2.

JSON in deployer logs

JSON of Dummy content

In the next blog, we will see what else we can do with this and how much flexible the extension point of storage is, Until then.

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 !!!