In this and the following two posts, I would like to suggest a solution to a common business problem of executing business logic operation in a scheduled reoccurring manner.
While the current post describes the business problem and a solution concept, the next posts will suggest an actual implementation, based on the Asynchronous Batch Process Pattern described here.
I am often asked by customers about implementing business logic operations in a scheduled reoccurring manner. Here are some of the business requirements I have encountered:
- Check the due date for all open Cases once a day and set ‘Exceeding SLA’ indication if due date has passed
- Send monthly news letter automatically to target customers
- Update MSCRM Users details from Active Directory once a day
- Once a month, disqualify all leads that has no open activities
These requirements have some common characteristics: scheduled, repeating, asynchronous activation of a business logic for a selected collection of business records.
There are some standard solutions in Microsoft Dynamics CRM for such business requirements and the common two are described in the following table:
|1.||Custom .NET code executing a query to retrieve target business records and implementing business logic.
Scheduled and activated by Windows Service or Windows Task Scheduler
|2.||Recursive Workflow rule activated for each target business record.
Business logic executed by native Workflow Step or Custom Activity .NET code
The main disadvantage in both common solutions, is the lack of support in Online deployments. This usually means that part of the solution is implemented in a different hosting environment such as Azure of On premise.
The Asynchronous Batch Process Pattern
The Asynchronous Batch Process Pattern is based on three basic elements:
- Schedule: managed by a Scheduling component, able to invoke an Action in a predefined date and time
- Action: a business logic operation performed of a collection of business records by the Executing component
- Target business records: A collection of business records defined by a Query Definition
The Action is applied to the target business records on a specified schedule
While this looks like a simplistic and trivial concept, the pattern defines the weakest coupling possible between the three components. The Scheduling Component is oblivious to the Action it invokes, and the Action delegate is unaware to Target Business Records population it acts upon.
This pattern allows a robust yet flexible solutions to the aforementioned business problem.
Suggested Implementation Features
In the following posts, I will describe a possible Implementation based on the Asynchronous Batch Process Pattern.
I will consider this Implementation preferred over the two solution mentioned above if it will support the following main features:
- Supported in Online, IFD and On-Premise deployments
- Does not require Azure/On premise hosting environment
- Can be contained in a MSCRM2011 Solution
- Highly configurable – does not require code compilation
- Fully supported