This project is read-only.

Go to the downloads section and download the EnterpriseLogger.zip and unzip the same. Once you download, you would see the following components.

  • XrmLogger_managed.zip
  • Xrm.Logging.dll
  • RolePrivileUtility

 

Install the managed solution XrmLogger_Managed.zip in your organization.

Once the solution is imported successfully, open the folder “RolePrivilegeUtility”. Open the RolePrivilegeUtility.exe.config and change the below configuration settings as per your environment.

image

Once you have entered appropriate values in the configuration file, run the RolePrivilegeUtility.exe. Make sure that the user console completes without any error

 

Open the solution “XRM Logger” and move to the configuration page of the solution. Please check the below screenshot for the same

image_thumb8

You would be presented with the following options:

  • Select your installation type and depending on that the logging mechanism would change.
  • Enable or disable logging using the “Enable Logging” checkbox.
  • Ability to configure logging at individual plugin step level.
  • Ability to configure logging at custom workflow assembly level.

Let’s first concentrate on the on-premise/ IFD installation. The moment we select On-Premise/ IFD option, we get the following options for logging as shown in the below screenshot

image_thumb12

Each of these options is explained under separate headers below

 

 

File Logging:

Once we select File Logging, the users is asked to provide a file path to log. As the message in red suggests, the file can be local to the CRM server or should be accessible over the network from the CRM Server. Also the users of CRM should have write permissions to the file because the logging to this file would be done based on the user’s context from whom the logger utility is invoked.

I have entered D:\Logging\Logger.txt as the log file path and saved. Please check for the screenshot below.

image_thumb14

Once you have configured your logging, let us now concentrate on the other part of it. The second component of this tool is the Xrm.Logging.dll which you need to refer in your plugins/ custom workflow assemblies/ custom applications or any application through which you are interacting with CRM. I have created a sample plugin project for demo and have referenced the DLL in the project. Please check for the screenshot below.

image_thumb17

Once you are refer it, include the namespace “Xrm.Logging” in your plugin project and you are ready to use the logger in your code.

image_thumb20

The logger dll gives you option to log errors/ warnings and messages. Lets first explore the parameters that are required for logging an error. For that we invoke the method TraceHelper.LogError.

To generate an error, I am forcibly calling the Retrieve of account on any arbitrary GUID. Hence it would throw an error. The entire code is shown in the screenshot below.

image_thumb36

The LogError method has two overloads for FaultException and General Exception respectively. Use the parameters as per the documentation which is very detailed and also suggests when to use what as you can see from the screenshot above. As you can see the logger provides you an option to also show custom error message to the business user and also an option whether to pass the exception back to the user. So in the above example, the detailed error would get logged in the Logger.txt file and the business user would get a pop-up which would show “custom error message”. Now we also have an option to suppress the exception setting the “passExceptionToUser” as false. In that case the system would not throw the error back to the user. By default if you do not specify the parameter it would be set to true.

Once we are done with the code, build the plugins project. Now before regsitering, we first have to merge the Xrm.Logging.dll and Plugins dll. You can do it from the command prompt using the ILMerger.exe utility or using the ILMege tool from codeplex. Personally I prefer to use the latter as it is wonderful tool and you do not need to remember all the parameters that you need for merging. The tool is available for download at: http://ilmergegui.codeplex.com/

image_thumb42

As you can see I have added the Plugin and the Logging assembly and have selected my plugin assembly as the Primary assembly (check the checkbox beside the assembly to select the primary assembly). Next select “Sign with Key File” option and choose the strong name key that you used to sign your plugin assembly. Put the path for the merged file output. Choose the debug option as true in case you need to debug the merged assembly.

Now register the merged dll in the plugin registration tool and add the required steps. I have registered the plugin to fire on the account-precreate. Now when i try to create an account the following is the screenshot I get.

image_thumb48

We get Business Process Error and as you can see, the custom error message is shown to the user. Now let us open the Logger.txt file.

image_thumb50

The detailed error is logged in the text file. One big advantage of using the logging solution is it gets the entire stack of error message i.e it parses through the entire inner exception of the exception object.

Now say you want to log an exception in the text file but you do not want to show the message to the user or in other words you want to suppress the error. I will just come to the code and set the parameter passExceptionToUser:false. Check for the screen shot below.

image_thumb51

Now when we create the account, the account is now created successfully in-spite of the exception. However the error message is still logged in the logger file.

Now say you want to disable logging for the account pre-create step altogether. No need to change any code. All you need to do is go back to the solution and uncheck the checkbox for the plugin step and save. Check for the screenshot below.

image_thumb54

Now even though you have logging code, it would simply bypass and not log anything. Similarly you could use the LogMessage and LogWarning to log messages and warnings respectively.

image_thumb1

P.S – The logging configuration for plugins and workflows would only be respected if you pass the optional parameter of plugincontext or workflow context depending from where you are calling. If you do not pass the parameter in the logging method, it would always log even if you disable logging for the step.

 

Event Viewer Logging:

Now we would see how the same can be configured to log in the Event Viewer.

All you need is to come back to the solution configuration page and this time select the option “Event Viewer”.

image_thumb1

As you can see, you have to specify the “Event Source” as well the “Event Id”. Please note that the Event Source specified, if not found, the logger would try to create the source. If the user under whose context, the logging method is called, does not have that permission, it would fail. I would suggest you create an event source with the same name prior to logging.

Once we save the configuration, we now again try to create the account. If you are continuing from the previous article, please note that I have enabled back the pre-account step of the plugin for logging. Once the create operation is completed, we open the event viewer and check. Following is the screenshot of what we have in the event viewer.

image_thumb3

Voila!. We have changed the logging mechanism for the entire solution from file based to event viewer based without changing a single line of code. Isn’t that great and I am pretty sure this would save a lot of your time.

 

Custom Database Logging:

Here we would see how we can log in custom database from CRM just by tweaking the configuration page without even changing a single line of code. Please note that for this to work, the users should have access to the custom database with write permissions to the table where logging would be done.

I come back to the configuration page of “Xrm Logger” solution and this time I select “Database” as the logging mechanism.

image_thumb2

The following information needs to be entered

  • Connection String : the connecting string to the custom database
  • Table name : the name of the table where logging would be done.
  • Message – The column name of the table where the Error Message/ Warning/ Message logged by the logger would be stored
  • Message Type – The column name in the custom database table that would store the value indicating where it is Error/ Warning/ Message
  • Stack Trace – The column to store the Stack Trace information in case of an error
  • Source Method – The column to store the name of the method from where the logger has been invoked. Basically whatever you pass in the parameter methodSource of the logging method, that value would be stored here
  • Log Time – The timestamp when the logging happened.

I have a custom database where the logging would be done. I enter all the fields and save the configuration. Please check for the screen shots below.

Screenshot for the database where logging would be done.

image_thumb4

Values entered in the configuration entity

image_thumb7

Please note that the connection string is stored in the CRM database Encoded and any user other than the system administrator would not be able to view the connecting string in plain text format.

Now I go again in CRM and create an account. And when I query the Log Table the following is the screenshot of what I get.

image_thumb10

And you have logged in your custom database without changing a single line of code. Hope this would surely help.

 

Logging in CRM Entity:

Now we would see how we can configure the Enterprise Logging tool for CRM to log in the CRM entity. This is the most simplest of configuration.

The logging would happen in the “Error Log” entity which is comes with the Xrm Logger solution.

Please Note: If you are using Crm Entity as the logging mechanism, you should make sure that all your security roles should have Organization Level Read, write and Create access on the Error Log entity. Sounds difficult? No worries, I have the RolePrivilegeUtitlity.exe executable, which I would provide along with this tool, which will do that for you.

Now I have selected “Crm Entity” as my logging mechanism and saved the configuration.

image_thumb1

Now I again go in CRM and create an account. Next I open Advanced Find in CRM and check for the Error Log entity.

image_thumb3

image_thumb6

Isn’t this truly interesting. You have changed the Logging Mechanism without changing a single line of code!

Please read this very carefully if you are using the CRM entity as your logging mechanism

If you are invoking the Logger methods from CRM, where CRM maintains transactions (synchronous plugin and synchronous workflows(CRM 2013 only)), the logger tool would log an error in the Error Log entity only if the passExceptionToUser parameter in the method of the logger is set to false. If it is set to True, the error would be thrown back to the user with the complete stack trace but no Error Log record would be created. However no such restrictions for Warning and Message Logging.

Another great advantage of the tool is say you are moving your organization from on-premise to online, no change in the logging code is required. All you need to do is come back to the configuration page of the Xrm Logger solution and select Office 365 and then CRM would start to log in the Error log Entity.

Last edited Jul 8, 2014 at 5:08 PM by debajdu, version 3