February 15, 2018

Different types of Content migration

Website is the most important element of any business & digital strategy. In rapid changing web and web technologies it becomes necessary to redesign your website/web app for different requirements.
  • Not responsive
  • Content update to reflection on website takes time.
  • Content creation process is mess.
  • Integration with CRM, DAM, E commerce, Social media.
  • Launch & Translation for new market is cumbersome
  • Conversion is bad
  • Outdated technologies
  • SEO & ranking issues.
Content is king and design is queen, so both needs to be up to date for your business kingdom.
Information Architecture (IA) is very first step in the redesign of the website. Information architecture helps in organizing content so that users intuitively adjust to the website & find without extra effort. Information Architecture becomes blueprint for UX team and wire framing. Though wire framing is becoming out of fashion due to quick turnaround time for design. IA and UX are very important aspects of the redesign.

Content Migration

IA & UX also helps in driving whether existing content can be used or needs to be migrated. Because if existing content does not fit, then new content copies and authoring of same becomes part of redesign project. Due to change in IA and UX new images, device specific images will be required. Content as-is migration does not make sense.
But still there are section of website which require content migrations, blogs, articles any other content which does not get impacted due to above changes.
Content Migration can be manual or automated.
Manual Migration:
It involves a person or team of people doing the work of copying and pasting a site’s content from one system to another. If content to be migrated is not enormous and doesn’t have lots of Media than Manual migration is the one of the choice. But any change in design will cause again going through all the content and update in all the pages, which becomes very cumbersome and error-prone.
Automated Migration
This method requires developers to write script/code to fetch the content from one system and push the content into target system using Target's system's API. (e.g. in SDL Tridion, Core Service is used). Depending on complexity of target system some specialization is always required to write the migration scripts and validation.
Automation migration also falls into two types
  • Source CMS to Target System directly.
  • Intermediate system to Target System.
Hybrid Migration
There are situations when Target system is not yet ready for content authors and authors can't wait till system gets ready, as content size is huge and timelines may get affected.
So an intermediate system is taken where author enters the content instead of Word processing software's. Later on when target system is ready, content can be imported using automation scripts, so a parallel track starts writing scripts to automate the content ingestion from intermediate system to target system.

February 14, 2018

Publish Settings in DXA explained

DXA has few system pages like Html-design, _navigation and “Publish Settings”, out of these Publish Settings is the one which boots an DXA application and considered as the very important system page.
Publish setting provides intelligence to the MVC application to get it work faster and isolated from CMS.
How does it choose what to publish?
So DXA provides a schema called Module Configuration. Whenever a module is created, a component of this schema is created you define the module name, version and related dependencies of it.

Whenever Publish-settings is published. It searches for the all components created with this schema
& generate files which store as binaries in the Broker DB. Above picture is of Core component (Module-Configuration schema). If you see it has listed configuration and Resource dependencies of this module.
Files Generated –  (each files starts with its module name)
/System/config
-          Core.json  - Contains all the configuration values(combined)  from attached components above
-          Core.schemas.json – contains name and id of all the schema of this module
-          Core.taxonomies.json – contain all taxonomies of the system.
There is another file _all.json in this directory which actually list all above files and few other environment settings.
/System/Resources
-          Core.json – a combined file of the entire resource component attached in module configuration.
/System/Mappings
We can say it is master data of schemas & templates, this is not module dependent files but global files.
-          Schemas.json - it contains all the schemas’ definitions from the CMS.
-          Regions.json - it has details of all the regions and details of component template where it’s used, along with linked schema of CT.
-          Includes.json – it contains all the Page Template Ids and associated includes in that PT.
So lots of information required/used by DXA for various purposes.
It needs schemas. Json to map field values to the respective entity, Semantics and XPM in MVC application. So whenever there is change in schema you have to publish “Publish settings” page to reflect the change in application.
Some Tips:
Any change in schema CT’s Region and PT’s includes require users to publish this page. Otherwise you will spend hours to figure out where the heck are my changes.
When DXA boots it loads _all.json of config and resources to read all the respective files and download all these under BinaryData folder of your application’ root directory.