Before CRM 2015 SP1 update, an alternative option to debug the Plug-in or Workflow for developers was to use tracing messages which would help to trace the program using custom messages.
The developer had to manually throw an exception in order to trace the program. And then when the plug in/workflow is triggered a dialog is shown up to “Download the Log File” which contains the tracing information.
So, the user/Developer had to read the tracing from the downloaded text file, which was a tedious job itself.
So now in CRM 2015 SP1 update, we have one more option in which we have a new Entity called “Plug-in Trace Logs” which itself creates record for any exception occurred or thrown by the developer.
But in order to enable this feature we need to make following settings in CRM.
- Go to Settings >> Administration
- Under Administration >> System Settings >> Customization Tab
So as we can see here there is an option “Enable logging to plug-in trace log”. By default it is Off, we need to select the option “Exception” in order to enable the creation of Plug-in trace log records in case any exception or error occurs.
There’s one more option in addition to this as mentioned in SDK and i.e. “All”. In the preview Version we don’t have it.
It’s mentioned that if we select “All” then the tracing information would be written to Trace Log record upon complete code execution or any error occurred throw custom code.
Once we have enabled the feature, we can view the Trace Log Records under:
Settings >> Plug In Trace Log Entity:
Records are created in CRM as below, which are read only just like System Job records to find out the error occurred.
Now let’s see what this record actually contains and why it simplifies the earlier process of debugging Plug-In and workflow using ITracingService interface.
You can see the record contains attributes like Message Name, Primary Entity, Mode etc which helps to get the information related to Plug-in.
As shown below it contains two fields Message Block and Exception Details which contains the actual data the user / developer is keen to understand.
Message Block: Contains the actual Tracing information which we specify in our Plug-in /Custom Workflow to Trace method. For e.g. tracing.Trace(“Workflow Started”); where tracing is an object of ITracingService.
Exception Details: Contains the Exception related information which has occurred in Plug-in or Custom Workflow.
Also we can view the Trace Log records using Advanced Find. Hence we can even filter out records based on the Query specified in Advance find. Below is an example of that:
We are selecting only those records which are created due to Plug-ins.
In addition to this there’s one more advantage of the Trace Log Entity.
Before, this feature was introduced the developers used to create a Custom Entity for storing Log Records so that they could trace the tracing information or exception details. But it was quite tricky in case of Transactional Plug-ins, as we know if any part of code fails in it, the entire changes would roll back and the custom entity to store the tracing information is not created. Although now, with this System Trace Log Entity the Trace records will be created even if the code fails.
Let’s take an example to understand it. We have registered a Plug-in on “Qualify Lead” on the Post Operation.
Let’s qualify the lead and suppose an exception occurs during execution as below:
We can “Download Log File” and read the “Tracing Information” which we used to do earlier. Or now we have an option to read the related Trace Log Record which is created even if the changes are Roll Back in the system i.e. Lead is not qualified.
The related trace log record created in the system is as below:
Thus, as we can see now the trace log record is created anyhow in the system even if the operations in the Plug-in are roll backed.
Now, who can view these records by default in CRM?
By default, the System Administrators and System Customizers can view these records but the access to view can be granted to other Users too.
NOTE: Trace logs will only be written to the trace log entities if the plug-in developer uses tracing within the plug-in.
If we have enabled this feature in our System, then Trace Log records will henceforth be created in CRM for the entities having Plug-in or Custom Workflow (which implements ITracingService) registered on it. Due to this more number of Trace log records could be created in CRM, so in order to manage this we can create a Bulk Deletion Job which we can schedule such that the trace log records would be deleted over fixed interval of time.