Learn time-saving tips for using FXM with sites that have many localized domains.
Sitecore’s Federated Experience Manager is a great tool that can help you start tracking and customizing legacy sites that, for whatever reason, cannot yet be migrated to Sitecore. However, recent experience has made me realize that using it in some real-world scenarios is not as straight forward as it may initially seem.
I recently completed a proof-of-concept implementation for a client with a large legacy commerce site. Their site was localized for nearly 100 countries, each with its own domain. Obviously, the client wanted to manage just one external site in FXM. The FXM documentation that I have been able to find doesn’t really explain how to handle this situation. It pretty much just points you to the Matching Rule field and leaves it to you to figure out how it works.
After playing around with the field for a while, I came to the conclusion that there must be something weird going on because nothing that I tried worked the way I expected. As usual, I resorted to reading through Sitecore’s decompiled code. Here’s what I learned.
To make an external site work with FXM, you have to add a beacon script to that site. When a user visits the site and their browser loads that script, it sends a tracking request back to the Sitecore server. On the Sitecore server, the request is validated by running it through the tracking.validate pipeline. The ValidateByDomainRuleProcessor processor checks to see if the request matches any of the Domain Matcher items under /sitecore/system/Marketing Control Panel/FXM. How it decides if the request is a match is not exactly intuitive.
You would probably think that it would simply evaluate the conditions in the rules field and return the result. But you’d be wrong. Instead, it explicitly parses the rules field and looks for instances of the “where request domain is domain name” rule. If it does not find any instances of that rule, it doesn’t evaluate any of the conditions, it just checks to see if the request matches the Primary Domain and returns that result.
Now that we know what it’s doing, we can figure out a way to work around it. First, add an instance of that required rule. You can just use the same domain that you have in the Primary Domain field. Then add another condition, but switch it to an ‘or’ join rather than the default ‘and’. I recommend using the request header rule to evaluate the Origin header as shown below so that it can match any country-specific top-level-domain. You could also use the regular expression comparer if you want to be a bit stricter.
The Language Rules field is used in a more straight-forward way. It simply evaluates the selected conditions and if appropriate executes the selected actions. Unfortunately, only two rather inflexible actions are provided out-of-the-box. Entering a condition-action pair for every single country sounded like a nightmare, so I recommended that they create a custom action that would resolve the language using business rules that they were already using elsewhere.