FME Flow Debugging Toolbox: System Tools

Introduction

Other applications and the environment can interfere and cause failures or unexpected behaviour in FME Flow. Investigating the FME Flow log files is still the best first step, as they still often contain relevant errors. However, other system and application tools can provide additional or more detailed information. 

This article contains suggestions for using third-party tools for troubleshooting issues affecting FME Flow and is best used for general investigation and diagnostics. Search keywords and errors on FME Community to find resources. Make sure to review the complete list of FME Flow Troubleshooting Guides when you identify the source of the issue. 

Debugging Disclaimer

Before you begin troubleshooting, carefully consider which tool will be most effective for solving the problem you are encountering in FME Flow. Not every tool or strategy will be useful or relevant to your issue. However, any progress is useful since troubleshooting is often a process of elimination.

The following sections may provide example directions for using each tool, but availability and instructions may differ between operating systems, deployment types, software versions, and other system factors. 

Always use caution or contact your FME Flow administrator when making any changes to your installation. 
 

Monitoring FME Flow System

A bird's-eye view of FME Flow activity can be found and customized from the System Events page. Additionally, readiness and liveness can be polled with the FME Flow REST API health check request. 
 

Monitoring FME Flow Services and Processes

FME Flow runs as a collection of services and processes. An FME administrator may review system configurations when problems arise after a new installation, after changes to the installation or environment, or failure to find a resource. You must have access to the machine that FME Flow is installed on in order to view these settings. 

The following instructions are for FME Flow installed on Microsoft Windows OS. If FME Flow is installed on another operating system, please adapt the steps by consulting the FME Flow Administrator documentation.

Windows Services

Each FME Flow component runs as a service. By default, each service runs under a ‘Local System’ account. Frequently, FME administrators change this account to a system account with network permissions in order to access files, licensing, or applications on other machines.

Services can be found from Task Manager > Services > Open Services…



The FME Flow Core, Engines, and Application services’ “Log On As” account has been updated to a system account, ‘fmeserveradmin’.

If you suspect that a job is failing because an Engine can't find a dataset, review Testing Account Permissions for FME Engine Service. 
 

Windows Processes

FME Flow requires a number of processes (“executable files”) to be running in order to function properly. See FME Flow Processes documentation for a complete list. On Windows, a detailed list of processes can be found by command line Windows Task Manager > Details.


Most FME Flow processes begin with the prefix “FME”, but there are some exceptions. Even though FME Server has been rebranded to FME Flow, the process name is still FMEServer.exe. 
 

Monitoring FME Flow Performance

Symptoms of performance issues in FME Flow may include memory-related warnings or errors in the FME Flow logs, a job log that ends before the translation is finished, poor responsiveness, slow loading, or “lagginess” while using FME Flow from the browser. 

For a live evaluation of system resources, reference the system’s performance application. In Windows, start with Windows Task Manager. With the Performance tab open, reproduce the behaviour in FME Flow while monitoring the CPU and Memory activity.

Windows Task Manager recorded CPU usage reaching 100% while this job was running, an indication that FME Flow has insufficient resources.

Windows Resource Monitor provides an even more detailed view of system performance, including which processes are consuming the most resources. This can pinpoint which system process is consuming the most resources, whether it is FME Flow or another application. 


Resource Monitor records how many resources each application process is consuming. 

If you find that performance is an issue on your FME Flow, please review Performance Tuning or Host System Sizing to optimize your workflows. 

Developer Tools

Developer Tools (“DevTools”) are included with most browsers and can be used for investigating issues with the FME Flow web application. For example, unexpected behaviour or results after clicking a button, loading a page, or submitting data while using FME Flow in a browser. With Developer Tools, you might find a specific error message or key information for solving the issue. 

TIP: Errors found in Developer Tools are often also recorded in the FME Flow system logs, inside the “tomcat” folder.
 

How to Use Developer Tools (Google Chrome)

1. Navigate to the FME Flow web page where the error occurs.
2. Right-click anywhere on the page and select Inspect. Developer Tools will open and dock in the browser window.  
3. From the top menu bar, select the Network tab. 
4. Reproduce the error on the FME Flow webpage, e.g. performing the action or reloading the page. 
5. All requests are logged to the network log. Errors are recorded in the network log as red entries. Select an error to view more details. 

The Network logs have tabs to organize the request to FME Flow and response from FME Flow. Notable sections include:

• The Headers section has the initial request information sent to FME Flow (URL, Method, Status Code, Headers etc.) and FME Flow's response headers.
• The Response section has the JSON information sent back from FME Flow. Check this tab for error messages.

To share the Network log with others, use the “Export Har...” arrow button to export a HAR file to your desktop. 


The Export button in Developer tools. In Firefox it is Save All as Har. 

HAR files are JSON formatted and can be opened in a simple text editor or imported into another application, like Google HAR Analyzer or Postman. 
 

Command Line

A computer’s command line interface is most often used by FME administrators to find out if another application is occupying a port required by an FME Flow service. Experienced users may also use it to administer the FME Flow Console. 

Windows Terminal

Terminal is the command line interface for Microsoft Windows OS that can be accessed through Applications.

1. To retrieve the process number (PID) of the process using a port open Windows Command Prompt and run:

netstat -ano | find "<port>"

2. The PID number is returned in the final column. To retrieve the service name associated with this PID run:

tasklist /fi "pid eq <PID>"

The first command finds PID 4782 on port 7069. The second command finds that PID 4782 is occupied by the FMEConnection.exe process. 

TIP: An application PID can also be found from Windows Task Manager > Services

If the port is occupied by another application, please review FME Flow Can't Connect to Core or Communicate with Host Due to Ports Already in Use by AnyDesk Application for resolutions.

Operating System Logs

Operating System (OS) messaging may help administrators diagnose issues running FME Flow and its components on a machine. Crashes, start-up or shut-down failures, and application conflicts are examples of problems that may be explained by OS events. 

Windows Event Viewer

In Windows, the Event Viewer records warnings, errors, and information about all system and application processes running on the OS. Not all events will be related to FME Flow, so try to find OS events occurring at roughly the same time as the issue is observed.
 

 

Third-Party Application Logs

Issues may arise when FME Flow interacts with third-party applications, such as databases or web servers. General errors are usually returned to the FME Flow logs, but sometimes more information can be found in the other application’s logging services.
Examples: 

• Database configurations can prevent FME Flow from performing certain actions, such as restricting the number of active cursors or locking tables during transactions. Consult with your database administrator to investigate these logs for more information.
• Security software, like port scanners, firewalls, and proxies, can interfere with FME Flow functionality. These applications will sometimes log information about the processes they are blocking or restricting.
• Web servers typically return an error to a job log if requests are failing due to limitations, authorization, or other restrictions. However, if the error is unclear or absent, a web administrator may be able to review these logs. 

Third-Party Web Services

If your workflows are failing to make a request or connect to a web service, like an API, the first step is to locate the error code and message returned to the job log. If the messaging is unclear, enable debug logging and rerun the translation to record more information. 

Find the error in the web service documentation to ensure that all required parameters are included and formatted correctly inside the request. If the web service documentation is insufficient, reference Common Status Codes. 

Testing Web and Database Failures

It is important to confirm if a web or database request failure is isolated to FME Flow, FME Workbench, or from the computer/network that the workflow is running from.
 
Identify the origin of the problem by making the request from different accounts, platforms (e.g. Workbench), on different machines, and from other applications (e.g. Postman).
 

Additional Resources

• Review the FME Flow Troubleshooting Guides for common questions and solutions
• Follow along with Debugging for Workspaces for troubleshooting strategies and methodology.  
• Search the FME Community for keywords related to your problem
• Contact Safe Software Support and include any logs, screenshots, or information captured while troubleshooting.