If you've ever developed a Sitecore site, or know anything about Sitecore, chances are you know that its documentation is lacking (and that's being kind). This can present some real challenges, the most obvious is the reaction: "I need to do X, and it seems like it's a reasonably straight-forward possibility, but I can't find any documentation on how to achieve it". Again, if you've worked with Sitecore, you've probably had that feeling at least once. The danger in that is actually two-fold though: not only can you not find what you're working on at that time, but after a while you start morphing into the opinion "I need to do Y, but I know Sitecore's documentation won't give me what I want, so I'll not even look into it". Now not only are you missing pieces of documentation that legitimately don't exist, but you're also missing documentation that is out there. The following is from documentation that really does exist, but can be easy to overlook.
If you're trying to implement Web Forms for Marketers in a production environment, it's easy to make the mistake of installing WFM on both your Content Delivery (CD) servers as well as your Content Management (CM) servers. After awhile you may realize that your CM servers aren't reporting WFM data that's being recorded on the CD (live, production site) DB. The solution to this is to actually only install WFM on the CM server. This SDN Post explains how to get this to work. Basically, you're creating a connection string on your CD server(s) that points to a web service established when WFM was installed on your CM server.
Looking at this code snippet, which again should be in your CD config and originates from the above post:
<add connectionstring="url=http://masterhost/sitecore%20modules/shell/Web%20Forms%20for%20Marketers/Staging/WfmService.asmx;user=[domain\username];password=[password];timeout=60000" name="remoteWfmService">
"masterhost" is to be substituted with the domain of your CM site. The [domain\username] and [password] are credentials that can be used to log into the Sitecore desktop on your CM site.
Basically, the above has the CD server pointing back to your CM's DB, so that the CM desktop can then report on data being populated through the CD environment. Of course, the analytics DB works almost the exact opposite to the WFM database (who needs consistency right?). If you're implementing OMS/DMS, you'll want to have your Analytics DB set up on the CD side, and then you use a connection string on the CM side (as explained on page 13 of this document) to point to your CD DB.
Thus, a sample production Analytics conn string may look like:
<add name="analytics" connectionString="user id=[CM_DB_User];password=[CM_DB_Password];Data Source=[CM_DB_Server];Database=Sitecore_Analytics" />
<add name="reporting" connectionString="user id=[CD_DB_User];password=[CD_DB_User];Data Source=[CD_DB_Server];Database=Sitecore_Analytics" />
The above config will allow your CM environment to collect it's own statistics for testing, but the reports within the desktop will display data that is collected on the CD environment.
So, what's important to remember is that WFM should be installed on your Content Management server and your Content Delivery server should point backwards, while your Analytics needs to be on your Content Delivery server and your Content Management server uses config to point up to it and report live production data. That, and of course, even if Sitecore documentation is often times lacking, it's always a good idea to look rather than to assume the answers aren't already out there.
What about the security implication of pointing back to the master database? I thought the point of "switchmasterToWeb.config" was to remove such references? Why are we now allowing a DMZ CD server to talk back to the CM?
ReplyDeleteMy concern as well, DMZ server talking back to CM... how do I resolve? IT doesn't want any security holes.
ReplyDeleteThank you in advance,
Sasha