Today, Sitecore has released the next big update for Sitecore 9, Sitecore Experience Platform v.9.0.1 rev. 171219.  This is a really big and highly anticipated release, solving a number of known issues around Sitecore Forms and other bug fixes.  But more importantly is the first version for Sitecore 9, let alone Sitecore in general, where the Email Experience Manager (also known as EXM and formerly known as ECM) is completely integrated into the native product as a singular platform.  This post hopes to open a window into the changes that have been made in the product and acclimate developers, clients, and product owners so that they understand what to expect when either upgrading or installing fresh.

Email Experience Manager At A Glance

Fully Connected Platform

One of the major accomplishments of this version of Sitecore is the roll-up of EXM completely within Sitecore’s Platform product. That means there is no longer a separate module which has to be installed to use EXM. Over the last year, one of the biggest issues with EXM was that fact that the module was so tightly coupled to the version of Sitecore, that each EXM release required the next available version of Sitecore.

With EXM now in the main product, changes to EXM will be rolled out and provided at the same time as the main product. This allows List Manager, Marketing Ops, and xConnect to be a seamless experience.

Additional Sitecore Role Added to Configuration

With Sitecore 9.0.1, a new Sitecore Role Server configuration has been added called DedicatedDispatch. This allows a Sitecore instance to be configured as an EXM Dedicated Dispatch Server.  Scaling Sitecore, and more importantly, scaling EXM is really as simple as scaling out the number of dispatch servers being used. This allows you to send more messages over shorter periods of time.

Introduction of Rebus

A big improvement in EXM, and more importantly to Sitecore 9 is the introduction of Rebus. Rebus is a slim and efficient service bus implementation, very similar to NServiceBus and Rhino ESB, specifically for the .NET platform.  The main goal of Rebus was to create a service bus that adhered to the “smart endpoints, dumb pipes” methodology.

For clarity, Rebus is not used to actually dispatch messages (so comments below about messages and messaging are not about dispatch). Instead, Rebus is being utilized to handle the communication needed from the Content Delivery servers back to the Content Management server and Automation Engine.

In previous versions of EXM, the Content Delivery servers needed a connection string that pointed back to the Primary CM, which caused issues for many IT departments and NETOPS that didn’t like edge delivery servers pointing back to servers behind the firewall.  By using a messaging service, like Rebus, this problem is solved.

Some features of Rebus include (pulled from their wiki):

• common message exchange patterns like point-to-point, request/reply, and publish/subscribe made easy
• advanced coordination of messages, i.e. process managers
• timeout manager that allows message delivery to be deferred to the future
• a message can be transferred using MSMQ, RabbitMQ, Azure Service Bus, SQL, and even the file system.
• handler pipeline re-ordering
• MSMQ queue inspector

While Rebus was only implemented for purposes by EXM, the fact that Rebus is now available on the platform could have some really neat future implementations. One off the top of my head is revamping the dreaded EventQueue table. Imagine not needing that table, and instead using a real Service Bus system to fire remote events on different servers. This is a huge improvement which could see additional usage later on in the product.

Seamless Marketing Automation Experience

One of the biggest improvements in Sitecore 9, the product itself, was the overhaul of the marketing engagement plans and funnels and the creation of the Marketing Automation application in Sitecore. This allows Marketers to create intuitive marketing workflows that can handle a variety of actions depending on the state of a contact in the workflow.

Now, automating triggered emails are as simple as dragging the Send Email option into the Automation Workflow and specifying an Email Campaign.  You can do other fun stuff, like adding a contact to a List, validating that a user received and clicked on an email, and listening to events.  All within the same platform. This allows you to have handcrafted experiences for your site visitors.

Key Enhancements and Changes

Below is a summary of the stated changes that come along with the update of Sitecore 9.0.1.

• Exm.web database has been removed and is no longer needed.
  • The purpose of this database was:
    • to help with some of the communication between the CD servers and the Primary CM server
    • to keep a cache of opens and clicks to determine which are unique.
      • This is now done during processing.
  • This has been replaced with the Rebus messaging service.
• A couple of sub-layouts have been removed.
  • Process Personalization Tokens
    • This sub-layout was included in a lot of messages. The removal of this rendering causes a rendering to be missing from the presentation properties of existing emails.
  • Subscription Form
    • This was removed. Instead, subscriptions can be implemented using the xConnect API and/or the EXM client api.
• The existing Email Campaign folder has been moved to just Email and has been moved out of /sitecore/system/Modules to /sitecore/system/Settings/Email.
• The Email Preview and Spam Check functionalities have been completely removed.
  • Sitecore released n article on this a while back. Litmus has changed some of their terms which prevented Sitecore from using the service.
• Target language can now be specified when sending automated messages through the client API.
• EXM.DispatchBatchSize setting has been added that allows you to specify the number of contacts that are processed at a time.
• EXM.IncludePIIinLogFiles setting has been added that specifies whether EXM should log PII-sensitive data.
• New web.config setting (<eds:define>) allows for the specification of using Custom SMTP or Sitecore’s Cloud Email Delivery Service.
• Automated message has a new Import HTML option
• Over 600 public methods have changed.
• Over 400 types removed.
• Around 50 changes to public fields
• About 20 interface changes
• Big Change in Factories
  • Removal of Major Factories in the Sitecore.Modules.EmailCampaign namespace:
    • BusinessLogicFactory
    • EcmFactory
    • IoFactory
    • GateWayFactory
    • Factory
  • These have all been replaced with much smaller and more numerous factories responsible for creating a single type.
    • Most of the new factories can be found in the following namespaces:
      • Sitecore.Modules.EmailCampaign.Factories
      • Sitecore.EmailCampaign.Cm.Factories
  • All factories are registered with the IoC container and can be customized like any other Sitecore provider using config patching.
  • RecipientManagerFactory removes the RecipientManager from the message item and now allows RecipientManager to be created from the factory.
• The getXdbContactRecipient pipeline has been removed, as well as the related contact abstractions in the Sitecore.Modules.EmailCampaign.Recipients namespace.
  • Loading custom facets during a dispatch now require a custom dispatch task and an override of the GetContacts method.
  • This task is configured in the Sitecore.EmailExperience.ContentManagement.config in the /sitecore/exm/dispatchTask config node.
• Email Links query strings have changed (again).
  • The ec_contact_id query string has been replaced with ex_id_s and ex_id_i.
    • This is because xConnect Contact Identification now requires both a tracking identifier and an identifier string.
• Two new Services provided
  • ContactService
    • Utilized to load contacts or retrieve contact identifiers, and is referenced in all old code paths where contacts are loaded.
  • EXMCampaignService
    • Utilized to retrieve the message item and related campaign activity.
• Personalizing Custom Tokens is easier with a refactor of the DefaultRecipientPropertyTokenMap and the removal of the getXdbContactRecipient pipeline.

Upgrade and Migration Experiences

It is important to note that for lack of a better way of saying it, there is no upgrade path for prior versions of EXM with Sitecore 9.0.1.  The best advice is to install Sitecore 9.0.1 new (or upgrade from Sitecore 9) and use the xDB Data Migration Tool to upgrade your xDB data to your newly installed Sitecore 9.0.1.  Sitecore will be providing a detailed migration document for migrating from EXM 3.5 to Sitecore 9.0.1 in the near future.

For emails that have been sent with previous versions of EXM, the <redirectUrl> pipeline has been adjusted to ensure that the original ec_contact_id query string parameter is still found and utilized correctly.  However, my advice is to test thoroughly with older messages to ensure that the URL query parameters are being read appropriately. If any change is needed, you will want to evaluate the internalCarryoverFields processor node in the <redirectUrl> pipeline.

Tagged as: EXM, Sitecore

Categorised in: EXM, Sitecore, Uncategorized