How to troubleshoot an online storefront deploymentTroubleshooting requires certain knowledge and tools. How these can be used/configured/implemented is described in this document.

General troubleshootingIn order to find the cause of any problem, these are a recommended list of things that can help:

- Consult the Event Log- Consult the SharePoint ULS log (if SharePoint-hosted code)- Verify if machine resources are not exhausted. Memory pressure can fail certain scenarios (i.e.

WCF activation on SharePoint-hosted environments)- Verify that any used user accounts are not expired, or had their passwords changed-

Diagnostics tracing

OverviewAny of the StoreFront code (incl. the Commerce Runtime) will by default write our trace information to the Event Log and SharePoint ULS log. The default levels that are configured are:

Here are the defaults as they are configured now:

Error Event Log and ULS log

Warning ULS log

Information hidden

As an example, this is how traces can be found in the Event Log:

The ULS logs can be found at this location: %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\Logs.

A sample entry looks like this:

10/22/2012 12:15:32.35* w3wp.exe (0x0170) 0x22F8 Dynamics AX Retail General ai1wu Medium ...RequestNotification(HttpContext context,

AsyncCallback cb) at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) at... 39c1d99b-3895-90cd-cd23-8e543d91e2de

The non-StoreFront code will use either an application configuration file- specified file location or by default (if nothing specified) a file at this location: %TEMP%\RetailLogs\<ProcessName>. There will be two files written, and when the configured size is reached, the files roll over.

Instrumenting custom codeCustomization code should use the provided APIs in the Microsoft.Dynamics.Commerce.Runtime.Diagnostics.NetTracer class to instrument the code. That will ensure that the added code would trace the information in the same manner as the Microsoft-shipped code.

Configuration file for SharePoint hosted codeAny code that is hosted by SharePoint must have this xml in its application/web config file:

<system.diagnostics> <sharedListeners> <add name="SharePointTraceListener" type="Microsoft.Dynamics.Retail.SharePoint.Common.SharePointTraceListener, Microsoft.Dynamics.Retail.SP.Common, Version=6.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" initializeData="" /> </sharedListeners> <sources> <source name="RetailNetTracer" switchValue="Information"> <listeners> <add name="SharePointTraceListener" /> </listeners> </source> </sources> <trace autoflush="true"> <listeners> <add name="SharePointTraceListener" /> <remove name="Default" /> </listeners> </trace> </system.diagnostics>

Configuration file for non-SharePoint hosted codeAny code not hosted by SharePoint must have this configuration section:

<system.diagnostics>

<sources> <!-- this registers the listener with traces from a specific source --> <source name="RetailNetTracer" switchValue="Warning"> <listeners> <add name="RollingXmlWriterTraceListener" /> </listeners> </source> <source name="RetailNetTracerEventLog" switchValue="Error"> <listeners> <add name="EventLogTraceListener" /> </listeners> </source> </sources> <!-- this defines a listener --> <sharedListeners> <!-- initializeData is the file name. If empty, it is going to be created in %TEMP%\RetailLogs\<name of exe> --> <add name="RollingXmlWriterTraceListener"

type="Microsoft.Dynamics.Retail.Diagnostics.RollingXmlWriterTraceListener, Microsoft.Dynamics.Retail.Diagnostics"

initializeData="" MaxLogFileInBytes="50000000"traceOutputOptions="ProcessId, DateTime,

LogicalOperationStack" />

<add name="EventLogTraceListener" type="System.Diagnostics.EventLogTraceListener" initializeData="Dynamics AX Retail" /> </sharedListeners> <!-- this configures tracing --> <trace autoflush="true"> <listeners> <remove name="Default" /> <add name="RollingXmlWriterTraceListener" /> <add name="EventLogTraceListener" /> </listeners> </trace> </system.diagnostics>

The level of traces that get written can be directly changed in the configuration file.

Configuring different tracing levels in SharePoint-hosted codeIf a customer wants to change which information is traced, SharePoint’s Central Administration Monitoring Configure Diagnostics Logging can be used to customize:

In order to do that, select the Dynamics AX Retail/ General Logging node and then customize the levels at the bottom of the page. The lower the list entries, the more verbose the tracing level is

Operations tracingThe channel database includes a table named “Operation”, which logs information about the success of most operations. That is similar to tracing but is happening on a higher level than the diagnostics tracing and has a certain format that can also help for gathering statistics about the health of the system.

In order to look at the last 1000 operations, and their outcomes, use this query

SELECT TOP 1000 [OperationCode] ,[OperationStatus] ,[RequestId] ,[Request] ,[Response] ,[ErrorCode] ,[ErrorContents] ,[CustomId1] ,[CustomId2] ,[CustomId3] ,[CustomId4] ,[WriteTime] FROM [AxRetailSP].[dbo].[Operation] order by WriteTime desc

The result may look like this:

To emphasize, even successful operations are logged here and can be used to gain information like how many times Publishing has succeeded in the last hour, etc.

StoreConnect Message tableMost data flows between AX and SharePoint through StoreConnect. To investigate the status of these messages, the AXRetailMsg database can be used. View the IncomingMessages and OutgoingMessagese tables for details. Order by datetime.

TO add:

More details about rolling file tracer

Add operations tracing with canned queries