To be precise, part of the community still thinks it has a long road to catch up with WFFM…

Sending Email Messages with Experience Forms

One of the biggest gaps was the “Send Email Message” action, not present until very recently in Sitecore 10.1. For more than 3 years, the only supported way was the EXM integration, as my friend João Neto explains in this post.

Noticed the gap, I implemented a free module to provide the community with this feature. Until these days, this is still my most popular module.

But what are the similarities and differences between the two actions? Today, I take a deep dive into the new feature and compare it with my community module.

Installation and Configuration

The new official action comes out-of-the-box. This is convenient compared to external modules: no packages to install. An advantage to Sitecore!

In both cases, you’ll need to fill the SMTP settings with a configuration patch file. You can use the same patch from my module, with localhost settings – Counterstrike!

User Interface

The new action has a nice GUI to configure the action, enabling content editors to write messages in a nice way.

I have to admit, this is much better than having to edit e-mail the templates beforehand.

The new GUI also provides token selection, so now you don’t have to remember the exact field names.

Well, well… looks like the team in charge of this implementation worked very hard! 

Keyword replacement with Form Data

Both actions use the same strategy for data replacement, with field named tokens that are replaced with the respective form data. Sitecore uses the [fieldname] format, while the community uses {fieldname}, which is practically the same.

But again, when it comes to the new GUI and the ability to visually select your tokens from the form fields, the new action is much superior for content editors.

Keyword replacement oddities

There are still some oddities with keyword replacement, that could be easy fixes. Who knows if Sitecore will ever get back to this simple, but very important feature? They should.

No replacement allowed with e-mail fields

It feels strange that none of the e-mail fields (To, Cc, Bcc, and From) can use token replacement. This makes it impossible to send messages using addresses collected in a form.

The “From” field is even more limited, as it does not allow to type e-mail addresses. Instead, the editor should select the submitter in a dropdown. To add new submitters to the list, you have to create new items under the following path:

/sitecore/system/Settings/Forms/Meta Data/Address Book/Senders

This is a serious limitation: the community module allows tokens in any field. This feature is crucial when you want to send emails to (and from) addresses collected in the form. You can’t send a message to the submitted address, or to the right department as selected in a dropdown field.

Defective replacement with the Subject field

Testing the new action, my first submission failed without any visual feedback. The log file showed this curious message:

ERROR [Experience Forms]: The specified string is not in the form required for a subject.

This started to make more sense when you look at the way I configured the subject:

And the content of the “Multi” field when I submitted this form:

It worked fine when I removed the line breaks, so this bug is due to them. This would be an easy fix for future releases. Keep this in mind when you use tokens in the subject, and you will save some precious debugging time!

Compatibility

The new action is only available from Sitecore 10.1 and higher. The community module is still the easiest way to submit e-mails from 9.0 to 10.0, which ensures its relevancy. At least until most of the Sitecore instances are 10.1+. A good clue is the end of mainstream support, found at the Sitecore Product Support Lifecycle:

Full comparison table

If you reached the end of this article and are still unsure, here is a “very unbiased” comparison table:

	Sitecore’s Send Email	Community’s Send Email
Installation	Out of the box	Installable module
Configuration	Configuration file	Configuration file
User Interface	Amazing GUI	Content Editor
Form Data Replacement	Replacement oddities	Total freedom
Compatibility	Sitecore 10.1 and above	Sitecore 9 and above
Developer is awesome	Yes	Yes
Developer can sing	No	Yes

I think it’s a draw!

A bit of History

Surprisingly I couldn’t find anything, then the only options would be sit and wait for something to arise, or create my own tool. As a born eager, I could not stay still and wait to, sooner or later, be parachuted to my next nightmare. Can’t sleep with that!

ETL?

When I started looking for options, based on some of my experiences with other systems, my first thought was to build or extend an ETL tool. ETL, which stands for “extract, transform and load”, is commonly used in data warehouse systems to massively retrieve, filter and modify data across different sources (SQL servers, XML files, Excel spreadsheets, web services, etc).

With so many good tools at the market, building an ETL tool from scratch would not be smart from my part. My best choose would be to pick an existent tool and make it able to read and write on Sitecore databases. The ItemWebAPI would make it possible, but still very low-level. That would also require some significant effort to create the configurations, business logic and interfaces to make it connect and speak with Sitecore.

It stood reverberating on my mind…

Sitecore Rocks?

I also considered creating an extension to Sitecore Rocks. That sounded like a good idea, as Sitecore Rocks already handles a considerable portion of what is needed to connect and interact with Sitecore databases. It also counts with XPath and query builders, whose logic could be used by my module to retrieve data from Sitecore. But in the other hand it would require Visual Studio to run, which would limit the module coverage, and still some UI and low-level implementation would be required.

And I let it reverberating on my mind…

A Sitecore Module?

Speaking in abrangence, my tool would preferable be a Sitecore Module instead of anything else. This way I would save time connecting to Sitecore, as the code would be executed inside of it. I would also save energy translating data back and forth as it reads and writes data on Sitecore, since I could simply use the Sitecore API as usual. That would also make things easier as the whole environment is familiar to me, and I wouldn’t have to dig down to technologies I’m not familiar with. I was trying to be pragmatic on my purpose of shielding from another nightmare with a minimum effort. Extending an existent Sitecore feature would be the best option.

Sitecore Buckets?

My first real attempt was to extend the Sitecore Buckets feature (image below). It has a nice UI for filtering and listing items, as well as some Search Operations that we can use to modify the items selected.

The native Buckets system would still have to be modified in order to be used for what I wanted, but it looked like the best option till that time. Some investigation demonstrated that the change wouldn’t be trivial, more studying and investigation would be needed. I was also not very satisfied with the way that items are filtered, conditions are programmed, and how user friendly it is to build a query.

For some time it simply stood reverberating on my mind…

The Rules Engine – An insight from Digital Marketing

It was during the preparation of a Sitecore training course for Content Editors, targeting Digital Marketing features, that I first considered using the Sitecore Rules Engine for my purposes. Despite it is originally used for other things, such as Content Personalization or Event-triggered custom tasks, the experience was very close to what I was thinking. The way conditions and actions are chained is perfect for flexibility and is also very user-friendly.

That is actually perfect for my intents:

• Rules would now be a way to save a data transforming pattern
• Conditions could be used to select and filter content
• Actions would be responsible for data processing and transformations.
• They are also very easy to code

Then the idea started to flow out of my mind into a real tool…

The Sitecore Rule Processor

Available at the Sitecore Marketplace, Sitecore Rule Processor is the result of my efforts to automatize data transforming in Sitecore. After installed, when a Rule is selected at the Content Editor an icon is shown.

When clicked, it brings up a window to process the rule, where users can easily filter items that matches the rule’s conditions, then execute their actions against all or some of the items:

This way any user can visually build queries to retrieve items, and setup actions to transform them.

The module comes with a series of custom Actions, to increase the number of things a user can do to process and modify items, such as:

1. Add a version to the item at a certain language;
2. Change the item’s template;
3. Copy, Move or Clone items to a certain path;
4. Delete items;
5. Empty an item’s field;
6. Log a message with info taken from the item;
7. Publish the item;
8. Replace a string in a field of the item;
9. Replace a string in an item’s name;
10. Run a script;
11. Serialize the item;
12. Set a value at an item’s field;
13. Set the value of an item’s field as the value of another item’s field;
14. Set the value of an item’s field as the ID of another item;
15. Set a workflow state.

I still have some useful actions left to do in my backlog, which will expand even more the value of this module.

Real life experience: existent actions

Then it finally happened: the next “monkey-job” were lurking at the clouds, being parachuted on me without a notice. One of our projects came with this demand: a “news article” template had some of its look and feel updated, and it imposed the need to replace some content of a Richtext field in all items (there were around 200 items at the repository). We had to replace all entries of class=”old-style” to our new class=”new-stype”.

My rule was then composed by:

• Conditions
  • Where template=’News Article’
• Actions
  • Replace a string in a field of the item
    • Replace class=”old-style”
    • By class=”new-style”
    • At field “Body”

Real life experience: a custom action

The above covered part of our needs, unfortunately some replacements were not that straight-forward. For instance, some of the markup had to be replaced by different tags. In our case, some tables inserted by the client had to be replaced by better formed <figure> tags.

This demanded the creation of a custom action, which would parse the HTML and apply replacement logic at its Document Object Model, then save it back to the item. To learn how to create a custom action, please check this article from John West.

My rule ended up very similar to the previous:

• Conditions
  • Where template=’News Article’
• Actions
  • My custom action for DOM replacements

Please fell free to download and test the module (available on the Sitecore Marketplace at this link), and expand it as you need. Also please let me know if you have questions or any feedback!

1. You can easily lose track on your customizations;
2. Upgrading Sitecore for a newer version may become harder;
3. During development you may be forced to turn your LDAP module off, basically undoing the setup of your providers, which is not straight-forward.

After facing these issues a couple times I decided to look for a better approach.

Using Includes

Biggest limitation is by far the need to update your Web.config, as the changes are not in the Sitecore portion and thus cannot be automatically patched by files in your /App_Config/Include folder. Best you can do is to create patches with the configurations, then include them at the Web.config.

Step by step

1. Add the LDAP connection settings to your ConnectionStrings.config:
   

   <add name=”ManagersConnString” connectionString=”LDAP://yourldapserver.com:389/DC=your,DC=domain” />

2. At your Web.config, find your <system.web> section and comment out your <membership>, <roleManager> and <profile> nodes – these will be all replaced by includes;
3. At the same level you commented out, add a <machineKey> node as covered at the official documentation:
   

     <machineKey validationKey=”BDDFE367CD36AAA81E195761BEFB073839549FF7B8E34E42C0DEA4600851B0065856B211719ADEFC76F3F3A556BC61A5FC8C9F28F958CB1D3BD8EF9518143DB6″ decryptionKey=”0DAC68D020B8193DF0FCEE1BAF7A07B4B0D40DCD3E5BA90D” validation=”SHA1″ />

4. Still at this level let’s add three includes for Membership, RoleManager and Profile providers:
   

   <!– Includes –>
   <membership configSource=”App_Config\AD\Membership.config” />
   <roleManager configSource=”App_Config\AD\RoleManager.config” />
   <profile configSource=”App_Config\AD\Profile.config” />

5. As well as the three includes for disabling the module. We let it commented for now, which makes the module enabled:
   

   <!–
   <membership configSource=”App_Config\AD\Membership_Disabled.config” />
   <roleManager configSource=”App_Config\AD\RoleManager_Disabled.config” />
   <profile configSource=”App_Config\AD\Profile_Disabled.config” />
   –>

6. You have also to add your mapped domain(s) to App_Config\Security\Domains.config:
   

   <domain name=”ad” ensureAnonymousUser=”false”/>

7. Now create a folder called “AD” at App_Config and drop the six config files that are zipped at this link:
   – AD-configs – Don’t forget to review all files (except the “_Disabled.config” that stores the native Sitecore configurations) to make sure you username, password and domains are corretly set!

Now when you want to turn the module off you just have to comment out the lines from #4 and uncomment #5 – pretty easy.