Plug-in Tracing Enhancements in the Spring Release of CRM 2015
During a sesson at Convergence 2015, Matthew Barbour introduced a new enhancement to the Tracing Service in the Spring release of Microsoft Dynamics CRM 2015 that greatly enhances the value of this service to developers for logging and troubleshooting purposes. The Tracing Service was introduced in CRM 2011 and it allows developers to write log debugging messages from plug-in and custom workflow activities. The value of this feature was limited because it was written only to the Event Log of the CRM server or included in the error message displayed to end users. The former location is not accessible to CRM Online customers and although it is accessible for on-premise customers, log messages are hard to pinpoint among all the other events logged there. To address these limitations, a lot of development teams, including some I worked on, attempted to use a custom entity for logging purposes. They quickly found out that the log records they were looking for were somehow missing. This problem was due to the fact CRM plug-ins execute in transaction and the transaction is rolled back whenever an exception occurs anywhere in the event pipeline. As a result, the records written to the custom entity would also be rolled back in the exact scenario when they would have been of greatest value.
Plug-in Tracing Enhancements
The new enhancements to the Tracing Service aim to address these limitations by logging messages to a dedicated entity, making these messages available in a centralized location readily accessible to all interested parties. In addition, the messages are logged even if an exception is encountered and the rest of the transaction is rolled back, something that only the product team could implement. So how does it all work? First, the good news is that you can simply continue to use the Trace method of the Tracing Service to record messages so nothing in your code needs to change. To enable logging to the new entity, you need to use the "Enable logging to plug-in trace log" setting on the Customization tab in System Settings:
The setting provides the following options: Off, Exceptions, and All. The All option will log all messages, while the Exception option would log messages if an exception is encountered in the execution pipeline. Plug-in Trace Log records are available from Settings > Customization > Plug-in Trace Log and also from Advanced Find. You cannot extend the Plug-in Trace Log entity and the information logged in it and you can only view records or delete records of the entity.
As shown below, the Plug-in Trace Log entity exposes not only the log message passed to the Trace method, but also the exception stack trace, if an exception occurred, and other useful information about the and the context in which it executed such as the plug-in name, entity, message, depth, secure/unsecure configuration, etc.:
Finally, the system where I reviewed this feature included a Bulk Delete job that deletes all Plug-in Trace Logs older than one day. This feature is important because any logging feature will tend to generate a lot of data and the size of the Plug-in Trace Log table will likely grow very quickly. However, if you are using this feature to monitor exceptions in a Production environment in an effort to improve product quality, you may want to consider increasing this timeframe while monitoring the size of the table carefully.
Overall, this is a significant improvement that will make it easier to troubleshoot CRM plug-in and custom workflow activities, but I would like to suggest a couple of enhancements that would further increase the value of the Tracing Service. The first is the ability to turn logging on or off not for the system as a whole but for individual plug-in registrations. In large deployments, enabling logging even at the Exception level may generate a significant volume of Plug-in Trace Log records. Having the ability to turn logging on for Individual plug-ins would help alleviate that concern. Until that capability is available, I recommend adding an extension method to the Tracing Service that first checks a setting in the Unsecure Configuration of the plug-in registration before calling the Trace method and using that method in your plug-ins rather than calling the Trace method directly. Regardless of the approach taken, I recommend that you start thinking about a Bulk Deletion job for Plug-in Trace Log records as soon as you enable the Tracing.
Second, I would like to see a convergence (pun intended) of the capabilities currently available in the Plug-in Trace Log and Plug-in Profile entities. If Plug-in Trace Logs generated for exceptions contained the serialized plug-in execution context just like Plug-in Profile records and were integrated in the Plug-in Registration Tool, the Plug-in Trace Log entity could become a one-stop shop for both logging and for troubleshooting plug-in issues thus greatly enhancing its value to development teams. Anyone who has attempted to fix a bug will tell you that a significant portion of the effort is simply to reproduce the bug reliably especially if the bug is data-driven. Having the exception logged in the Plug-in Trace Log entity along with the context that it occurred in makes reproducing the issue rather trivial. This capability in turn can allow developers to proactively improve plug-in code quality by monitoring the Plug-in Trace Log entity and addressing any exceptions recorded by the system without waiting for end users to report them. Hopefully, we will see these improvements or alternative capabilities that solve these problems in the near future.