In a previous blog post, we covered how to debug Methods inside of Aras Innovator. In this blog post, we'll be covering the basics of using the standard Aras Innovator server logs as well as some best practices for using logs. Server debug logs, when enabled, output all of the AML coming to and from the server to files in a designated folder in the Aras Innovator codetree. These logs can be especially helpful when tracking down an error that's being thrown from a cascading series of events where you're not sure which Method is causing the problem.
Generating Server Logs
Identify the Problem Action
Enabling server logs will output all of the AML queries and results of those queries to files on the server. Many of these logs can be generated in a very short amount of time, so it is recommended that you leave the logs enabled for as briefly as possible. To do this, the first step when turning to logs is to identify the exact action that causes the error you're trying to diagnose. After that action is identified, you'll want to login to Aras Innovator and set up the environment to a state just before that action is run. For example, if a user reports an error when saving a new item, you'll want to create a new item and fill out any required fields but not actually save the item to create it.
Clean Up Existing Logs
Next you'll want to delete any logs that may exist already. This will help minimize the amount of files you need to look through to find the error you are looking for.
- Navigate to the install path of your Aras Innovator instance (C:\Program Files (x86)\Aras\Innovator\ by default)
- Go to \Innovator\Server\logs\
- Delete any existing files here
Turn on Server Debug Logs
These next few steps should be performed as quickly as possible so the fewest number of logs are generated. This will make reading through the logs to diagnose the error much easier.
- Go back to the root of your install path and open InnovatorServerConfig.xml
- Near the top of the file make the following edit to enable logs
<operating_parameter key="debug_log_flag" value="true"/>- It may be necessary to restart IIS after making this change
Perform the Problem Action
Once the logs are enabled, you will want to quickly switch back to the context of your Innovator window and perform the action that causes the error. In the situation we mentioned above, we will want to now click the save button to create our new item which should fail.
Turn off Server Logs
After the error or unexpected behavior happens, you will want to follow the steps below to stop any more logs from being generated.
- Switch back to the editor where you have opened InnovatorServerConfig.xml
- Disable the logs by reverting the change made above
<operating_parameter key="debug_log_flag" value="false"/>- Again, it may be necessary to restart IIS after making this change
Reading the Logs
When you navigate back to /Innovator/Server/logs/, you may see more than one file that's generated but following the steps above should both minimize the number and size of these files. The logs you should see will be XML files and generally follow the format of call and response. You'll also notice that these calls to and from the server are wrapped in SOAP envelopes. Because of this, you can usually find errors pretty easily by opening these files into a text editor and searching for the string "Fault". Once you find the error returned from the server, you can look directly above that response in the log to find the AML that caused the error.
Logs to Ignore
There are some applications that Aras supports like SSVC or the ConversionServer that periodically make calls to the server. Unless you're specifically debugging these applications, you can typically ignore logs that list any AML using the ConversionTask ItemType or AML using SSVC methods like GetNotificationMessages.
Conclusion
Outputting logs can be especially helpful for diagnosing errors when you don't know the specific method or AML that's causing the issue. However, you should also take care when using these logs to ensure that both that reading through the logs is easier for you and that you don't bloat your server with unnecessary log files.