7

In ECM 2.2, the RegisterEmailOpened.aspx was located in sitecore_modules directory, which is mapped to the Sitecore site "modules_shell". In EXM 3.3, this page is moved to /sitecore/ and made an ashx. Okay, cool...

Method #1: Use URL Rewrite to redirect to the new location. For whatever reason, whether it's stupidity or lack of regex understanding, I could not get a rewrite rule to redirect. Aborted.

Method #2: Created an aspx page in the same location to force a redirect. Turns out, this is the method I REALLY want to do, because before doing the redirect, I've realized that I need to do work to convert the query params from ECM 2.2 to EXM 3.3 query params before going to the new EXM 3.3 location -- Therefore, this is actually the method I want to use. but having complications.

Issue: The complications are that I need to instantiate the Sitecore Analytics Tracker in order to identify the user and create an Xdb Contact record if one doesn't exist. But "modules_shell" has EnableTracking set to false in the Site Definition.. (to wit I'm assuming is for a reason), meaning that the "startAnalytics" pipeline aborts out before creating the Tracker.

Research: I thought it was because I have a blank for Analytics.The hostname for the longest, but it's actually not even getting to that point. That may still be an issue, and figuring out how I need to set Analytics.Hostname for a multisite environment is my next research question.

Is there any reason why I WOULDN'T want to set EnableTracking true on the modules_shell site in Sitecore?

  • I would have thought the authors would account for this. The tracker is for 'tracking' sessions and page visits. I expect the EXM handler receives enough parameters through the query string to do its job without the use of the tracker. So the real question is: why would you enable the tracker on the modules_shell site? A rewrite rule is the correct way to solve this. – Richard Hauer Sep 21 '16 at 22:28
  • Hi Rich, I agree. EXM generates all.of the information that it needs. However this particular scenario is providing backwards support from OLD links out of ECM to new links in EXM. The query data in ECM links is not sufficient in order to do a straight Redirect rule. I need to process the old params and create new params for EXM. This piece of the puzzle requires that I create or load contacts from xDB. If the contact exists in xDB, not a problem. If the contact doesn't exist then I have to identify with the email address, to create the contact, which is presenting the issue. – Pete Navarra Sep 21 '16 at 22:46
  • Can you PM me - I have something that may be of use to you. – Richard Hauer Sep 22 '16 at 3:30
  • A client solved this by creating a handler at the old EXM location that looks up the contact and re-creates the correct (v3) link parameters, then redirects the user. Seems like that's what you are trying to do as well. I may be able to get some code that is of use to you. If I can "genericise" it and get permission from the client, I'll make a blog post. – Richard Hauer Sep 22 '16 at 3:36
  • Seems there's no "PM" functionality in SO, so if you can make contact with me via email or from the contact page on www.ping-works.com.au, or via LinkedIn or use your ingenuity... then I can give you the code you will need. I can't post it here I'm afraid. – Richard Hauer Sep 22 '16 at 4:44
3

This might be slightly off topic, but I can give you a bit of background info.

In EXM 3.3 you can move/change the email open handler by modifying the configuration setting EXM.OpenHandlerPath in Sitecore.EmailExperience.Core.config.

The EXM 3.3 open handler does not require the tracker. It creates an interaction using the interaction registry. See Register interactions using the interaction registry.

There is a way in EXM 3.3 to convert legacy query strings into the new query string format. This is done in the transformQueryString parameter, but you'll need to enable the DecryptLegacyQueryString processor. The email open handler is already using this pipeline, but the legacy querystring processor is disabled by default.

  • According to you, we can handle legacy links and new links simply via configuration settings? No need for custom code? Or did I misunderstood something? – Vicent Galiana Sep 22 '16 at 7:50
  • Not all legacy links unfortunately. I forget how far the backwards compatibility goes back, but some old links contains a (automation state) plan id and no contact id. An older version of EXM/ECM used this plan id to look up the contact id. EXM 3.3 can't do this unfortunately. – Jacob Nielsen Sep 22 '16 at 7:55
  • Yeah, that was the issue I was having. A client is going from ECM 2.2 one day, to EXM 3.3 the next day. I had to rebuild full backwards compatibility. Hence a lot of my odd EXM questions. – Pete Navarra Sep 22 '16 at 11:14
  • 1
    I see. It should not be necessary to initiate the tracker though, but you will have to do the mapping between plan id and contact id. – Jacob Nielsen Sep 22 '16 at 11:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.