On-premise plug-in development
A plug-in is custom business logic (code) that you can integrate with Dynamics 365 for Customer Engagement apps to modify or augment the standard behavior of the platform. Another way to think about plug-ins is that they are handlers for events fired by Dynamics 365 for Customer Engagement apps. You can subscribe, or register, a plug-in to a known set of events to have your code run when the event occurs.
Dynamics 365 for Customer Engagement apps are built on the Common Data Service platform, which is also the underlying data platform for PowerApps. If you are a Dynamics 365 for Customer Engagement apps (on-premises) user, you continue to use the Customer Engagement platform that has similar functionality as Common Data Service.
The plug-in documentation that is applicable to Dynamics 365 for Customer Engagement apps (online) users is now available in the PowerApps documentation at: Use plug-ins to extend business processes
This topic and its sub-topics contain information that is applicable only for the on-premises users of Customer Engagement apps.
For more information about plug-in run-time execution, see Event Framework.
Best practices for on-premise plug-in development
This section includes best practices specific to on-premise plug-in development
Don't depend on references to variables passed into plug-ins
In an on-premises environment where a full trust plug-ins are executed within the same app domain, don't expect that a variable that refers to data included in the plug-in context will maintain a reference to the object.
When data is passed into the event pipeline, the data is serialized and de-serialized to create a new object instances. The object instances do not refer to the same memory address. Any changes to the object in the plug-in execution pipeline will not be reflected in an object instance that was passed into an operation in the pipeline.
For example, if you define a QueryExpression that is included in a RetrieveMultipleRequest, if there is any code within a plug-in that changes the QueryExpression, that change will not occur on the original QueryExpression instance variable that was passed with the RetrieveMultiple request. Within the pipeline, the QueryExpression object properties may be updated in the process of retrieving the data. For example, the QueryExpression.PageInfo property will be updated as a part of executing the query. You will not be able to detect these changes by examining the original QueryExpression variable that was used with the RetrieveMultipleRequest.
Where should you put plug-ins and custom workflow activities?
For on-disk plug-ins or custom workflow activities, place the assemblies in the
In This Section
피드백 로드 중...