Wednesday, May 05, 2010

Managing the MSCRM Asynchronous Service

Workflows are a wonderful thing.  They make it so that power users, non-developers, can get a lot done with Microsoft CRM without having to know a lick of code and can get a lot of business processes built into their company’s application relatively easy.

I have, however, seen some administrators and power users get a little liberal in how they use and implement their workflows without thinking about the repercussions to their system as a whole.  I’ve seen servers where the Asynchronous Service (CRMAsyncService.exe)was using on average 90-95% of the CPU constantly. 

1

Any guess as to the cause?  Workflows.  But not just any workflows, workflows with WAIT’s in them.  Workflows that fire from their given trigger, run their course and then complete are great and just fine.  They don’t take up much memory or CPU usage because they run for such a short time.  It’s the WAIT states that eat up all your memory and CPU usage on your server.

WAIT states have their place and sometimes cannot be avoided.  But a system administrator should look to have as few WAIT’s as possible in his/her system.

Here are some good alternatives for WAIT’s:

1. Use the UPDATE trigger on another workflow to check for a given attribute and condition and fire the WAIT logic when that criteria is met.

2. Don’t wait to create activities, create them immediately and just set the dates on the activity accordingly.  If you are waiting X number of days to send an email as a follow up, you could just create the email and have it sit in a users “To Do” list and when that user looks at his/her list for the day, would see that the email needs to be sent out.  Otherwise, you could even create the emails and write a nightly process (or use a third party tool) to check the system for emails that haven’t been sent and have the tool send them after hours.

3. Change to batch processes.  Using a custom tool or third party product, have the tool check the system at intervals to escalate incidents (cases), send emails, remind users about opportunities or past due activities, etc.  Sure it’s a little extra work but if you have a lot of things that need to be waited on, then it’ll be worth the effort.

Protect yourself, your server and your company from WAIT’s in workflows by just avoiding them.  Keep your eye on that Asynchronous Process!

David Fronk
Dynamic Methods Inc.