My Experiences with Sitecore Upgrade

In one of my projects, I was assigned to upgrade ECM to EXM. We have upgraded our Sitecore using database upgrade approach as follows.

Sitecore 7.5 ==> 8.0 ==> 8.x.x

1. Execute DB scripts for Core, Master, Web and Analytics databases.
2. Install Sitecore upgrade package for 8.X (8.X.X)

After successful upgrade to each version Publish Site and rebuild indexes.

Now download Sitecore 8.2.2  instance(in my case we have upgraded to this version) and changed database connection strings to point upgraded database. This way we were sure that we have proper Sitecore base package with upgraded code.

Solution Upgrade

Remove all references to an older version and replace with latest Sitecore 8.2.2 references. Disable all customization (Sitecore patching) done in the solution.

Make sure your solution is building, and then deployed to your upgraded website.

Make sure your CMS is functioning properly.

EXM Upgrade

There are very path-breaking changes from ECM 2.2 to EXM 3.4.1

1. MongoDB Contacts instead of ECM Contacts (ECM Contact is just wrapper around Sitecore User)
2. Subscription List instead of Target Audience
3. SetTargetItem rendering is removed
4. Manager Root Template is changed
5. Message State “Drafts” is renamed to “Draft” in EXM 3.4.2
6. Message Types are renamed from ad-hoc to OneTime, periodical to Subscription and Trickle to Triggered.

Post-installation of the new EXM package few items which are in ECM 2.2 were still present and are not overwritten.

Fixing EXM core fields after package installation

referred blog:https://tresteil.wordpress.com/2016/11/25/sitecore-exm-issue/

Change Drafts to Draft

UPDATE [dbo].[SharedFields]
SET [Value] = ‘Draft’
Where Value = ‘Drafts’ and FieldId = ‘AF0FE26A-A78B-491D-885C-03D95BC17342’
GO

USE [Dev_DOH_Sitecore_Master822]
UPDATE [dbo].[SharedFields]
SET [Value] = ‘OneTime’
Where Value = ‘ad-hoc’ and [FieldId]=’0934BEC4-325A-427B-95BB-46F78CEA9591′

GO

SELECT [Id]
,[ItemId]
,[FieldId]
,[Value]
,[Created]
,[Updated]
FROM [dbo].[SharedFields]
where value=’ad-hoc’
and [FieldId]=’0934BEC4-325A-427B-95BB-46F78CEA9591′
GO

Change Periodical to Subscription
UPDATE [dbo].[SharedFields]
SET [Value] = ‘Subscription’
Where Value = ‘Periodical’ and [FieldId]=’0934BEC4-325A-427B-95BB-46F78CEA9591′

GO

SELECT [Id]
,[ItemId]
,[FieldId]
,[Value]
,[Created]
,[Updated]
FROM [dbo].[SharedFields]
where value=’Periodical’
and [FieldId]=’0934BEC4-325A-427B-95BB-46F78CEA9591′
GO

Change Trickle to Triggered
UPDATE [dbo].[SharedFields]
SET [Value] = ‘Triggered’
Where Value = ‘Trickle’ and [FieldId]=’0934BEC4-325A-427B-95BB-46F78CEA9591′

GO

SELECT [Id]
,[ItemId]
,[FieldId]
,[Value]
,[Created]
,[Updated]
FROM [dbo].[SharedFields]
where value=’Trickle’
and [FieldId]=’0934BEC4-325A-427B-95BB-46F78CEA9591′
GO

EXM and Web API (Blessing in Disguise)

In many projects, we have plugged WebAPI with Sitecore. In most of the scenarios programmers used following code

public static void Register(HttpConfiguration config)
{

// // force JSON responses only (no XML)
config.Formatters.Clear();
config.Formatters.Add(new JsonMediaTypeFormatter());

// set camel case formating for JSON to c# object
// this lets us have a json object { “id”: “123”} map to C# object property Id {get; set;} and vice versa
config.Formatters.JsonFormatter.SerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver();
}

And when you deploy this code In Authoring Environment, your EXM will not function correctly.

The reason is this code forces your controller to follow JSON naming conventions for the code. Unfortunately, Sitecore still follows C# style naming conventions in their client-side API. e.g. If you return Person object using above code. It will be returned as

{ firstName:”Mohit”, lastName: “Dharmadhikari”}

however Sitecore default functionality is expecting C# style properties

{FirstName:”some-value”, LastName:”some-value”}

Since javascript is case-sensitive it obviously throws undefined for the above properties.

You should write the above code only for Delivery Role and it should allow your web API to work as expected and authoring environment as well.

 

Hope this Helps!