LOGS AND TRACES.. Refresher Part Deux

 In continuing this refresher series of logs and traces we will cover some of the built-in capabilities that are available to use, specific to:

1. Batch server logs
2. Syracuse logging
3. Workflow email logs
4. Web scheduling logs
5. SEI Logs
6. ADC (MA) services Log
7. Print server

Let’s jump right in..

Batch server logs

When accessing the Batch server (Administration, Endpoints, Batch server) you will see the following information, this lists the Batch servers you have available. You should see one that shows a status of “Running”.

Click the pencil icon to view the details.

Having gone into the details you will have access to see various information.

When troubleshooting issues, you will want to review the “Activity log” (Batch controller logs) which is essentially logging of the Batch server itself. This can indicate if the batch server had any issues connecting, if its successfully running and the process ID (PID) created for the session.

This is also available through the right menu options (Controller logs).

Also available from the right list menu is a link to view Queries Management.

This link will display a list of your tasks, indicating all recent queries that have been set to run on your batch server. Each line in the Query results grid (table) is a task submitted to the batch server (released or not released). Each task has a status and is displayed using a color. The color reflects the status of the task. The standard colors are as follows:

• Green. Task currently being executed.
• Black. Task finished without error.
• Red. Task interrupted or terminated with errors.
• Blue. Task pending execution.

You will have 2 logging options,

• Each individual line has an action ellipse with a log option.

This log is specific to the task line you have selected.

• The log on the top right of the screen that shows logging of the batch server and details on all queries it has processed. Errors in this log are highlighted in green.

Syracuse logging

Syracuse logs can be found in your installed Syracuse location.

On my station its under SafeX3, SyraSrv, Syracuse, Logs, this can be different based on your install location and naming conventions but will reside in the logs folder of Syracuse.

When providing support logs to assist in troubleshooting please provide ALL logs in this folder, ideally zip the entire folder up and send it to support.

You can increase the logging level to provide additional information through Global settings, more info on that from Online Help : https://online-help.sageerpx3.com/erp/12/staticpost/global-settings/

When you have the logs a simple search on “Error” will quickly help identify potential issues, please see this blog post for additional information on error searching.

• https://communityhub.sage.com/us/sage_x3/b/sageerp_x3_product_support_blog/posts/an-easy-way-to-find-error-messages-in-syracuse-log-files

Workflow Email logs

The KB: 225924150079994, has good information and links to troubleshooting workflow emails, we will only look at the logging portion.

Logs are found in: Your X3 Dir\folders\SEED\ TMP.

1. Once you’ve located the TMP storage volume, click the action icon and then select File list (or if browsing to it in Windows Explorer, open the TMP folder).
2. Locate the proper M1xxxxx files.  If users trigger a workflow and it actually meets all the criteria, an M1xxxxxxxxx.TXT file will be created.  This file contains the information necessary for the email server to process and send an email. The existence of this file confirms 100% without any uncertainty that the workflow did its job and met all its conditions.
3. If the email server rejects the file for whatever reason, or sends it successfully, a M1xxxxxxxxx.TRA file of the same name (but different extension) will be created.
   1. If the email server sends it successfully, the TRA file will either be:
   2. Blank, as in nothing is in the file, with a zero KB size.
   3. Or it may contain some transmissions information.  But you will clearly see there are no error messages in the TRA log file.
4. If the email server rejects it for whatever reason, the TRA file will clearly tell you what the error was. Depending on the error, if it’s referencing a port for example, that means a port is being blocked or the mail server does not exist.  Search the Internet for the error to identify what the cause might be.

Web scheduling logs

There are several logs available for Web scheduling to help diagnose issues and for gathering data.

• xxx.json: D:\sedApta\SupplyChain\X3_Interface\Data
  • There will be one file record for each X3 site.  The file is re-generated after each import (total or partial).  Here you will find the most recent records for the site that have been imported into Web Scheduling from X3.

• log_file.txt:  D:\ sedApta\SupplyChain\X3_Interface\Data
  • Contains the activity of the Sage_X3_Interface service (Analytics).  This log shows the connection to the NICIM database, and the data insertion/SQL statements run as part of an Analytics import.  The newest data is written at the bottom of the log, after each import (total or partial).  If the import is successful, it will be logged as “Import Completed.”  If not, you’ll find warnings and errors in this log.

• Interface_Config.xml: D:\sedApta\SupplyChain\X3_Interface\Data
  • Not technically a log, but this file is useful when troubleshooting as it controls the connection from X3 to the X3_Interface_Service.  When dealing with Analytics import issues, the Log_Level can be changed to “DEBUG” to provide additional logging in the Log_File.txt.  Make sure to restart the X3_Interface service if changes are made to this file.

• LogCallInterfaceCustomAction.txt:  D:\sedApta\OSA\Analytics\AryosaAnalytics.Web\CustomActions
  • Connection and interface log that shows connection, inserts, and updates to NICIM database each time the custom interface runs.  Contains dates and times of each total or partial import along with the instructions passed to the NICIM database.  Parameters entered in the UI are also logged.
• Logfile—yyyy—mm—dd.log:  C:\ProgramData\sedApta\logs\analytics
  • Captures connection information and can have detailed error logging for Analytics (partial/total imports) added via log.config.
• log.config: D:\sedApta\OSA\Analytics\AryosaAnalytics.Web
  • There are several other logs available in C:\ProgramData\sedApta\ that you can make use of.  Each of these logs is controlled by a log.config like the example below— while in your sedApta installation directory (D:\sedApta\ on my test machine), just search for log.config to see all the possible options.

SEI Logs

SEI has a many different log options available, I’ll only touch on the main log.

Be sure to visit the SEI Online help page for detail info on all available logs, setup and general information. https://onlinehelp.sageenterpriseintelligence.com/Latest/en/Troubleshooting/logs.htm

BIService.log: Located in C:\Program Files\Sage\SEI Server\Server\BIServiceYYYYMMDD.log.

The BI Service log is the main log because most of the SEI components communicate with and execute actions through the BI Service.

The BI service also sends distribution results via SMTP (i.e., email) or saves them to a disk.

The BI Service log files contain SQL statements that are automatically generated for BI events and any errors that may have occurred in the Web Client, OLAP Job Service, Distribution Service and Excel Add-in. You can refer to these SQL statements if you are unsure of an executed action or in the case of an error.

A BIService.log file is created each day and up to 14 .log files are stored before being automatically deleted.

Mobile Automation logs (New ADC)

If experiencing issues with the new ADC it’s advised to increase logging to get a better understanding on what could cause the issues. This is done via the config file:

• In your X3 services "xtrem-config.yml" file (located in the "INSTALLATION BASE" directory, such as "D:\Sage\x3services") add the log entry as below.

storage:
    managedExternal: true
deploymentMode: development
logs:
    disabledForTestsx: false
    domains:
        sage/xtrem-x3-gateway/storage:
            level: verbose
        sage/xtrem-x3-gateway/web-service:
            level: verbose
        sage/xtrem-x3-sql-manager/sql:
            level: debug
        sage/xtrem-service/service:
            level: debug
        sage/xtrem-service/http:
            level: verbose

NOTE: The spacing is essential, so it should look like below (4 spaces for each indent)

• Restart X3Service windows service to ensure the change is picked up and this also cycles the X3 services log file.
• Reproduce the issue, then review the x3service log file "xtrem.server-XXX.log" (located in the "INSTALLATION BASE\logs" directory, such as "D:\Sage\x3services\logs") and also the Syracuse logs.
• Once diagnostics are completed, revert the changes and restart the X3Services windows service.

Print server logs

The log for the print server is called: AdxSrvlmp_Trace.log and is found in the temporary folder of the print server (Example: E:\Sage\SafeX3\EDTV2\EDT211\srvedit\Temp).

To activate a log file use: " /d" in the start parameters: This option is used to put the print server in DIAGNOSTIC mode to produce a file that logs the activity of the print server and of the printing processes that are launched.

• Open the Windows Services
  • Click the Start button in Windows
  • Type services.msc
  • Press ENTER
• Locate the Sage X3 print server service. It could be named similar to Safe_X3_SrvEdt_V2_EDT_DEFAULT.
• Right-click on the service and select Properties.
• Click Stop
• In the Start Parameters textbox type /d
• Click Start

Click OK

Now you are set to replicate the issue and review the logs.

That sums up my blog regarding logs and tracing. I hope you are able to get some useful information out of this and it helps with your troubleshooting.

Its always a good idea to increase the logging when investigating an issue so when you review the logs you can see as much information as possible to help identify the problem.

In most cases when increasing the logging you will want to revert that back to normal logging when you've completed your testing as increased logging would add stress to your environment and could affect resource consumption.

See you all next blog.