Developing some service or workflow to handle some periodic tasks is a common task when creating a CRM solution. Last week, I was looking for the best way to handle periodic tasks such as sending reminders when creating tasks based on date/time, birthday notification and the like.
For example, I have an entity project schedule with thousands of records of this entity. For each of these I want to send email reminders. For each record I can have a waiting workflow which results in thousands of waiting workflows. Or, I can develop a Windows service that runs overnight and process records according to my criteria which includes sending reminders.
What about performance considerations for hundreds of waiting workflows versus one windows service instance running overnight? Here are some merits and demerits for both techniques:
1. Workflows are configurable with no code but we would need to create a configuration mechanism for Windows service and scheduled tasks.
2. We can control the best time to execute a Windows service while workflows are fired on the event matching time condition.
3. Any change in the logic can be rolled out with ease using Windows service during off peak time while waiting workflow remain in waiting as per old logic. So using workflows can create a sizable maintenance problem.
4. If the number of records are high then creating waiting workflows may cause a strain on the system and degrade performance when compared to Windows service.
5. If there is frequent update operation on the waiting workflow entity then every time a change occurs workflow becomes active and moves to a waiting state. This can cause a strain to your system.
Although waiting workflows will not consume any CPU or memory resources, the overhead of handling change and strain on system during peak hours make them less favorable when compared to using a Windows service. Personally I feel the control and maintainability of a Windows service is better than workflows, especially when you take all of this into consideration.