Recently I got a chance to work with large migration from SDL Tridion 2013 SP1 to SDL Web8 Cloud – while it might sound as if we are implementing with Web 8 with all our infrastructure on some Cloud – it is in fact quite a different experience all together in terms of development, deployments, project management, UAT etc.
Below is a list of few points I would like to share about my learning:
Disclaimer: Please note this is my own experience while working with SDL Web cloud and you might have a different experience on few of the items while working with it
Development and Implementation
- The development and implementation on an SDL Web Cloud environment might not be the same experience as we have it against an SDL Web Installation on local server or AWS machine.
- You need to work with Amazon Workspace tool – https://aws.amazon.com/workspaces/ to connect to the Workspace environment and execute your development there
- There is an AWS Marketplace – https://aws.amazon.com/workspaces/applicationmanager/awsmarketplace/ – from where you can purchase/download software needed for your development like Visual Studio etc. or you may install your own software if you have valid licenses
- AWS Workspace have a associated licenses cost per developer – so you also need to identify how many developers would be there using the Amazon Workspace
- At maximum, it might happen that you may get Discovery service URL accessible from your local machine which you may use to develop remotely
- In case you have a Custom Database in use – you must check whether this will be supported in the SDL Web Cloud and if yes, how and what would be the connetivity. Typically, you won’t be able to access any Custom DB in case it is deployed in the SDL Web Cloud environment from your local machine as that has to be deployed as an RDS instance and may only be allowed to access it (in case it is at all) from the Amazon Workapce environment
- You may not get privilege to access the environments and deploy your application at your ease – You may need to get a support account to SDL’s ticket system and raise your request through it for deployment. Based on the priority of your request this will be taken in execution – In my case, there was no well defined SLA for a ticket to deploy
- In case you need to debug, investigate or get any information or logs from the environment – you won’t get a privilege to access them at your own ease but have to request them from SDL through their ticketing system
Supported and Out-of-Support stuff
- One very important aspect of SDL Web cloud is the upgrade – you would always be with the updated SDL Web version. As per the best of my knowledge, the SDL Web version would upgrade to next version every quarter.
- The Supported items list for SDL Web 8 on premise and SDL Web8 on cloud is different – this means if a latest SDL Web 8 based application is working on your local infrastructure would not gurantee to work on the SDL Web Cloud
- Typically, everything marked as deprecated (but still working) in SDL Web 8 will not be supported in SDL Web 8 Cloud
- The most obvious thing – legacy mode installation is not possible with SDL Web8 cloud.
- No Additional software installation is possible unless supported by SDL – for example: Setting up a new SOLR instance might not be supported and you may need to rely on AWS Cloud Search instead.
Disclaimer: Please note this is my own experience while working with SDL Web cloud and you might have a different experience on few of the items while working with it
I have recently been working with an implementation involving Web 8 and DXA.
During the implementation we put couple of redirects such redirect from
However, I am continuously getting the below error:
404 - Resource Not Found
Careful investigation suggests that a “traiing” slash is getting added to the redirected URL as –
I keep on investigating by looking at the code, redirect rules, searching over search engines but nothing leads to a resolution. I even tried to look into the DXA framework code to search for any hint but no luck.
Further googling links me to this 2 year old bug in Chrome browser:
which is supposedly fix in a later version two years back itself
Curiously, I tried hitting the URL in other browser and to my surprise it works fine without any issue and as expected.
In the above post last couple of comments (from this year) suggests a browser cache clean (for some other behaviour though) – but I give it a try…and woo hoo!!! It starts working in Chrome too.
Moral of the Story: Technology is Technology – an error might exists anywhere, even at those places you may never imagined.
Few weeks back, I got honored to attend my third MVP retreat and those who really thinks we simply drink beer during this retreat (as few of connection really reacted that way and asked If I am not too drunk can I help them with something :P), we indeed get a privileged to connect with great mind in the industry and SDL technologies and got a chance to collaborate on future of SDL and related technologies.
This year, the group focus was on taking out the best from DD4T and DXA and merge them in a new framework to get the best of both world and create more powerful framework – so a win-win situations for customers as well as vendors/partners/consultants involved in a typical SDL implementation.
Why this merging?
Few years back DD4T comes in existent to provide a framework with possible best practices to use while implementing a website using SDL Tridion system and MVC. This aims to provide a smooth and faster development and adapting to the developers faster who may not have much deeper knowledge of Tridion but MVC (.NET or Java side).
Followed to DD4T, another framework introduced to have already baked frequently used modules in website so as to provide a prototype of website and further reducing the development time. At the core this is also using most of DD4T – initially it is termed as Tridion Reference Implementation (TRI) later renamed to SDL Tridion Reference Implementation (STRI) and finally to Digital Experience Accelerator (DXA)
Both these frameworks were aimed to provide a short development time while still keeping the best practices recommended by the experts in the area and provides noobs a smooth and faster learning curve while meeting the company/customer objectives faster.
Now at one end SDL Tridion has gone through a tons of architecture changes and advancements in the form of SDL Web8 and at the other end massive improvements has been done in the DD4T as well as DXA – This has resulted in branching out of these two solutions from a common goal.
The End Result: Both DD4T and DXA are now competing each other where architects across companies are evaluating both DD4T and DXA to choose which framework to use – The initial aim was both of these framework to complement each other.
This prompts the team behind these two framework to collaborate and agree to combine these two frameworks in one powerful framework to further enhance the development experience.
One of the major advantage DD4T 2.0 is producing the rendered output in the JSON format and removing unnecessary tags/data so as to have a smaller payload while publishing.
Although, till meta-version of DD4T 2.0, the output of Templates can be generated in JSON as well as in XML format, however, in the main release this option has been smartly removed and may have very valid reasons behind it.
On the other side, if you are in real need of getting the XML output (of course at the expense of quite good benefits that DD4T 2.0 provides) then you can follow below simple steps:
- Open CME and navigate to the location where all DD4T 2.0 Templates, TBB and Schema have been installed.
- Open the Parameter Schema – Generate dynamic component – to edit
- Add a new Field of type Text with xml name as SerializationFormat. Also configure this field to select its value from a List with the list have two values – JSON, XML.
The below image depicts this:
- Now open the Component Template for which you want to render the output in the XML Format in the Template Builder tool to edit
- Once in Template Builder, select the Template Building Block (TBB) – Generate dynamic component
- Change the parameter value for this newly added field – SerializationFormat – as XML and “Save & Close” the template. Below screen shot illustrates this:
- That’s it – you are done and now the output of this specific template will be generated in XML format.
Note: If no value is selected for the parameter – SerializationFormat – then by default the output will be rendered in JSON format.
While upgrading to DD4T 2.0, there were some issues/bugs I have encountered – some of them quite obvious, some are tricky and some really drives me crazy – Below is a list of few of them and the resolution which worked for me:
- Installing DD4T 2.0 Templates in a CMS Instance:
While installing the DD4T 2.0 templates using the installer available on DD4T website, it always through below error:
Product: DD4T Templates -- Error 1001. Error 1001. Unable to upload the DD4T Templates into SDL Tridion. Please verify your input.
Error: The transaction associated with the current connection has completed but has not been disposed. The transaction must be disposed before the connection can be used to execute SQL statements.
This issues happens in the scenario when the CM database is being restored from some other environment. Also, this applies to not only installing the DD4T TBBs but also for any Custom TBBs referring the DD4T TBBs.
- Open the Tridion CM database in SQL Server Management Studio
- Locate the table –
Queue_Consumer and open it in edit mode
- Mark status of all other hosts from online to offline – you need to update the field value
IS_ONLINEto 0 for all hosts other than your current host machine.
- Using Component Factory in DD4T 2.0
ComponentFactory in DD4T 2.0 is marked as “deprecated” but the code (which is working fine till DD4T 1.31) does not work while using ComponentFactory in DD4T 2.0.
The ComponentFactory has been marked as deprecated but all the method in the class are throwing “Not Implemented” exception.
This has been raised as a bug with DD4T team and can be followed here – Issue 79
Use Component Presentation Factory instead of Component Factory. If you need to get an IComponent object, then you can use
- Using already published Xml Format DCP with your updated DD4T project
You can use the Xml Format DCP (published through older version of DD4T) with your DD4T 2.0 APIs; however, depending on your Content Delivery code, after update to DD4T 2.0, you might get below error:
Object reference not set to an instance of an object
In the ContentModel.cs class, quite a few numbers of attributes related to Metadata and Keywords are decorated with [XmlIgnore]. Due to this, while you try to Xml Deserialized, you will receive these XmlIgnored attributes as null.
This has been raised as a bug with DD4T team and can be followed here Issue 80
You may either need to wait for this issue to be fixed by the DD4T team or you can take the latest code for the DD4T.Model package, update the ContentModel.cs class in it to remove the [XmlIgnore] attributes. Create a fresh DD4T.ContentModel.dll and replace it in the DD4T.Model package in your project.
NOTE: If you restore your package from nuGet again, it may overwrite your solution.
- Publishing with Custom TBBs referring the DD4T TBBs
In case you have some custom TBBs written for your specific business need and it is expecting the XML format to manipulate with, the publishing will fail in “Rendering” phase
The DD4T 2.0 does not produce the XML format output but only JSON format instead.
Update your custom TBBs such that it does not depends and manipulate the XML format content but accets and work with the JSON format.
Upgrading the Content Manager side with DD4T 2.0 is relatively simple as compared with the Content Delivery side. Typical steps you would be following are mentioned as below:
- Download the Template installer from HERE
- Execute the following batch file from the downloaded template installer and follow the instructions:
- Ensure the batch file gets executed successfully and DD4T 2.0 TBBs and Schema got created in the folder specified while executing the script above
- Now, each and every Component Templates (CT) and Page Template (PT) must be changed to reference these new DD4T as well as require migration of any metadata values from the older TBB to the new TBB
- You will also need to remove the reference to the Publish Binary in Component and Publish Binary in Page TBBs from your templates
- You can now choose to publish the Components/Pages with these updated templates
- Follow the steps 1, 2 and 3 above for a temporary or dev CMS system and ensure the WebDav Path of the folder specified is the same as the existing older DD4T TBBs in the target CMS system
- Create a Content Porter export package of each item in this folder
- You will also need to remove the reference to the Publish Binary in Component and Publish Binary in Page TBBs from your CTs and PTs
- Import the CP Package in the target CMS system
- Caution: this may override the Metadata values specified in the older TBBs
Points to note:
- The new Templates will generate the rendered output in JSON format and if you are using a custom TBB which might be using the older XML format “output” and parsing it, will throw an exception and you need to update your custom TBBs to accept and work with JSON format
- If this is too much of work for specific templates to change the TBBs to accept the XML to JSON – there is small hack can be done for those specific templates to still generate the output in XML format – I will post a separate blog post with step by step guide to do this – Stay Tuned!!
In the process of upgrading your existing DD4T based implementation to latest DD4T 2.0 based implementation, the major effort is required in the Content Delivery side.
You would typically be following below process for upgrading your code/implementation to the DD4T 2.0:
Typically, you would be doing following:
- Removes all references to DD4T 1.31 dlls from each project in your website solution
- Download and Install DD4T packages using NuGet Manager – What all packages you may need to install depends on your specific implementation requirement, however, you would mostly be downloading and installing following packages:
- DD4T.Providers.SDLTridion2013 or DD4T.Providers.SDLTridion2013sp1 or DD4T.Providers.SDLTridion2011
- DD4T.DI.Unity or DD4T.DI.Ninject or DD4T.DI.Autofac – In case you are using a DI mechanism provided by Unity or Ninject or Autofac respectively
- Ensure, all necessary projects now have a reference to these newly downloaded DD4T 2.0.x.x version dlls
Compiling the Solution:
There may be a variety of compile time errors after changing the references to the new DD4T dlls. The magnitude of compile errors and their fixes entirely depends on the implemented code, usage & customization/extending/overriding of DD4T classes/methods and cleanliness of the code. You can get an idea of changes and challenges you might face by referring the below list of typical compile issues I have faced and required a resolution in the code: (The below list may be different in your implementation)
- Change all references of D4T.ContentModel.Logging to DD4T.ContentModel.Contracts.Logging
- Change all references of D4T.ContentModel.Logging.ILogWrapper to DD4T.ContentModel.Contracts.Logging.ILoggers
- Change all references of DD4T.Utils.LoggerService to DD4T.Utils.Logger
- Change all references of DD4T.Providers.SDLTridion2013 to DD4T.Providers.SDLTridion2013sp1
- Change all method calls of GetView(ComponentPresentation) to View(GetViewName(ComponentPresentation))
- Need to re-implement IPage interface for newly added method – IDictionary<string, IFieldSet> ExtensionData
- A variety of DD4T classes now does not have a parameter-less constructor, additionally, most DD4T classes have changes in the constructure signature – This requires a change in all those classes in the implementation inheriting from these DD4T classes.
- PageFactory now does not have a parameter-less constructor and also have its constructor accepting additional parameters – This means if there is any customization/extending of this class, you need to appropriately make changes in that class to support the updated constructor
- TridionControllerBase now does not have a parameter-less constructor and also have its constructor accepting additional parameters – This means if there is any customization/extending of this class, you need to appropriately make changes in that class to support the updated constructor
- Need to change all references to DefaultComponentPresentationRenderer as there is no parameter-less constructor
After all compile errors are resolved, you may come across a variety of run-time errors which also need to be fixed. These run-time errors entirely depends on specific implementations. Few major changes, I experienced while upgrading are as below:
- All references to IComponentProvider must be changed to IComponentPresentationProvider. The IComponentProvider is marked as deprecated in DD4T2.0 so you will not get any compile time error, but actually, all the methods in IComponentProvider are throwing NotImplemented exception.
- Change of IComponentProvider to IComponentPresentationProvider means we also need to change any reference of IComponentFactory to IComponentPresentationFactory
- Above changes suggests, all method calls to GetComponent may need to be changed to GetComponentPresentation.
- Further this means, TryGetComponent would be changed to TryGetComponentPresentation – Please note the parameters order is changed for these two method
- Following new dependencies must be declared for your DI module in use (In my case it was Windsor, so a bit of different process):
There may more or less changes during the run time as well as compile time depending on your specific implementation and code.
BTW – Not to mention the great help from Harald Hoffelinck in identifying and resolving some of these critical issues.
NEXT – Upgrade to DD4T 2.0 – Content Manager (CM)