We usually receive questions about where should plugins be registered, and is sandbox a recommended option assuming it is "sandbox-ready", or is it only for Dynamics CRM Online? Based on what we have seen and experienced with our customers, in this post we will answer these questions and more importantly discuss how you can monitor the plugins hosted in the sandbox service.
Where to register my plugin?
Developers have the option of registering their plug-ins in the sandbox, known as partial trust, or outside the sandbox, known as full trust. Full trust is supported for on-premises and Internet-facing Microsoft Dynamics CRM deployments. For a Microsoft Dynamics CRM Online deployment, plug-ins or custom workflow activities must be registered in the sandbox (partial trust) where they are isolated as previously described.
In summary, if your plugins are “Sandbox-Ready/compliant” that conform to the boundaries of the sandbox process (Partial trust) as described in How to: Run Partially Trusted Code in a Sandbox, then the sandbox is the recommended execution environment for plug-ins as it is more secure, supports run-time monitoring and statistics reporting, and is supported on all Microsoft Dynamics CRM deployments. In addition, Microsoft Dynamics CRM Online only supports execution of custom workflow activities if they are registered in the sandbox.
Plug-in isolation, trusts, and statistics
Monitoring plugins hosted in sandbox
"PluginTypeStatistic"
This entity is used by the platform to record execution statistics for plug-ins registered in the sandbox (isolation mode). The schema name for this entity is PluginTypeStatistic. To view the entity metadata for your organization, install the Metadata Browser solution described in Browse the metadata for your organization.
PluginTypeStatistic entity messages and me
Run-time statistics
The Microsoft Dynamics CRM platform collects run-time information about plug-ins and custom workflow activities that execute in the sandbox.
This information is stored in the database using PluginTypeStatistic entity records. These records are populated within 30 minutes to one hour after the sandboxed custom code executes. See the PluginTypeStatistic attributes to find out what information is
collected. You can retrieve this information by using the retrieve message or method.
If the sandbox worker process that hosts this custom code exceeds threshold CPU, memory, or handle limits or is otherwise unresponsive, that process will be killed by the platform. At that point any currently executing plug-in or custom workflow activity in that worker process will fail with exceptions. However, the next time that the plug-in or custom workflow activity is executed it will run normally. There is one worker process per organization so failures in one organization will not affect another organization.
An easy way to see the statistics is through the advanced find, look for “Plug-in type Statistics”
You’ll find very interesting information reflected in the columns of the view that includes:
TerminateMemoryContributionPercent, OrganizationId, AverageExecuteTimeInMilliseconds, FailurePercent, PluginTypeStatisticId, ModifiedOnBehalfBy, CrashPercent, CreatedBy,
FailureCount, CreatedOnBehalfBy, CrashCount, CrashContributionPercent, TerminateCpuContributionPercent, ModifiedBy, TerminateHandlesContributionPercent, PluginTypeId, ModifiedOn,
ExecuteCount, TerminateOtherContributionPercent, CreatedOn.
For example, the execute count and failure count columns could be compared to determine the percentage of failures. The failures could then be investigated further to determine root cause. In our case, it was because the business logic in the custom component was expecting data that was not there and throwing a NullReferenceException.
We hope this information had shed lights on the sandbox service and how to monitor it!
By: Julien Clauzel, Fadi EL-Hennawy