Sitecore WFFM IsRemoteActions and Scaling Considerations

One of our Sitecore implementations was experiencing WFFM exceptions when trying to send emails from CD servers.  This post about WFFM configuration over on the Community site for Sitecore ends with a vague answer to fix a scenario such as this via the following:

Please remove the below mentioned setting from “Sitecore.Forms.Config” from all CD instance.

<setting name=”WFM.IsRemoteActions” value=”true” />

we have also added this setting as per sitecore documents but after adding this line on CD instance, mail won’t trigger. You have to remove this setting from “Sitecore.Forms.Config”. Making value as “false” won’t fix the issue.

Unfortunately, this is a fairly common scenario on that Community site . . . there are certainly answers tucked away in there if you’re diligent in your research, but sometimes they can leave you with more questions.  I think the new StackExchange site for Sitecore is a breath of fresh air on this front, but for this specific question about WFFM I was left to puzzle over this WFM.IsRemoteActions setting.  Here’s what I uncovered.

The official Sitecore documentation for setting up WFFM explicitly states (on page 6 of the WFFM 8.1 Update-3 installation guide in our case, but it’s mostly the same for other versions):

In the \Website\App_Config\Include\Sitecore.Forms.Config file,

• Add the following node to the section:
• <settings> section: <setting name=”WFM.IsRemoteActions” value=”true” />

The above contradicts the guidance on the Sitecore Community forum, and in our case we found that removing this setting altogether DID correct our problem of WFFM emails not being sent.

I used Reflector (like always!) so get some insight into what was going on, and in the Sitecore.Forms.Core.Handlers.FormDataHandler type is an ExecuteSaveActions method that is the crux of the logic for processing forms that are submitted through WFFM.  Right near the top of this method is a big conditional test based around the WFM.IsRemoteActions setting:

When one removes this setting from a CD server, this logic short-circuits this ExecuteSaveActions method and prevents the CD node from following through on the WFFM activities . . . and instead the Sitecore EventQueue of the “Core” database is used to store a record of this WFFM action.

At a later point, a server that shares that Sitecore “Core” database AND is configured with the proper WFFM hooks and events definition (from Sitecore’s WFFM documentation on Multiserver configuration) as follows . . .

The  section: 
<!--HOOKS-->
<hooks>
<!--remote events hook-->
<hook type="Sitecore.Form.Core.WffmActionHook, Sitecore.Forms.Core"/>
</hooks>

The  section: 
The <events> section:
<!--Remote events handler-->
<event name="wffm:action:remote">
<handler type="Sitecore.Form.Core.WffmActionHandler, Sitecore.Forms.Core"
method="OnWffmActionEventFired" />
</event>  

  . . . will pick up the EventQueue record and run the WFFM event.  Usually this is the CM server.  This is how it all worked in our case.

By removing (or setting to false) this WFM.IsRemoteActions setting we’re asking less of our Sitecore CD servers and centralizing the WFFM save behaviour to the CM server.  Most Sitecore implementations are eager to find ways to reduce the demands on the CD nodes in an implementation, so this measure could be considered a best-practice if you’re using WFFM and looking to save Sitecore CD cycles (CPU!) for responding to HTTP requests for site visitors instead of performing WFFM post save actions.  To me, it looks like you could take this further and delegate this responsibility to a “processing” server if you’ve got one in your scaled Sitecore architecture . . . or any node that suits you.