Sitecore EXM 9.1 here we go.

It is time to start diving deeper into Sitecore Email Experience Manager (EXM) and really getting to know it. I am working a project that is going to require some fairly advanced customizations with EXM and with the help of SitecoreHacker we will get through it.

First on this list is to make sure we understand how the EXM pipelines are set up. Both Sitecore docs and SitecoreHacker have some good information on this. I am a visual learner so I created this diagram to help me see the pipelines.

It is important to notice that the Newsletter pipeline is different between the CM and the Dedicated Dispatch Server (DDS). The config on the CM manages the process so, it has some additional processes in the pipeline in runs. The send email pipeline is where the real work is done of getting the email and sending it.

The next thing to get into is what happens when SendEmail is called? If you are just using Sitecore EmailCloud or the standard OOTB CustomSMTP you may not care about these details. But when the time comes to customize your email provider you will need to get into these details.

Again, as a visual learner, I put this into a sequence diagram to help visualize what classes were being used and how. It is a fair amount of abstraction layers so keep tracking of what class is used where can be a little hard without some visualization.

Sitecore Dependency Injection

Before we get too far into the breakdown of these classes and methods we need to understand how Sitecore is doing dependency injection.

Let's look at the connection pool manager configuration node.

1 2 3 4 5 6 7 8 9

<connectionPool type="Sitecore.EDS.Core.Net.Smtp.ChilkatConnectionPool, Sitecore.EDS.Core" singleInstance="true" patch:source="Sitecore.EDS.Providers.CustomSMTP.config"> <param ref="exm/eds/connectionPoolSettings"/> <param ref="exm/eds/smtpSettings"/> <param ref="exmLogger"/> </connectionPool>

You will see in this example the connectionPool node has a few child nodes of <param ref="" />. This tells Sitecore what parameter objects it must create and inject as parameters. The Sitecore framework is responsiblef or taking those parameter reference items and searching the Sitecore XML config for the needed notes. So for the first one is searches the XML configuration to find the connectionPoolSettings node (below) and uses that configuration to build out the ConnectionPoolSettings object for ChilkatConnectionPool.

<connectionPoolSettings type="Sitecore.EDS.Core.Net.Smtp.ConnectionPoolSettings, Sitecore.EDS.Core" singleInstance="true" patch:source="Foundation.EXM.Providers.Momentum.config">
  <maxPoolSize ref="settings/setting[@name='NumberThreads']/@value"/>
  <delayBetweenConnectionRetries>00:00:10.000</delayBetweenConnectionRetries>
  <maxConnectionWaitTime>00:00:30.000</maxConnectionWaitTime>
  <maxConnectionIdleTime>00:10:00.000</maxConnectionIdleTime>
  <maxConnectionRetries>3</maxConnectionRetries>
</connectionPoolSettings>

The ChikatConnectionPool class looks like this. Notice the ConnectionPoolSettings class that is passed in and from which the Sitecore framework created it from the configration section above.

public ChilkatConnectionPool(
      ConnectionPoolSettings settings,
      ISmtpSettings smtpSettings,
      ILogger logger)
    {
      ...
    }

SendEmail

SendEmail class looks like this.

public SendEmail(ILogger logger)
            : this(logger, 
              Factory.CreateObject("exm/eds/dispatchManager", true) as IDispatchManager, 
               ServiceLocator.ServiceProvider.GetService<EcmSettings>())
        {
        }

The key learning here is the frameworks ability to create an instance of a class based on a config path. If you look at the showconfig.aspx you will find a node in the configuration like this:

<exm>
  <eds>
     ...
      <dispatchManager type="Sitecore.EDS.Core.Dispatch.DispatchManager, Sitecore.EDS.Core" singleInstance="true"/>
     ...
   </eds>
</exm>

This `Factory.CreateObject` method takes in a configuration path and then creates the object based on that path.So we have seen how the framework has a way to create an object in code or through configration.

Dispatch Manager and Provider

This is a pretty simple class that just makes this call this._providerHelper = new ProviderInitializer<DispatchProviderBase>("exm/eds/dispatchProvider");  Just like the SendEmail class it looks at the configuration to initialize a dispatchProvider that is configured and then calls SendAsync. SendAsync is actually a method on DispatchProviderBase. DispatchProviderBase is an abstract class whose's SendAsync method calls the SendEmailAsync method of that class that implements DispatchProviderBase. The SendEmailAsync method triggers two things. First, it creates the MessageTransport object and hands it the EXM message object. It then uses the connection pool manager that was passed in via dependency injection to get a connection on the transport client.

MessageTransport

This class is responsible for taking the EXM message object and transforming the object into the shape needed for the Mail Transfer Agent (MTA). So in the case of the OOTB options shaping it for SparkPost or a standard SMTP object type. If you are connecting to your own custom MTA you will need to override this class and provide your logic here.

Connection Pool Manager and Connection Pool

The connection pool manager is really just an access point to the connection pool. The connection pools GetConnectionAsync method is used to return a connection for the transport client that should be used. The idea here is that the connection pool class is responsible for managing the state of the connections, how it should retry, how many connections it should allow and the state of the connections.

Transport Client

At this point, we are left with just the transport client. This client is responsible for knowing how to communicate with the MTA. This can be via an SDK from the MTA or a custom client you create. Its SendAsync method is given a message object already shaped by the MessageTransport class for the MTA.

This class also has access to the APISettings classes that is injected and allows the transport client to setup any calls based on configuration data provided in configuration files.

Now you are ready to start building and overrideing areas of EXM sending processes.