Plugins Unplugged: Breaking Down the Complexity for Developers !!

Dynamics 365 (D365) is designed to deliver solutions with low code or no code. However, there are scenarios where business requirements are more complex and cannot be achieved using the platform as it is. In such cases, custom coding comes to the rescue.

🔧 Complex Scenarios Requiring Custom Code

1. Data Integration: Sending data to different systems.

2. Bulk Data Updates: Handling large volumes of data efficiently.

3. Complex Business Logic: Implementing intricate business rules.

4. Deployment Automation: Streamlining deployment processes.

5. Data Import/Export: Managing data transfers.

🤔 Why Custom Code Instead of Power Automate?

While Power Automate can handle many tasks, it has limitations, especially for organizations that prefer on-premise applications over cloud solutions. Custom code becomes essential in these situations. We can develop complex requirements using custom coding components like plugins, custom workflows, WebAPI, etc.

• Server-side Components: Plugins, workflows, actions.

• Client-side Components: HTML, JavaScript, XML.

These components access the CRM database and interact with web services to modify data.

D365 Web Services

D365 offers two main web services:

• Discovery Service: Helps find instances and organizations for given credentials.

• Organization Service: Handles basic CRUD operations and advanced message operations like import/export customization and metadata editing. It allows schema changes by connecting with the organization service.

SOAP and REST

• REST: Used for client-side operations.

• SOAP: Used for server-side operations.

🔍 Unlocking the Power of Plugins in Dynamics 365

Plugins are a powerful way to extend Dynamics 365 (D365) functionality, enabling developers to meet complex requirements. It is a class library or set of classes that runs on server events/messages like create, update, delete, assign record, etc. It's an assembly with custom code registered on server-side events.

Let's dive into how plugins work and how you can leverage them to enhance your D365 solutions.

🔄 Plugin Pipeline: The Journey of Data

When a user or client creates a record, the data embarks on a journey through several stages before it reaches its final destination in the database. Here's a breakdown of the plugin pipeline:

1. Pre-Validation Stage: 🛡️ Custom code accesses the record's data and performs validation checks to ensure everything is in order.

2. Pre-Operation Stage: ⚙️ Actions take place before the main operation, setting the stage for the core changes.

3. Main Operation: 🗄️ This is where the magic happens! Data is inserted into the database.

4. Post-Operation Stage: 🔄 Any final modifications needed before the response is sent back to the client are made here.

Microsoft provides the capability to insert custom code on the server before or after the main event occurs in the database through plugins. This flexibility allows for a wide range of customizations and enhancements.

🛠️ How to Write a Plugin: Step-by-Step Guide

Ready to create your own plugin? Follow these steps to get started:

1. Download and Install Visual Studio: Ensure you have Visual Studio installed to begin your development journey.

2. Create a Class Library Project in C#: Start a new project in Visual Studio and set it up as a class library.

3. Download Assemblies from NuGet Package Manager: Add the necessary Dynamics 365 assemblies to your project.

4. Add References to Assemblies: Include the downloaded assemblies in your project to access D365 functionalities.

5. Implement the IPlugin Interface: Write your plugin code by implementing the IPlugin interface.

Here is a handy template you can use to write your plugins :

Now Lets Dive Deeper to understand more on plugins :

🚀 Understanding Images in Plugins 🚀

Images in plugins are like "before and after" snapshots of an entity's fields. They help capture data before and after core operations, providing valuable insights into changes.

📸 Pre-Entity Images

Pre-entity images capture data before any modifications occur. They are useful for accessing values that were not updated, as the primary entity only passes modified values.

📸 Post-Entity Images

Post-entity images retrieve data after modifications have taken place, allowing you to see the final state of the entity.

🛠️ Example Code

🔄 Impersonation in Plugins

By default, plugins run under the context of the logged-in user. To run plugins under a different user's context, you can impersonate the plugins:

1. At the time of registering the plugin - The entire plugin runs under the context of a different user.

2. At the time of writing the plugin code - Specific lines of code can run under a different user's context.

🛠️ Example Code for Impersonation : In this code Record1 will be created in context of impersonated user !!

🔗 Sharing Data Between Plugins

Plugins should be in the same pipeline and execution context. Use shared variables to pass data from pre to post operation.

🛠️ Example Code for Shared Variables

🌟 Benefits of Shared Variables

• Efficiency: Avoids unnecessary calls to the organization service.

• Simplicity: Reduces the need for custom attributes to store intermediate data.

• Flexibility: Allows for easy data sharing between different stages of the plugin execution pipeline.

🔒 Plugin Isolation Mode

🔒 Partial Trust (Sandbox)

Sandbox: Plugins run under a secure layer that protects access to Microsoft's cloud file system, registry, and events. Microsoft online instances or cloud instances only allow plugins to be registered in the sandbox for security reasons. Uploading custom .NET code to Microsoft's cloud server could pose a security risk if the code tries to access the server's file system, registry, event log, etc. Since plugins are user-defined code, Microsoft created a separate worker process to handle them.

🌟 Benefits of Sandbox Mode

• Supports runtime monitoring and provides CPU utilization data.

• The Dynamics platform monitors code execution and resource utilization. These metrics are recorded in Dynamics 365 tables, which can be retrieved and analyzed.

🔓 Full Trust (On-Premise Deployment)

On-Premise: Since it's your own server, there are no restrictions. Your code can access the file system, registry, etc., as it is your own server.

🔧 Configuration Data

If you need to store information that varies between environments, instead of hardcoding it, you can store the values within configuration variables.

• Passing Configuration Data: Configuration data can be passed during the time of plugin registration.

• Accessing Configuration Data: It can be accessed using the constructor method.

For example, if you need to access a password in a plugin to call an external web service, you can use the secure configuration. During export, secure configuration data is trimmed, while unsecure configuration data remains unchanged.

🛠️ Example Code for Configuration Data

⏳ Synchronous vs. Asynchronous Plugins

Synchronous Plugins

Plugins are by default synchronous. When you update a record, all plugin pipeline stages are executed one by one: Pre-Validation, Pre-Operation, Core Operation, and Post-Operation. Only after these stages are completed will the user form be reloaded. This is called synchronous because the user form will not be reloaded until all these operations are completed.

Asynchronous Plugins

Asynchronous plugins are triggered by the main process but handled by a different worker process. The control does not need to wait for any operation to complete, allowing the user to execute the operation without delay. The actions registered in the asynchronous plugin will be executed separately by the worker process.

For example, if you need to update hundreds of records, asynchronous plugins should be used. This way, the user will not experience any delay in execution, and performance will be improved.

#PowerPlatform #Dynamics365 #MicrosoftDynamics365 #DeveloperCode #CustomCode #Plugins #Dataverse

Feel free to connect and share your thoughts! 😊