locked
CRM2011: Waits and Timeouts in Workflows - How efficient are they? RRS feed

  • Question

  •   

    Workflows are one of those features in CRM which really makes the application come alive. It’s always great to show a workflow in process to a potential new client. I’ve been playing with workflows for some time, but there is one element of a workflow that perplexes me. Perhaps it’s because I’m an application developer and I think I can do the job more efficiently, rather than trusting the system.

    Reactive and On-Demand workflows  I totally get (and love), but just how efficient are Waits and Timeouts in CRM?  

    Suppose I had a Recursive Timeout workflow that waited 7 days and then checked the account balance to see if it was over a certain value.

    If it wasn’t it would call itself again waiting another 7 days. But if it was, it sends an email reminder to the Finance department and then calls itself again waiting another 7 days.

    Doesn’t sound too bad does it? (and yes I know I could of done reactive workflow on the balance update, this is to illustrate the issue as simply as I can)!

    But what if I have 100,000 customers in my CRM database. That’s 100,000 workflows running and waiting. What issues does this cause for the general operation of CRM.

    As a developer I could create 1 job that checked 100,000 conditions in a one-off hit once a week, but a CRM only solution that would require 100,000 jobs checking just 1 condition.

    Does it matter? Am I worrying about nothing in my drive to make CRM as efficient as possible and I should trust it to do the job.

    Any comments or suggests gratefully received.

    Steve

    Tuesday, February 28, 2012 4:16 PM

Answers

  • Hi Lemonje,

    CRM2011 workflow is built using Workflow Foundation (http://msdn.microsoft.com/en-us/netframework/aa663328) and so generally performance is quite good

    When a workflow hits a wait condition, it is serialised to a database record and so is no longer in memory. The Wait conditions fall into two categories:

    • Event Based Waits - where a workflow subscribes to an attribute change event on a record
    • Time Based Waits - where a workflow is suspended until a specific date.

    Whenever either of these two events are true, the workflow is 're-hyrdated' from it's serialised data and then execution continues. The Async Service is very good at managing it's work load based on how many AsyncOperations it has in the queue.

    In your example, the issue is not really how many workflows you have waiting (since these are just records in the database) - but more about how many workflows you are going to have being re-hydrated and running at the same time. So if you had a specific hour on a specific day that 100,000 workflows were waiting for, then this could potentially cause you problems in that it would take quite some time for the Async Service to get through this backlog.

    Obviously if you were building an application from the ground up for a specific purposes you'll always get performance gains, however at the price of considerably more total cost of ownership.

    hth,

    Scott


    Scott Durow
    Read my blog: www.develop1.net/public
    If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"

    • Proposed as answer by D kay Thursday, March 8, 2012 10:38 AM
    • Marked as answer by lemonje Thursday, March 8, 2012 11:20 AM
    Thursday, March 1, 2012 9:44 PM
    Answerer

All replies

  • Hi Lemonje,

    CRM2011 workflow is built using Workflow Foundation (http://msdn.microsoft.com/en-us/netframework/aa663328) and so generally performance is quite good

    When a workflow hits a wait condition, it is serialised to a database record and so is no longer in memory. The Wait conditions fall into two categories:

    • Event Based Waits - where a workflow subscribes to an attribute change event on a record
    • Time Based Waits - where a workflow is suspended until a specific date.

    Whenever either of these two events are true, the workflow is 're-hyrdated' from it's serialised data and then execution continues. The Async Service is very good at managing it's work load based on how many AsyncOperations it has in the queue.

    In your example, the issue is not really how many workflows you have waiting (since these are just records in the database) - but more about how many workflows you are going to have being re-hydrated and running at the same time. So if you had a specific hour on a specific day that 100,000 workflows were waiting for, then this could potentially cause you problems in that it would take quite some time for the Async Service to get through this backlog.

    Obviously if you were building an application from the ground up for a specific purposes you'll always get performance gains, however at the price of considerably more total cost of ownership.

    hth,

    Scott


    Scott Durow
    Read my blog: www.develop1.net/public
    If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"

    • Proposed as answer by D kay Thursday, March 8, 2012 10:38 AM
    • Marked as answer by lemonje Thursday, March 8, 2012 11:20 AM
    Thursday, March 1, 2012 9:44 PM
    Answerer
  • Many thanks Scott for your post.

    Never really understood the mechanics of the operations, so this helped.

    Thanks

    Thursday, March 8, 2012 10:25 AM
  •  Hi Scott,

     This is a very good explaination ...

    thanks for the post

    cheers

    dkay

    Thursday, March 8, 2012 10:40 AM