Given that the existing OrganizationServiceContext for a Plugin is performs updates in the current SQL transaction context (assuming pre or post validation event), is there an efficient way to update a separate entity outside this transaction/context?
The goal is to avoid rollback of updates on a different entity (other than the Plugin target entity) when an exception is thrown.
Just create a new IOrganizationService rather than use OrganizationServiceContext.
Check this example.
Related
When executing a CreateRequest using the MS CRM OrganizationService, it seems that any attribute of type 'EntityReference' is checked by the internal CRM pipeline using a SQL query against the respective base table looking for the key specified in the EntityReference object. It's basically a foreign key check substitute since CRM doesn't define actual foreign keys when you relate entities.
I'm trying to import some data into the system where I know the specified EntityReference's already exist since I just retrieved them (race conditions aside). Is there any way to bypass that internal check from happening when using the web services? I'd like to avoid having to do any direct SQL updates since it invalidates the auditbase and modifiedby information.
For example, inserting 100,000 entity instances which each have 5 entity reference attributes on them turns into 500,000 selects being issued, often for the same value. Please tell me there is a supported way around this?
No. The only supported way to create records inside Dynamics CRM is to use the API.
I have 2 plugins registered on the same pipeline stage (post operation) and triggers on the same entity Entity A (create event).
When plugin 1 triggers on Entity A (create event) and make changes to Entity B and another plugin 2 triggers on Entity A (create event) and while making changes to Entity A an exception was thrown.
Does the changes that plugin 1 made on Entity B get rolled back since both plugins triggers on the same entity and they have the same pipeline stage OR the changes plugin 1 made to Entity B remain and will not be rolled back?
Depends on the plugin transaction.
Event execution pipeline
Plug-ins may or may not execute within the database transaction of the
Microsoft Dynamics CRM platform. Whether a plug-in is part of the
transaction is dependent on how the message request is processed by
the pipeline. You can check if the plug-in is executing in-transaction
by reading the IsInTransaction property inherited by
IPluginExecutionContext that is passed to the plug-in. If a plug-in is
executing in the database transaction and allows an exception to be
passed back to the platform, the entire transaction will be rolled
back. Stages (pre-operation) 20 and (post-operation) 40 are guaranteed to be part of the database
transaction while stage 10 may be part of the transaction.
Any registered plug-in that executes during the database transaction
and that passes an exception back to the platform cancels the core
operation. This results in a rollback of the core operation. In
addition, any pre-event or post event registered plug-ins that have
not yet executed and any workflow that is triggered by the same event
that the plug-in was registered for will not execute.
In your case if the plugins are chained together, and the second one is synchronous the exception from plugin 2 will bubble up to plugin 1. If both plugins are inside a transaction the actions from both plugins are rolled back.
I have a plugin that needs to create a bunch of entities, and does so using;
service.Create(Entity);
At the end of the plugin (pre-operation on Update, synchronous) I sometimes need to cancel the save operation. The only way I know how is to throw an exception, but if I do that my service.Create(Entity) does not get executed.
How do I force the service to execute the operations inside the plugin, and then cancel the save by throwing an exception?
EDIT: The code is;
var id = service.Create(newEntity);
throw new Exception("Cancelled Save but created the new entity");
If I throw the exception, the entity does not get created. If I do not throw the exception, the entity does create. I need it to create and also throw the exception so that the save operation is cancelled.
Thanks for any pointers.
Nicknow's answer is correct, but there are still a few ways to accomplish what you want to do.
In your plugin, don't use the OrganizationService from the plugin context. Create your own new OrganizationService just like you would if you were creating a console app. This new OrganizationService won't be subject to the transaction scope of the original OrganizationService.
Create a web service that does the work. From your plugin, call this web service. The web service won't be subject to the transaction scope of the original OrganizationService.
Use ExecuteMultiple. I've never tried this but here's somebody who claims it works: http://crmtidbits.blogspot.com/2014/02/bypass-plug-in-transaction-to-log.html
Hope that helps!
If IPluginExecutionContext.IsInTransaction == true then when an Exception is thrown anything that has been written to the database will be rolled back. You can try registering in the Pre-Validation stage and sometimes that is outside the transaction, but not always.
Just be aware that there is no guarantee it'll always be outside of the transaction. The SDK documents make this very clear - so at anytime an update could occur that puts it in a transaction.
https://msdn.microsoft.com/en-us/library/gg327941.aspx#bkmk_DatabaseTransactions:
Plug-ins may or may not execute within the database transaction of the
Microsoft Dynamics CRM platform. Whether a plug-in is part of the
transaction is dependent on how the message request is processed by
the pipeline. You can check if the plug-in is executing in-transaction
by reading the IsInTransaction property inherited by
IPluginExecutionContext that is passed to the plug-in. If a plug-in is
executing in the database transaction and allows an exception to be
passed back to the platform, the entire transaction will be rolled
back. Stages 20 and 40 are guaranteed to be part of the database
transaction while stage 10 may be part of the transaction.
Any registered plug-in that executes during the database transaction
and that passes an exception back to the platform cancels the core
operation. This results in a rollback of the core operation. In
addition, any pre-event or post event registered plug-ins that have
not yet executed and any workflow that is triggered by the same event
that the plug-in was registered for will not execute.
I remembered that it's can be done using the SDK and the API, for example:
I wanted to create Task and with the same request (using the same Proxy and Context objects) create a new Contact entity and link in to the Task (RegardingObjectId) – All in one execute / request message to the CRM and of cures with full support of transaction
10X
Itzik
If you want it all to be wrapped into a single transaction, you'll have to use a plugin registered either before or after Create, just not in the validation stage. Then if any action fails, it'll all be rolled back.
I have a question regarding the rollback mechanism in CRM 2011. I know that a synchronous plugin will rollback any changes it has performed if an error is thrown. But what if this plugin triggers another plugin during it's execution.
Consider the following plugins:
Plugin A: Triggers on pre-UPDATE of Task entity
Plugin B: Triggers on pre-UPDATE of Case(incident) entity
Scenario would be like this:
I update a case and Plugin B get's triggered.
Fields in the case are modified
One of the Tasks associated with the case is also updated with some information.
Plugin A is triggered
Fields related to the task are modified
Some other operations on the case record
Plugin B throws exception
My question is, would the operations performed in Plugin A get rolled back as well?
As long as the plugins are registered in the transaction (before or after, but still in), everything will get rolled back. If a plugin is registered for the Pre-Validation stage, it will not get rolled back.
This also assumes that you're retrieving the IOrganziationService from the PluginContext as well.
This is what happens on the server:
A request to update an entity comes in, are we currently in a transaction via the context? If not create a new Database Transaction and store it in the Plugin Context.
Request is made to update a different entity, transaction is passed to the new plugin's context, and step 1 is repeated for new plugin execution.