NAV Team: Enabling Diagnostic Tracing for Dynamics NAV Web Services

[Blog bot]

Dynamics NAV Services (Web and RTC) are both WCF (Windows Communication Foundation) services and the tools used to troubleshoot WCF can be used to troubleshoot your NAV Services. The steps below can be used for both the NAV RTC and NAV Web service instances. A core feature of WCF is to allow trace logging to diagnose any problems you may encounter within the web service. Before jumping into creating a trace file for the NAV Web Service, some clarification on WCF tracing is in order.

WCF - Trace Listeners

WCF provides base "Trace Listeners" that can be used to capture specific events and output data to some medium. For instance, you can output trace results to a UI, file, or Windows event log. The three main types are:

Here are some of the core WCF Trace listener's provided by .Net and what they can capture:

Assembly NameDescriptionSystem.ServiceModel

Logs the following:

• Message process
• Reading of configuration information
• Transport-level action
• Security requests

System.ServiceModel.MessageLoggingGenerates tracing information for every message that flows through the system.System.ServiceModel.IdentityModelGenerate trace data for authentication and authorization.System.ServiceModel.ActivationEmits information regarding activation of the service.System.Runtime.SerializationEmits information when objects are serialized or deserialized. WCF always serializes and deserializes information during request so it's a good event to see the content of the request.WCF - Trace Levels

WCF Trace Listeners incorporate a "Trace Level" that allows you to configure the level of tracing. Here are the levels and what they capture:

Trace levelNature of the tracked eventsContent of the tracked eventsTracked eventsOffN/AN/ANo traces are emitted.Critical"Negative" events: events that indicate an unexpected processing or an error condition.

Unhandled exceptions including the following are logged:

• OutOfMemoryException
• ThreadAbortException (the CLR invokes any ThreadAbortExceptionHandler)
• StackOverflowException (cannot be caught)
• ConfigurationErrorsException
• SEHException
• Application start errors
• Failfast events
• System hangs

Error"Negative" events: events that indicate an unexpected processing or an error condition.Unexpected processing has happened. The application was not able to perform a task as expected. However, the application is still up and running.All exceptions are logged.Warning"Negative" events: events that indicate an unexpected processing or an error condition.A possible problem has occurred or may occur, but the application still functions correctly. However, it may not continue to work properly.

• The application is receiving more requests than its throttling settings allow.
• The receiving queue is near its maximum configured capacity.
• Timeout has exceeded.
• Credentials are rejected.

Information"Positive" events: events that mark successful milestonesImportant and successful milestones of application execution, regardless of whether the application is working properly or not.

In general, messages helpful for monitoring and diagnosing system status, measuring performance or profiling are generated. You can use such information for capacity planning and performance management:

• Channels are created.
• Endpoint listeners are created.
• Message enters/leaves transport.
• Security token is retrieved.
• Configuration setting is read.

Verbose"Positive" events: events that mark successful milestones.Low level events for both user code and servicing are emitted.

In general, you can use this level for debugging or application optimization.

• Understood message header.

ActivityTracing Flow events between processing activities and components.

This level allows administrators and developers to correlate applications in the same application domain:

• Traces for activity boundaries, such as start/stop.
• Traces for transfers.

All Application may function properly. All events are emitted.All previous events. How to Enable Tracing with NAV

Tracing can be enabled by modifying the web service configuration file and the appropriate elements to alter the behavior of the service. The sample below provides a minimal level of tracing. As a minimum within the configuration file, you need to add a source, a listener, a listener type, and a location for the results. Below is a configuration snippet that is using the SystemService.Model Trace Listener with a listener of type "System.Diagnostics.XMLWriterTraceLister", and a location of "C:LogTraces.svclog" to log tracing events.

<configuration>
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="All, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:logTraces.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>

Note, the "switchValue" refers to the "Level" of logging as described above. PropogateActivity allows you to correlate activity across endpoint(s), which is very helpful in correlating client to server communications. The type "System.Diagnostic.XmlWriterTraceListener" allows you to direct the tracing and debugging output as XML-encoded data. The file created has an extension ".svclog", which is a special file type reserved for use with the service trace viewer tool (which is part of the windows SDK).

To enable tracing for the NAV web service, all we need to do is update the NAV configuration file with the diagnostic elements so that we change the behavior to emit trace results. To enable tracing for NAV, update the Microsoft.Dynamics.Nav.Server.exe.config file in your installation folder. Using the above snippet as a basis for a trace, you would end up with the following configuration. (Make a backup of your configuration file before modifying!).

Microsoft.Dynamics.Nav.Server.exe.config (Before modification)

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings file="CustomSettings.config" />
<system.diagnostics>
<assert assertuienabled="false" />
</system.diagnostics>
</configuration>

Microsoft.Dynamics.Nav.Server.exe.config (After modification)

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings file="CustomSettings.config" />
<system.diagnostics>
<assert assertuienabled="false" />
<sources>
<source name="System.ServiceModel"
switchValue="All, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:logTraces.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>

The next step is to ensure that the user or service that is running your Dynamics NAV Service has rights to write to the "C:log" directory. Create the directory if you don't already have it and apply security rights to the user or service identity currently used for your Dynamics NAV web service.

The last thing to do is to simply restart your NAV web service to enable the new configuration. Note: the Dynamics NAV Service and the Dynamics NAV Web service use the same configuration when starting up the service, so stop the Dynamics NAV Service to isolate the trace to only web service specific activity. When you start NAV web services, you should see a trace file in the "C:Log" directory. To view the trace file, use the Service Trace Viewer tool (SvcTraceViewer.exe), which is installed with the windows SDK and can typically be found in the default location of "C:Program FilesMicrosoft SDKsWindowsv6.0Bin". The amount of information in your trace file will depend on the tracing level you have defined. Typically I use the tracking event "All" so that I get all information from the trace listener. Please note the WCF will cache some of the trace results and will not flush out the trace elements entirely in real time. Once you have recreated the problematic activity with the trace running, you will need to stop the NAV Web service to flush out the entire trace results. The trace file is locked for writing until the service is stopped; at which time you can use the trace viewer to view the trace results. Using the trace viewer you can see the detail of any exceptions and then leverage that detail to help isolate the problem in the web service.

To disable logging, restore your original configuration file and restart your NAV web service. When performing tracing in a production environment, see the following link in MSDN for additional information:

Recommended Settings for Tracing and Message Logging in a Production Environment

http://msdn.microsoft.com/en-us/library/aa702726.aspx

In addition, here is a helpful link in MSDN that describes how to correlate activities between client and server along with using the trace viewer tool:

http://msdn.microsoft.com/en-us/library/aa751795.aspx

Happy tracing!

Best regards,
Bert Burkholder
NAV Escalation Engineer

Источник: http://feedproxy.google.com/~r/Micro...-services.aspx