D365 PRE-POST IMAGES IN PLUGINS

Images are snapshots of the entity’s attributes, before and after the core system operation. Following table shows when in the event pipeline different images are available: 

Message	Stage	Pre-Image	Post-Image
Create	PRE	No	No
Create	POST	No	Yes
Update	PRE	Yes	No
Update	POST	Yes	Yes
Delete	PRE	Yes	No
Delete	POST	Yes	No

 

FEW MORE POINTS 

• Whether a plug-in executes synchronously or asynchronously, there is a 2 minute time limit imposed on the execution of a (message) request. 
• If the execution of your plug-in logic exceeds the time limit, a Timeout exception is thrown 
• If a plug-in needs more processing time than the 2 minute time limit, consider using a workflow or other background process 

• ‘Pre-operation’ operations that CRM will do will not be carried out in pre-validation stage. 
• If you are deleting a record that has many-to-many relationship records with another entity; these relationship records will still be available in pre-validation stage, but not in pre-operation stage. 
• “Target” entity (i.e., pluginContext.InputParameters[“Target”]) 

 

It’s the entity on which plug-in registered. It only contains “dirty” attributes. If you convert to early bound, the value of the unchanged attribute will be null 

 

EXAMPLE OF PRE-VALIDATION USAGE? 

 

Entity: Account | Event: Delete 

Logic: Plugin runs pre validation. Checks that there are no contacts referencing any of the account’s addresses. If any are found, stop execution. If not, delete account. 

Example: Account ‘Stack overflow’ has address ‘Jeff Attwood’s House’ and Contact ‘gloss‘.  

‘Gloss‘ is referencing ‘Jeff Attwood’s House’ through a customization. If a user selects to delete ‘Stack Overflow’, we should detect ‘gloss‘ is referencing an address and prevent the delete. 

The reasoning behind this was the developer found that at the Pre–Operation stage, some aspects of the delete had already happened, namely the cascade deletes. The logic of the plugin requires us to check all contacts – by registering at Pre–Operation, contacts under the account had already been deleted, rendering the check obsolete. 

In our previous scenario, when the user selected to delete ‘Stack Overflow’ Account, the Contact ‘gloss‘ would be deleted before the plugin runs. Therefore when the plugin did run afterwards, it would allow the delete. 

IF CASCADE DELETE HAPPENS OUTSIDE OF TRANSACTION, THEN HOW DOES ROLLBACK HAPPEN IN CASE OF ERROR? 

Maybe I misunderstand here but if the account deletion was to fail for some other reason and the pre-operation plugin threw an exception, how would the cascade deletes be reversed? If the cascade deletes happen before the pre-operation stage then they happen outside the transaction so i’m not sure how crm would be able to reverse them? 

Essentially, at the pre validation stage, nothing has happened. At the pre operation stage, the cascade deletes have happened but they occur inside the transaction, meaning they can be rolled back 

Availability of images

When you configure an entity image it is important that you recognize that the type of entity images available depend on the stage of the registered step and the type of operation. For example:

• You cannot have a Pre Image for the Create message because the entity doesn’t exist yet.
• You cannot have a Post Image for the Delete message because the entity won’t exist anymore.
• You can only have a Post Image for steps registered in the PostOperation stage of the execution pipeline because there is no way to know what the entity properties will be until the transaction is completed.
• For an Update operation that is registered in the PostOperation stage you can have both a Pre Image AND a Post Image.

Hope this helps!

Advertisement