In the previous post I described the Asynchronous Batch Process Pattern concept and the problem type it can solve. In this post, I would like to suggest a possible implementation which adheres to the Asynchronous Batch Process Pattern principals. In the next post I’ll demonstrate an actual implementation using a sample business scenario.
There are many possible ways to implement the Asynchronous Batch Process Pattern. The main consideration in the suggested implementation is Online support and MSCRM2011 Solution support.
Scheduling Component – Workflow Rule
One scheduling mechanism available for all deployment types, is the Workflow engine which has a Wait action available. The Workflow’s Wait action allows a process to wait for business events and future due dates and therefore suitable as a configurable Scheduling Component.
The Scheduling Workflow Rule will operate on the Batch Process record and Wait for the Next Activation Schedule. When the due date arrives, the Scheduling Workflow Rule will change the Batch Process record status to ‘Activated’, which in turn launches the Executing Plugin registered for the Batch Process entity Update event (the Status attribute update only).
Query Definition – FetchXML Query
Microsoft Dynamics CRM FetchXML is a proprietary query language used to describe complex queries and retrieve a collection of matching records. FetchXML is also used by the Advanced Find engine and In version 2011, the Advanced Find screen allows downloading the FetchXML query definition for any existing and custom query. This makes the FetchXML ideal for defining queries that are valid in both Advanced Find and the API Organization Service.
For this implementation, the Advanced Find will be used to define the target records, test the query and download the query definition for later usage. The FetchXML query string will be set in the Batch Process record and used by the Executing Plugin to retrieve the IDs of the target business records.
The FetchXML main advantage is being dynamic: it returns current matching business records rather than records that matched in the past but not anymore, which may be the case when implementing the recursive Workflow rule approach.
Executing Component – Plugin & Workflow Rule
Both Plugins and Workflow Rules are executing mechanisms in Microsoft Dynamics CRM, each with its own strengths and weaknesses.
In Online deployments, Plugin is currently the only Solution contained component that enables embedding custom server side code into the application processes. A Plugin is not limited to the predefined Workflow actions and can perform actions like Share, which a native Workflow Rule can not.
A Plugin can also perform queries and activate a Workflow Rule via code. This is a key capability in the current implementation. After the Executing Plugin has retrieved the target business records, it will apply the Action Workflow Rule to these records, and set the Batch Process record according to the recurrence frequency.
Batch Process Entity
A custom Batch Process entity will be used to initiate and manage the Batch Process data:
- Next Activation Schedule
- Workflow process to run
- FetchXML query
- Activation frequency (one-time, daily, weekly etc.)
- Success/failure notification
The following diagram describes the execution algorithm. The key concept used here, is the communication of the Scheduling Workflow and the Executing Plugin component over two data attributes of the Batch Process record:
- Batch Process Status – when ever Batch Process record status changes to ‘Activated’ by the Scheduling Workflow Rule, the Plugin component executes, query for business records using the FetchXML query and apply the predefined Action Workflow Rule to the result records. The Plugin than changes the Batch Process record status back to ‘Scheduled’ or ‘Suspended’.
- Next Activation Schedule – If the Batch Process record defines a recurring schedule (daily, weekly etc.), the Plugin component sets the Next Activation Date respectively. This trigger initiates another Scheduling Workflow Rule instance which waits to the new Activation Date