The need for logging in Ax for me came from the .Net world of using Debug.Writeline , and then looking up the debug values from sysInternals dbgview.
However, to make a very quick and just basic configurable logging, i went to write the logs into a file.
This is a quick and dirty way to add logging capabilities into Dynamics ax.
The project can be found at Codeplex: http://axug.codeplex.com/SourceControl/changeset/view/82084#1932052
To go on with the current logging, following is the code signature of the method to be called for passing the logging message
public static void LogMessage(str _processId, str _text = '', int _step = 0)
and logging can be called by
Logging::LogMessage("Testing Logging","Logging is great :)", 0);
The Macro values define if the logging capability is turned on, and also the filename (So it can be configured from the usr layer / production site)
I have tested this with Ax 2012 and it has worked pretty well so far, and i do not think Ax2009 should have an issue with it. This logging is so far restricted to file based logging, but I am looking at incorporating other forms like Debug.WriteLine, and will further look into incorporating log4Net (however i have a strong suspicion that this will be limited to server side, and only for Ax 2012).
Hope this brings enough joy to you out there.
NOTE: before you run the test class in the project, please make sure to edit the Macro to specify the folder path (This can be set to a local directory, but please be advised, this method is “called from”)
I have now updated the code to include 2 more logging features. Along with that made changes to the method to include the type of message being passes (i.e. warning, information or error. We shall see why)
1. Windows Event logging. – This enables you to you write into the Windows Event log directly. The log type (info , error, warning) will correlate directly to the log icons in the event viewer 🙂
2. Debug log: The most simplistic logging with .Net’s System.Diagnostics.Debug.WriteLine is now included. Although i have seen that this also writes to the event log 😦 (as information only, probably something that is handled from x++ itself, so may not be a good idea to have it in a production server where it manages to clutter the event viewer)