Tag Archives: Database

SQL Provider (SaveToDatabase Action) for Web Forms For Marketers (WFFM 2.5 – Sitecore 7.5)

With the release for WFFM 2.5 for Sitecore 7.5; SQL server is no longer supported (see release notes) as each time a form is submitted it automatically saves the form data in the xDB (MongoDB) and associates it with the current contact (used to be called visitor).

I believe MongoDB is a much better choice than SQL for storing non-structured data that is generated by WFFM and in addition it can also be used to tailor the experience to the current contact (visitor) i.e. don’t show them the form if they have already filled it out, etc.

Problem

Unfortunately I have a number of customers that want to upgrade to Sitecore 7.5, but due to a number of business and operational reasons are not ready to migrate MongoDB. Therefore they wish to continue storing their form data in the existing SQL database.

Solution

I decided to create a simple SQL provider for WFFM 2.5, that would allow customers to continue saving/retrieving data frm the existing SQL database.

The shared source module WEB FORMS FOR MARKETERS 2.5 – SQL PROVIDER (SAVETODATABASE) is available at Sitecore’s marketplace and the source code is available at GitHub.

This initial version is very simple and provides the following functionality:

  • Save data to a WFFM SQL database (SaveToDatabase Action).
  • Retrieve all submitted data for a given form.
  • Download the data as a CSV file (see separate blog post)
  • Specify a date range to be exported (see article)
  • Define the CSV Delimiter (see article)

It was my intention to port the forms report viewer from a previous version, but the architecture has changed considerably to accommodate xDB and it would have required me to re-code and override a lot of classes. In addition there were a number of UI control libraries that the forms report viewer relies upon which are no longer used/bundled with Sitecore 7.5.

Therefore I intended to implement the ability to down load the data for a given form as an CSV file. So the data can be analysed and sorted using Excel, which in my experience is how the majority of customers used WFFM data.

Installation

Install the WFFM.SQLServer.SaveToDatabase-1.4.zip package, note you prompted that the Save to database item already exists, select overwrite and aply, see below

overwrite

Ensure the WFM.ConnectionString settingin /app_config/include/Sitecore.Forms.config is set to the name of the connection string for the WFFM SQL database i.e.

<setting name="WFM.ConnectionString" value="wfm" />

where the “wfm” connection is defined as follows:

<add name="wfm" connectionString="user id=[USER ID];password=[password];Data Source=[Server];Database=[WFM DATABASE];Connect Timeout=30" />

How To Save Data

Like previous version of WFFM you use the “Save To Database” action to save the submitted form data to the SQL database. The SaveToDatabase action is still /sitecore/system/Modules/Web Forms for Marketers/Settings/Actions/Save Actions/Save to Database. In fact it is the same item from previous versions, so all existing forms that use the SaveToDatabase action will continue to work without making any changes.

save to database item

The only change is that class is WFFM.SQLServer.SaveToDatabase.Infrastructure.Actions.SaveToDatabase, from the WFFM.SQLServer.SaveToDatabase assembly.

Retrieve data for a given Form

To Insert new form data and retrieve data there is a FormReposiotry class which has a Get function to retrieve a list of form data for a given form id, seee below

public IEnumerable<IForm> Get(ID formId)

I have added a button to download data as CSV see this article.

And it is now possible to specify a date range to export and the delimiter used to separate the columns in the CSV file (see article)

Links

marketplace.sitecore.net/Modules/Web_Forms_for_Marketers_SQL_SaveToDatabase.aspx

github.com/TakeitEasyAlan/WFFM-SQL-Server-SaveToDatabase

How to kill Sitecore with a Database connection

Well it’s been a while since my last blog due to the summer holidays and the fact that we have been very busy at Pentia.

Anyway here is my next installment in my “How to kill Sitecore” trilogy.

We recently took over a website that was having a lot of performance issues, and when I looked in the log files I noticed that the database connections were timing out.

So initially investigated if there was an issue with the SQL server, but after profiling and monitoring the database it appeared to have no performance issues, but I noticed that some of the exceptions were coming from the Heartbeat task.

What I believe the heartbeat tasks does among other things is to establish a connection for all the connections defined in the connections section, so that when the first request comes in the database connection is ready to retrieve the data from the SQL server.

The solution had a lot of include files some of which defined connections to databases that no longer existed.

So what happens when you have 4 connection strings that contain a reference to a databases that does not exists, well the hearth beat runs every minute and therefore creates 4 new connections every minute.

The connections were setup to timeout after 20 minutes which meant that after 20 minutes the heartbeat task had created and was waiting for 80 connections.

The problem is that the default max number of connections is 100, which left only 20 connections for the actually data providers that were configured correctly and when the site was busy this was not enough so they started to timeout,  which in turn caused the site to run very slowly 😦

To be honest it would of helped and been a lot quicker to find this error if .NET cast an CONNECTION POOL HAS REACHED IT MAX!!

But once this issue was found and I removed the unused connections, the site ran a LOT faster.

How to kill Sitecore whilst getting the languages for an item

I was reviewing a solution (not developed by Pentia) for a customer as they were concerned about the performance and stability of their site.

It didn’t take me long to find the following bit of code which calls the SQL server to find the languages for a given item:

languages

I was shocked that anyone would not use the Languages property on the Item class, which would have replaced the entire function.

I think in all my years of Sitecore development this is the worst bit of code I have ever seen, it shows  a complete lack of respect for the API and if  the site was upgraded it is possible that the database schema could change and therefore the code would break!

On average the SQL query took 400mS (which is quite slow, but then again the SQL server was getting hit by 4 front end servers for every request).

The same call to the Item.languages took 0.1mS, this simple change made every request 400mS quicker and reduced the load on the SQL server considerably.