We have a post-operation sync plugin which writes events data into a eventhub. However we have some custom functionality which uses ExecuteTransactionrequest to run batch operations.
If the transactions running under ExecuteTransactionrequest fails it rollsback however data written into eventhub can't be rolled back.
Is there a way to control firing of post-operation plugins with this so that they fire after all the operations are completed.
Your options here are somewhat limited, you could try pre-validation.
Pipeline stages
Pre-validation - Stage in the pipeline for plug-ins that are to
execute before the main system operation. Plug-ins registered in this
stage may execute outside the database transaction. The
pre-validation stage occurs prior to security checks being performed
to verify the calling or logged on user has the correct permissions to
perform the intended operation.
Pre-operation - Stage in the pipeline for plug-ins that are to execute
before the main system operation. Plug-ins registered in this stage
are executed within the database transaction.
Post-operation - Stage in the pipeline for plug-ins which are to
execute after the main operation. Plug-ins registered in this stage
are executed within the database transaction.
Inclusion in database transactions
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.
If you are using event hub as some sort of logging, I would advise that you don't, as transaction rollback is likely to wipe out any logs.
You could consider taking your logging outside of CRM. Or, if you have to have it within CRM, then send the data somewhere it can't be rolled back first. For example plugin > external web service > CRM.
You can use an asynchronous plugin. Asynchronous steps are only invoked when the synchronous plugin pipeline has completed without errors.
Related
Problem Statement: Asynchronous Plugins are failing intermittently because entity Records are being updated at very high pace
In Detail Analysis: We have a process where we frequently share/un-share Entity Records with Access Team. Asynchronous plugins executes after create and update. Dynamics CRM is integrated with multiple systems and receives updates in the system. We are facing an issue as these Async Plugins are failing with SQL Error,
Sql error: Generic SQL error. CRM ErrorCode: -2147204784 Sql ErrorCode: -2146232060 Sql Number: 1205
In the Dynamics 365 web application, if user creates/updates a record, plugin executes and succeeded. Issue is if a record is being updated through integrated systems, at that point of time plugins fails. We tried below things as to resolve the issue,
Changed the order of execution of Async Plugins
Optimized the plugin code
These are not helping much, is there any way we can put delays between Plugin executions? Or any other way we can overcome this hurdle?
***Microsoft says update record frequency is too high(0.07 sec difference between 2 record update). Deadlock is being caused due to the execution of internal SP "p_CascadeRevokeAccess".
Sql number 1205 is the key, transaction causing some deadlocks.
Error 1205 : Transaction (Process ID) was deadlocked on resources with another process and has been chosen as the deadlock victim. Rerun the transaction
I would recommend you to take care of few things:
You already mentioned that you did optimize the plugin code, make sure you have "No Lock" in any Query expression or fetchxml query that you are using in plugin code
If you are recursively updating the same entity record in plugin, try using pre-operation of create/update message and update the target attributes in same synchronous transaction instead of too many asynchronous transactions
Not sure how many steps getting triggered in your post-operation plugin, though you have execution order set properly, only the order of flow within the same transaction can be controlled in specific order. But you cannot control the execution order of step 1 of second transaction to run after the step 2 of first transaction of the same entity record update by your upstream systems.
So try to compose your needed flow and do shuffling the code in each plugin step for better handling. Though the CRM platform take care of some optimistic concurrency techniques, you have to take care of your implementation. Otherwise this will become a maintenance nightmare and future enhancements may be impossible.
Also you mentioned about sharing/unsharing using access teams, there is a possibility that this issue could be related to Principal Object Access (POA) table updates. Check with Microsoft with a premier support ticket if needed.
We have a business need where we need to create up to 50,000 records. Using a synchronous plugin or javascript is not acceptable solution here because it takes too long-- SQL timeout will occur. Is it possible? Can we run asynchronous & synchronous plugin on the same PostOperation Create step of that entity?
Of course, yes. You cannot have same step as both sync and Async but You can register two steps, one as synchronous and another one as asynchronous. Make sure you are not doing the same logic in those steps in same plugin.
You can split the logic in two plugins and register the two separate steps carefully wrt what is need in sync mode vs Async mode.
Normally, If you want to Rollup the DB transaction when the logic fails - then synchronous step is needed. If the logic failure is not a show stopper and can silently fail to move forward - then asynchronous is enough (write a plugin trace log entry in try..catch for analysis).
Assembly (.dll) can have two plugins (.cs file), and multiple steps for each plugin is possible. But maintain the clarity for less complexity and maintenance.
I have currently CI system which triggers submit and particular stream and then builds the change and tests it.
However as I said it is done upon submit, meaning the change is merged before the testing.
So my question is how I can trigger the changes in an earlier stage? What is the best approach?
We are not using any IDEs for development.
Thanks!
To do it on the Perforce side, you'd use a change-content trigger, which runs prior to submit while the files are available in a staging area on the server (the in-flight change is treated as a shelf and can be accessed using the #=change syntax). This allows a trigger script to access the content in-flight and reject it before it's finalized.
While a content trigger is running, the files are locked, and the submit will block the client session until it's finalized on the server and can report success, so you'd want to be careful about which codelines you enable something like this on.
I try to update an entity with a plugin. I use Image (pre) and stage Post with asynk... The databse is updated in real time, but not the form. Does anybody know why i have to "upate" two times to se the updated text in the webform and the value is updated in the database immediately? I want to se it "immediately". Thanks
With asynchronous plugin execution, the database is never really updated "in real time"; the asynchronous execution might just happen so quickly that it looks that way to a human's "slow" perception.
On a server process level, however, the code of an asynchronous plugin will run "when there is time", while the code that rebuilds the form and sends it back to the client is running "immediately" and will wait for synchronous plugins, but not for asynchronous ones.
If you want the changes your plugin makes to be reflected in the entity form immediately after the reload, the plugin has to be registered for synchronous execution.
As far as I know, for asynchronous plugins, as well as for workflows, there is no timeframe in which they are guaranteed to run after being triggered.
The workflow is being published as a wcf service, and I need to guarantee that workflows execute sequentially. Is there a way--in code or in the config--to guarantee the runtime doesn't launch two workflows concurrently?
There is no way to configure the runtime to limit the number of workflows in progress.
Consider though that its the responsibility of the workflow itself to control flow. Hence the workflow itself should have means to determine if another instance of itself is currently in progress.
I would consider creating an Activity that would transactionally attempt to update a DB record to the effect that an instance of this workflow is in progress. If it finds that another is currently in progress it could take the appropriate action. It could fail or it could queue itself using an EventActivity to be alerted when the previous workflow has completed.
You probably will need to check at workflow start for another running instance.
If found, cancel it.
I don't agree that this needs to be handled at the WorkflowRuntime level. I like the idea of a custom Activity, sort of a MutexActivity that would be a CompositeActivity that has a DB backend. The first execution would log to the database it has a hold of the mutex. Subsequent calls would queue up their workflow IDs and then go idle. When the MutexActivity completes, it would release the Mutex, load up the next workflow in the queue and invoke the contained child activities.