Situations may occur where multiple users are working on the same record, at the same time, and the one who saves the record last overwrites the changes made by another user. For example, User A opens a particular account record. Meanwhile User B opens up the same account record and saves it after making some changes. If User A also modifies the record and saves it, he would now overwrite the changes made by User B. To prevent this concurrency situation from occurring, our recommended solution is to implement a record locking mechanism.
Selecting the appropriate locking approach (Pessimistic vs. Optimistic)
Pessimistic locking requires the record being currently accessed by a user to be locked for exclusive use until the user is done with the record. This is not an ideal choice as we do not want to deny access to that record by other users during that time. Also, maintaining database locks is extremely expensive and has a high risk of producing deadlocks. Most importantly, a CRM application is a stateless environment and pessimistic locking requires sessions to remain open. We can mimic sessions being preserved through the use of session variables and event handling but this would not be a “clean” approach.
Optimistic locking does not require exclusive locks and permits simultaneous access to each record, but informs the user if the record has been altered by another user after he had accessed it. This approach requires a higher number of database queries, but we are working under the assumption that conflicting updates would be infrequent and thus a very low penalty is anticipated. As such, Optimistic locking is our selected for a solution.
Implementing Optimistic Locking in CRM 2011
In order to implement this approach, the system needs to track and maintain a versioning/time stamp based mechanism, It must use that mechanism to determine if a particular record has been altered by a user after being accessed by another user. There are multiple ways one can design the versioning mechanism, but in this example we chose to use existing “out of the box” fields in Dynamics CRM - namely “ModifiedOn” and “ModifiedBy” to implement a simple yet effective solution for optimistic locking.
We have added custom code to the “OnLoad” and “OnSave” events on the form for the entity. When a user opens up a form/record the system retrieves the values from the “ModifiedOn” and “ModifiedBy” fields for the record. Later when the user tries to save the record the system again retrieves the values for these fields. If the values for these fields retrieved earlier are found to be different from those retrieved later, it would indicate that the record has been recently modified by another user.
In this situation, the current user would be prompted to either continue or close out the form and restart. If the user decides to continue, he will overwrite the changes made by the other user to the common fields modified by both. Since the default behavior of any CRM form is to only send back and save the modified values, the override will occur only for the fields they both had modified.
Limitations/Further Enhancements:
This solution does not warn one user that another user is modifying it while on the form. The user is only warned about the possible conflict when trying to save the record. This could be frustrating for the user but we did not want to store state by using custom applications or creating additional records in the system.
An alternative approach is to periodically poll the modified date during form editing and let the user know during the edit that someone else just modified the record. There will be a minor performance cost while it queries CRM behind the scenes at a predetermined interval using Ajax, but this might be worth the enhanced user experience in your situation.
For the purpose of this demonstration we are using an entity called “Sales Order” .
1. Create a web resource of type script and add the following code to it.
> See Code Snippet PDF <
2. Include this web resource library on the “Sales Order” form properties.
3. On the “OnLoad” event for the form register the function “getPreviousModificationDate.”
4. On the “OnSave” event for the form register the function “validateConcurrency.”
5. Have a user (Robert Duke in this example) open up a Sales Order record.
6. Then have another user (John Smith in this example) open up the same record and modify and save it.
7. Now have Robert Duke modify the record and click on the “Save” button. He will receive a warning about the possible overwrite of data.
Note: In the web resource code the value of the “aSync” parameter passed to the retrieveRecord method is extremely crucial. Rest calls using Ajax are asynchronous by default. But in this scenario we require a synchronous call as the system needs to wait for the result before proceeding with the “Save” event. So we pass the value “false” for this parameter thus forcing it to ne a synchronous call.
Filed under: Microsoft Dynamics CRM 2011, Microsoft Dynamics CRM Best Practices, Microsoft Dynamics CRM Customizations, Microsoft Dynamics CRM Tips & Tricks | Leave a Comment »
