Deployer/Storage Extension – Remove Dependencies on Tridion – Part-I

One of the thing we have been working in last few months is to generalize and modularize the Deployer extension such as to remove dependencies on Tridion as much as possible (the concept can be applied to a Storage Extension as well).

The main intentions and advantages of this are as below:

  • Removing dependencies on Tridion developer for any custom changes pre/post/during the publishing process. (Custom changes like: clearing a cache, indexing to a search engine, sending notifications etc.)
  • Making upgrade less painful as pulling out the custom logic from custom deployer module
  • In case of SDL Cloud deployment, lesser or no dependency on SDL Support
  • Improved go-to market timeline

The Solution we did is utilized the Serverless architecture in MS Azure briefly described as below:

Part – I

  1. The deployer extension was written in a generic way to fetch all information like component presentation, metadata information etc. and convert it into a json format.
  2. The deployer extension then interact with an Azure Service Bus Message queue asynchronously and pass all the information in json format to the Azure Service Bus Message queue to process

Part – II

  1. On Azure portal; a Service Bus Message Queue is configured to invoked from the deployer extension and accept content in JSON format
  2. An azure function is being written which listen to the Service Message Bus queue mentioned in Step (1) above and accepts the published content in json format
  3. This azure function then applies all business logic and manipulate JSON to extract necessary information for processing and send it another specific Service us Message Queue
  4. For every custom functionality, there would be a Service Bus Message Queue and each of these Service Bus Message Queue will be listen by specific azure function implementing the specific functionality consuming the publish content sent in JSON format to the Service Message Bus Queue
  5. These azure function then take care of all the individual functionalities and offloading the deployer extension for any real logic in it.

A detailed pictorial representation of this implementation and advantages we gain out of this implementation will be described in next blog in the series.

Director at Content Bloom India having 15+ years of experience in Software Development Life Cycle using AGILE, Iterative and RUP approaches. Experience in following: - CMS packages: SDL Tridion, Adobe Experience Manager (AEM), Sitecore, Umbraco, Kentico, and Alfresco - Search Engines: SOLR, AWS Cloud Search, Elastic Search - .NET Technologies: .NET & .NET CE Framework, ASP.NET, ASP.NET MVC, WCF, WinForms - Mobile Development: Android Native App, Windows Mobile App - Database: MS-SQL Server, MySQL - Program Management: JIRA, MS-Project, Trello - Design Tools: MS-Visio, StarUML - Infrastructure: Linux, Windows Server, AWS Have decent knowledge about Core Java, Spring MVC Instrumental in Application Architecture, Designing (HLD & LLD), Coding and deployment .NET applications (Web, Desktop, Mobile). Experience in following domain: - Digital Media & eCommerce - Travel & Hospitality - Aviation Industry - Education - Insurance - Automation - Automobile - Railways Education: Bachelor Degree in Computer Engineering and Post Graduate Diploma in Business Administration with specialization in Marketing

Tagged with: , , ,
Posted in SDL Tridion

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: