Tag: Sitecore
Connecting Sitecore to Salesforce

Connecting Sitecore to Salesforce

When it comes to creating CMS websites the most common integration requirement is one to a CRM system. In this article I’m going to explain the different methods of integrating Sitecore and Salesforce along with the advantages and disadvantages of each.

Salesforce Web to Lead

The first option isn’t Sitecore specific at all and is functionality provided and supported by Salesforce. Web to Lead allows you to create a HTML form from within Salesforce that when submitted will create a Lead item in Salesforce. To add it to your Sitecore instance can be as simple as copy and pasting the generated HTML and setting up a confirmation page for Salesforce to redirect to once the form has been submitted.

The process for the form submission is then as follows:

With some extra technical input, as the HTML for the form is hosted on your site rather than through an iFrame, it is also possible to customise it with your own CSS and validation to fit in with the rest of your site.

Advantages

  • Very simple to set up
  • Very low in terms of complexity
  • Easy to maintain
  • No duplication of data in Sitecore (simpler for GDPR)
  • Potential for form to be CMS managed by pasting in HTML from Salesforce

Disadvantages

  • Vulnerable to spam
  • No data is fed back into Sitecore analytics
  • Limited to form submissions
  • Limited functionality

For more information on web to lead see: https://www.salesforce.com/products/guide/lead-gen/web-to-lead/

Salesforce Web to Lead plus some custom code

What’s good about web to lead is it provides a simple platform that can be built upon to fix some of its disadvantages.

With some custom code on the Sitecore side, we can change the process from the visitor submitting a form directly to Salesforce, to a form submitting to Sitecore which in turn does an HTTP Post to Salesforce. This gives us the ability to also add in some protection against spam using something like re-captcha and the ability to record some analytics information in Sitecore analytics.

The process for the form submission is as follows:

Advantages

  • Low complexity
  • Easy to maintain
  • No duplication of data in Sitecore (simpler for GDPR)
  • Protected against spam
  • Built on top of Salesforces web to lead functionality

Disadvantages

  • To make fully CMS-able requires a larger bespoke implementation
  • Limited to form submissions

Sitecore Connect for Salesforce CRM

If you’re after something greater than simple lead creation from a form on the site, then another option is the Sitecore Connect for Salesforce CRM module from Sitecore. This is built on top of Sitecore’s data exchange framework and works by syncing data between the two platforms.

Out of the box it is set up with some default mappings for contact information, but this can be expanded to included additional facets of information against a contact.

Using this type of integration as new contacts are created on the site, they will be created in salesforce too. Or a contact being in a salesforce campaign could be synced to the Sitecore instance to customise the users experience there.

For more information on Sitecore Connect for Salesforce CRM see: https://doc.sitecore.com/developers/salesforce-connect/20/sitecore-connect-for-salesforce-crm/en/sitecore-connect-for-salesforce-crm-configuration-guide.html

Advantages

  • Built and supported by Sitecore
  • Ability to build a more complex integration on a framework

Disadvantages

  • Much higher complexity
  • No quick wins for common scenarios such as creating a lead

Fuse IT S4S Connector

Since 2009 Fuse IT have been building a Sitecore to Salesforce connector targeting the biggest use cases for connecting the two platforms.

The connector is installed as packages into both Sitecore and Salesforce and provide out the box functionality such as:

  • Sitecore Forms and Web Forms for Marketers field mapping wizard to create leads in Salesforce. Which gives marketers complete freedom to add a form to a site that creates a lead in Salesforce
  • Sitecore analytics integration to sync behavioural data to salesforce leads and contacts
  • Sitecore personalisation for a contact from Salesforce

The package also includes sample code to enable expanding the solutions with bespoke development.

For more information on S4S see: https://www.fuseit.com/products/sitecore-salesforce-connector/

Advantages

  • Out the box functionality that takes advantages of Sitecore’s features
  • Ability to build a more complex integration on a framework

Disadvantages

  • Additional license fee
  • Creates a dependency that may affect upgrades in the future

Fully Bespoke

Often when you suggest a fully bespoke solution people can take an instant reaction to fear it will be costly, hard to maintain or will break. Writing traditional code often can get viewed as being bad or hard, but the reality is most alternative implementations still involve writing code but just have a nice interface at the start. Depending on the kind of integration your trying to achieve going fully bespoke might be the easiest solution. After all code is essentially an easy tool to achieve a complex scenario and it is generally the scenario which leads to the problem being hard, rather than a developer’s ability to write code in any given language.

A bespoke solution could be something as simple as a webservice being provided by a Salesforce developer that Sitecore will post to, much in the same way as web to lead, but capable of achieving some additional functionality on top.

Or it could be a middleware API layer that is used to connect multiple systems together. E.g. If your site needed to talk to Salesforce and a stock level system at the same time. Or it could be used to completely abstract the CRM system in order to facilitate Salesforce being swapped out with something else in the future.

Advantages

  • Anything’s possible

Disadvantages

  • Could be to complex for simple scenarios
  • Everything must be built
Sitecore strange language switching

Sitecore strange language switching

The other day we started experiencing a strange issue on one of our test sites. Pages were starting to error and looking at the logs the errors were happening in view's which hadn't been updated in a long time. Some of these seemed like the code wasn't robust enough to handle when a datasource hadn't been set (the classic object not set to an instance of an object error), but fixing these just resulted in an error in another. It also didn't explain why this suddenly started happening, not to mention the components in question should have all had data.

Then we noticed that on the first view of any page of the site with a new session the site would display fine even though these were server errors happening. Navigating to any other page or refreshing though caused the server error to return.

This led us to look at the differences between the request headers and we had our answer. On all subsequent requests the language context had been changed to some random thing which there is no content for. The site itself is not a multilanguage site and only has content for en. Adding the language code into the URL would force the context language back and the page would work again.

How language works in Sitecore

To understand what is happening it's good to know how languages in Sitecore work.

Sitecore is built as a platform which can server content in multiple languages. By default you start with one language in the editor (en) but are able to add more. You can read my blog post from a few years ago on how to do this here (https://himynameistim.com/2015/06/30/sitecore-adding-languages-for-a-multilingual-site/).

Sitecore will recognise which language should be displayed based on a language code in a URL. e.g. himynameistim.com/en-gb/ for English - Great Britian. This is done through the strip language pipeline which picks up these languages and sets the context language.

Config for the link manager then controls if links are generated with these language codes in the URL or not. On a single language site you would have this set to never resulting in URL's without a language code and the default language will be used.

The flaw in all of this though is the strip language pipeline always runs, even when your pages only have one lauange. The pipeline also doesn't check if the language it finds in the url is set up as a language on the site, so quite a lot of two letter combinations will work and change the language context. When this is changed, it is changed for the users session meaning it is possible for a url to inadvertedly cause the language context to change for a user on the site when the site only has one language.

Disabling Strip Language

As the site in question only has one language the fix is quite simple. For multilingual sites the solution is a bit harder.

For a single language site you can simply turn off the strip language functionality. You can do this using a patch config file as follows:

1<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
2 <sitecore>
3   <settings>
4    <setting name="Languages.AlwaysStripLanguage">
5       <patch:attribute name="value">false</patch:attribute>
6    </setting>
7   </settings>
8 </sitecore>
9</configuration>
Removing port 443 from urls generated by Sitecore

Removing port 443 from urls generated by Sitecore

For as long as I've been working on Sitecore there has been this really annoying issue where setting the link manager to include server url and running under https will cause urls to be generated with the port number included. e.g. https://www.himynameistim.com:443/ which naturally you don't actually want.

To overcome this there are a few methods you can take.

Method 1 - Set the Scheme and Port on you site defenition

This is possibly the smallest change you can make as it's just 2 settings in a config file.

Setting the external port on site node to 80 (yes 80) tricks the link manager code into not appending the port number as it does it for everything other than port 80.

1<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
2  <sitecore>
3    <sites xdt:Transform="Insert">
4      <site name="website">
5        <patch:attribute name="hostName">www.MySite.com</patch:attribute>
6        <patch:attribute name="rootPath">/sitecore/content/MySite</patch:attribute>
7        <patch:attribute name="scheme">https</patch:attribute>
8        <patch:attribute name="externalPort">80</patch:attribute>
9      </site>     
10    </sites>
11  </sitecore>
12</configuration>

What I don't like about this method though, is your setting something to be wrong to get something else to come out right. It's all a bit wrong.

Method 2 - Write your own link provider

The second method which I have generally done is to write your own provider which strips the port number off the generated URL.

For this you will need:

1. A patch file to add the provider:

1<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
2  <sitecore>
3    <linkManager defaultProvider="sitecore">
4      <patch:attribute
5          name="defaultProvider"
6          value="CustomLinkProvider" />
7      <providers>
8        <add name="CustomLinkProvider"
9             type="MySite.Services.CustomLinkProvider, 
10                         MySite"
11                       languageEmbedding="never"
12                       lowercaseUrls="true"
13                       useDisplayName="true"
14                       alwaysIncludeServerUrl="true"
15          />
16      </providers>
17    </linkManager>
18    <mediaLibrary>
19      <mediaProvider>
20        <patch:attribute name="type">
21          MySite.Services.NoSslPortMediaProvider, MySite
22        </patch:attribute>
23      </mediaProvider>
24    </mediaLibrary>
25  </sitecore>
26</configuration>

2. A helper method that removes the SSL port

1namespace MySite
2{
3    /// <summary> 
4    /// Link Helper is used to remove SSL Port 
5    /// </summary> 
6    public static class LinkHelper
7    {
8        /// <summary> 
9        /// This method removes the 443 port number from url 
10        /// </summary> 
11        /// <param name="url">The url string being evaluated</param> 
12        /// <returns>An updated URL minus 443 port number</returns> 
13        public static string RemoveSslPort(string url)
14        {
15            if (string.IsNullOrWhiteSpace(url))
16            {
17                return url;
18            }
19

20            if (url.Contains(":443"))
21            {
22                url = url.Replace(":443", string.Empty);
23            }
24

25            return url;
26        }
27    }
28}

3. The custom link provider which first gets the item URL the regular way and then strips the SSL port

1using Sitecore.Data.Items;
2using Sitecore.Links;
3

4namespace MySite
5{
6    /// <summary>Provide links for resources.</summary> 
7    public class CustomLinkProvider : LinkProvider
8    {
9        public override string GetItemUrl(Item item, UrlOptions options)
10        {
11            // Some code which manipulates and exams the item...
12

13            return LinkHelper.RemoveSslPort(base.GetItemUrl(item, options));
14        }
15    }
16}
17

4. The same provider for media

1using Sitecore.Data.Items;
2using Sitecore.Resources.Media;
3

4namespace MySite
5{
6    /// <summary> 
7    /// This method removes SSL port number from Media Item URLs 
8    /// </summary> 
9    public class NoSslPortMediaProvider : MediaProvider
10    {
11        /// <summary> 
12        /// Overrides Url mechanism for Media Items 
13        /// </summary> 
14        /// <param name="item">Sitecore Media Item</param> 
15        /// <param name="options">Sitecore Media Url Options object</param> 
16        /// <returns>Updated Media Item URL minus 443 port</returns> 
17

18        public override string GetMediaUrl(MediaItem item, MediaUrlOptions options)
19        {
20            var mediaUrl = base.GetMediaUrl(item, options);
21            return LinkHelper.RemoveSslPort(mediaUrl);
22        }
23    }
24}

What I don't like about this method is it's messy in the opposite way. The port number is still being added, and we're just adding code to try and fix it after.

Credit to Sabo413 for the code in this example

Method 3 - Official Sitecore Patch

Given that it's Sitecore's bug, it does actually make sense that they fix it. After all people are paying a license fee for support! This simplifies your solution down to 1 extra patch file and a dll. What's better is as it's Sitecores code they have the responsibility of fixing it, if it ever breaks something, and you have less custom code in your repo.

You can get the fix here for Sitecore version 8.1 - 9.0.

So this may leave you wondering how did Sitecore fix it? Well having a look inside the dll reveals they wen't for method 2.