We have brought up synchronous and asynchronous processing multiple times throughout previous posts thus far related to Custom Workflow Assemblies and Plug-ins in Microsoft Dynamics CRM 4.0. The next section will cover in more detail the business and technical impacts of both types of event registration within the Execution Pipeline.
Execution Pipeline Synchronous vs. Asynchronous Overview
The Microsoft Dynamics CRM 4.0 Execution Pipeline allows for synchronous and asynchronous event processing. Synchronous events execute one at a time, either before or after CRM Platform Core Operations (Create, Delete, Update, etc). Asynchronous events are added to the asynchronous event queue to be executed by the asynchronous process at some point in the near future.
The business impact of using synchronous and asynchronous events is more easily understood with the help of examples. The following two hypothetical examples detail two scenarios where events could be registered synchronously or asynchronously to satisfy a business requirement. While the scenarios will function with either registration method, there are advantages and disadvantages to the method as described below.
Example 1: Account to Contact Cascading Addresses
CRM users have requested an extension to Microsoft Dynamics CRM 4.0 that would update the addresses for all sub-contacts for an account when the account’s address changes. You write code to check if the address has changed on save of an account. If so, you retrieve the sub-contact records and iterate through the records to update each contact’s address. You now must decide if you should register the code synchronously or asynchronously.
If you register the event to run synchronously, users will have to wait for all of the sub-contacts to be retrieved, edited, and saved before form control is returned to the user after clicking save. The up side to this approach is that the user could be sure that once the full save event finishes, all sub-contacts would immediately reflect the address change. The down side is that user experience could become extremely sluggish when working with large accounts with many sub-contacts or when bulk-editing multiple accounts.
If you instead register the event asynchronously, the sub-contacts will be processed in the background (with a slight delay) without affecting user experience. The one downside occurs in the corner case when a user saves an address change for an account and then quickly opens a sub-contact record to see if the address was updated. There might be some user confusion if the asynchronous process had not yet updated the contact record. Since this is a rare corner case and it can be avoided through training, registering asynchronously is the clear choice to avoid performance issues.
Example 2: Custom Case Number Generation with Immediate Feedback
CRM customer service users track customer support information using the case entity in CRM. When a new case is created, an email is sent to the customer providing them their case number. The business has decided not to use the out-of-box CRM case number functionality, since they require an abbreviation of the case subject to appear in the case number in order to more easily categorize cases by topic outside of CRM.
When a user is in the process of creating a new case, they first ask the customer the nature of the call and choose a case subject. You write code that executes on save to generate a new case number and include an abbreviation of the subject appended to the number. You then create a workflow to send an email to the customer using an email template that retrieves the newly-generated case number.
At the end of a service call, customer server representatives would also like to verbally communicate the case number to the customer. If you register the .NET assembly asynchronously, service users would have to do an initial save on the case and then continuously refresh the case form until the asynchronous process gets around to updating the case with the case number. Synchronous registrations allows for the field to be updated on the case form as soon as the save event completes, allowing the representative to quickly provide a case number to the customer. Synchronous Plug-in registration is the clear choice in this case.
Conclusion
These two examples have quickly highlighted some the advantages and disadvantages of using asynchronously or synchronously processing of you custom business logic. When deciding which route to take you need to understand how each will impact the user. Will waiting for a response interrupt the process flow within the application or will not having the confirmation or custom logic result interrupt the process flow. With each area of process automation we need to examine the best approach to facilitate the intended business process.
- Phil Edry & Hoss Hostetler