Apex Code Development You need to sign in to do that
Don't have an account?
HarryB Help with new "edit locking" feature and outbound messages needed!
Hi,
there seems to be a new feature in SF7 that should (imho) prevent data loss, if two users edit the same record at the same time and then save their changes one after another. Example:
User A hits "Edit" on a contact, starts to change some details and then gets a phone call.
At this time user B edits the same contact, does his own modifications and saves them.
User A finishes his call and hits "Save" too - he'll get a message page to inform him, that he can not save his changes - he has to reload the record instead, gets the data modified by User B and has to redo his changes.
Nice feature so far.
Now lets assume that there is a workflow and an outbout message connected to all Contact modifications, which execute a script that does some calculation with various Contact data and then updates another Contact field with the result. This whole procedure will take some seconds for the message to fire and the script to run. Over that every outgoing message uses a fixed user that has to be defined on message setup (so not the actual user that fired the workflow and message in the first place!).
Another example:
User A edits a contact and saves it. Now the workflow is triggered, the script takes some time to finish. Before its even done, User A decides to edit the same contact again, during which the script ends and updates the contact in the background. Now User A hits "Save" and gets the message "Congratulations, your changes are lost" ;-)
This is no made up scenario - in fact it happens a lot on a customer, which had no problems up to the release of SF7.
Now the golden question - is there any way to get around this dilemma?
Can one disable this great new "edit locking" feature somewhere?
Can certain users be excluded of this locking mechanism - meaning their changes won't trigger it?
Is there a way to get/use the ID/SessionID of the user that triggered a workflow/outbout message in a script called by the message?
Any help really appreciated!
Cheers,
Harry
Believe it or not, I am thrilled by your questions - and even more thrilled that we have excellent answers.
Let's take the second scenario first. We thought about this exact situation in designing the feature, although more in terms of a user clicking the Back button on the browser. Because of this, we do not check for changes when the changes were made by the same user, so you would not get an error in this situation.
To understand the first situation, you have to realize the difference between a user and a workflow (or an API operation, for that matter). The workflow you describe would do its work of calculation, and then make an update to the record. The only situation that could result in a 'lost update' would be if someone else changed the record between the beginning of the update and the end - which is impossible, since the data is locked for the (brief) duration of the update. Remember, the workflow does not enter Edit mode.
In this same way, changes made by an API call could not result in the API caller getting this error.
I will be writing up a page on the ADN wiki on this topic within the next few days.
Hope this helps.
- Rick Greenwald
Developer Evangelist
Message Edited by RickyG on 08-16-2007 10:06 AM
Ricky,
thanks for your answers, but I don't see any solution so far. The problem - again - is that workflow generated outbound messages keep users from saving their changes - and this isn't acceptable. The fields which the outbound message script modifies are not visible and completely separated to those visible/changeable for normal users - so IMHO locking the whole record for either side is definately not the right way. There should be optional exceptions at least.
Over that its not acceptable that a new SF version has such a huge impact on existing and approved infrastructures and solutions. For the mentioned customer there was no chance of working anymore, because various users kept getting messages "Your changes could not be saved" (because some workflow/ outbound message has modified the record in the meantime). We had to disable some workflows to enable the users to continue to work. And this isn't the way it should go - or put differently, it was working fine up to SF7.
Cheers,
Harald
Message Edited by Whyser on 04-09-2008 09:43 AM
Whyser,
we simply avoided the "infinite loop" scenario by checking if the new (calculated) values are different to the old (existing) ones. If not, the script (executed by the workflow) simply exits without changing anything and the loop ends.
But the core problem (apart from the record locking "feature") seems to be that you can only assign one specific and fixed user/userid to be passed to the outgoing call. So all outgoung calls triggered by one workflow are using the same userid to execute all its API calls. So everytime a (real) user changes a record, the workflow will use another userid to make its changes leading to the dilemma described above. A real solution would be, if you could set your workflows to use (and pass to the external script) the userid of the user that made the changes to the record and thus triggered the workflow.
Cheers,
Harry