In Microsoft Dynamics 365, plugins are executed within a pipeline that consists of multiple stages. The three primary stages—PreValidation, PreOperation, and PostOperation—determine when your custom code runs relative to the core data operation. Each stage has its own characteristics, benefits, and use cases. This article explains the differences between these stages.
1. PreValidation Stage
Timing:
- Executes before any platform security checks and prior to the creation of the transaction context.
Characteristics:
- Early Validation: Ideal for checking input parameters or enforcing business rules before any processing occurs.
- Non-Transactional: Operations performed here run outside the main transaction; if the main operation fails, changes made in PreValidation are not rolled back.
- Database Access: You can query the database using the IOrganizationService; however, be aware that modifications are not transactional.
Use Cases:
- Validating request data.
- Intercepting and blocking operations if certain conditions are not met.
- Performing logging or preliminary data checks.
2. PreOperation Stage
Timing:
- Runs after PreValidation but before the main operation is executed on the database.
Characteristics:
- Within the Transaction: Code executed in this stage is part of the transaction that includes the main operation. This means any changes you make here will be committed if the transaction succeeds, or rolled back if it fails.
- Input Parameter Modification: You can modify the input parameters of the operation, allowing you to change the behavior of the upcoming core operation.
- Database Access: Full access to the database context is available, and any updates here affect the operation’s outcome.
Use Cases:
- Modifying the data that will be saved (for example, setting default values).
- Enriching the target entity with additional data.
- Performing complex business logic that must be committed as part of the main transaction.
3. PostOperation Stage
Timing:
- Executes after the core operation has completed and the data has been committed to the database.
Characteristics:
- Out-of-Transaction: PostOperation runs outside the context of the main transaction. As such, any actions performed here will not affect the outcome of the original operation.
- Read-Only on Core Data: Although you can query and interact with the data, you cannot change the main entity data that was just committed.
- Integration and Notifications: Commonly used for integrating with external systems, sending notifications, or performing asynchronous logging.
Use Cases:
- Triggering external workflows or integrations.
- Sending confirmation emails or notifications after a record is saved.
- Performing follow-up operations that do not need to be rolled back if the main transaction fails.
Summary of Differences
PreValidation:
- When: Before security checks and transaction creation.
- Transaction: Not transactional.
- Purpose: Early validation and blocking of operations if necessary.
PreOperation:
- When: Just before the core operation, within the transaction.
- Transaction: Part of the transaction; changes here roll back on failure.
- Purpose: Modify or enrich data that is about to be saved.
PostOperation:
- When: After the main operation has committed.
- Transaction: Executes out-of-transaction.
- Purpose: Perform additional processing such as integrations and notifications.
Understanding these stages is crucial for designing robust plugins that interact with Dynamics 365 data. By choosing the appropriate stage, you can ensure that your custom logic executes at the right time and with the correct transactional behavior.
No comments:
Post a Comment