Developing some service or workflow to handle some periodic tasks is natural to CRM solutions. Last week, I have been looking for the best way to handle periodic tasks like sending reminders, creating tasks based on date/time, birthday notifies etc.
So I have an entity project schedule and I have thousands of records of this entity where I have to send email reminders. For each record I can have a waiting workflow. So I can have thousands of waiting workflows. While, I can develop a windows service that runs overnight and process records according to criteria and send reminders.
What about performance constraints for hundreds of waiting workflows VS one windows service instance running overnight?
So here are some merits and demerits for both techniques:
1. Workflows can be configurable with no code but we 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 fired on the event matching time condition.
3. Any change in the logic can be rolled out with ease in case of windows service during off peak time while waiting workflow remain in waiting as per old logic. So it creates a big issue in case of maintenance.
4. If number of records is high then creating waiting workflows cause a strain on the system and degrade performance as compared to windows service.
5. If there is frequent update operation on the waiting workflow entity then every time a change occur workflow becomes active and then in waiting state. This can cause a strain to the live system.
Although waiting workflows will not consume any CPU or memory resources but overhead of handling change and strain on system during peak hours make them a less favorite as compared to windows service. Personally I feel much control and maintainability in windows service as compared to workflows.
Filed under: CRM Deployement, CRM Development, MSCRM General | Tagged: Timed Workflow Windows Service Dynamic CRM Microsoft CRM | 10 Comments »




