Technical Blog Post
WMQ MFT / FTE Role Based Guidance
WebSphere MQ Managed File Transfer and File Transfer Edition Role Based Guidance
WebSphere MQ Managed File Transfer (previously known as File Transfer Edition) transfers files between systems in a managed and auditable way, regardless of file size or the operating systems used. It leverages your existing WebSphere MQ (WMQ) infrastructure and offers an out-of-the-box solution without having to program your own.
This document is intended as a launching point to get you started. It offers a collection of insightful links organized by role.
Planning your FTE/MFT environment
Anyone looking to get their feet wet with managed file transfer solutions provided by both WebSphere MQ File Transfer Edition (WMQFTE / FTE) and the newer WebSphere MQ Managed File Transfer (WMQMFT / MFT) feature, should spend a good amount of time reviewing the pages of the IBM Redbooks publication "Getting Started with WebSphere MQ File Transfer Edition" - it offers what is needed to intelligently outlay the type of managed file transfer environment best suited for the business need.
Other useful links to get you started:
- WebSphere MQ File Transfer Edition topology overview
- WebSphere MQ File Transfer Edition product options
- How does WebSphere MQ File Transfer Edition work?
A new installation of WMQFTE / MFT requires some planning and thought. A WMQ infrastructure must exist and be in working order before WMQFTE agents are deployed.
- Quick 2 minute YouTube video introducing WMQFTE:
WebSphere MQ File Transfer Edition Two Minute Introduction
- WMQFTE highlights and overview, why use it, and how to install and setup:
Webcast replay: WebSphere MQ File Transfer Edition (FTE) - Basic Step-by-Step Configuration and Setup
- Diagnose errors returned from the WMQFTE installation:
Troubleshooting the installer
Configuration considerations abound when it comes to managed file transfer. Think of WMQ FTE or MFT as any other WMQ client application, it needs to connect to a queue manager. The client in this case, agents, can connect in either bindings or client transport modes. They must connect with their agent queue manager. Likewise, the coordination, agent and command queue managers must also be able to communicate with one another, which is accomplished by clustering them together or using SDR/RCVR (Sender/Receiver) channels. Here are some useful configuration references:
Here are some suggestions to improve the performance of WMQ FTE / MFT agents:
- Increase the agentChunkSize. To set this for each agent involved in the managed file transfers, please add the following line to their agent.properties file. For example, to set the chunk size to 512KB add the line:
Making this change effectively doubles the default chunk size and means that the agents will break down the files into larger chunks; needing to send less pieces than before. The chunk size can be further increased on reliable networks to improve performance.
- Increase the agentCheckpointInterval from 1 to 2. This property determines the frequency at which the agent takes a check point. The default is to take a checkpoint every 1 complete frames. The agentFrameSize by default is calculated by multiplying the number of windows in each frame (default 5) and number of chunks in each windows (default 10). So by increasing the agentChunkSize (see number 1 above) to 512KB, the default check point is every 25MB of data sent. Increasing agentCheckpointInterval from 1 to 2, means that this check point will occur every 50MB of data sent.
So on a reliable network, there is little reason not to increase this property in both agent.properties files; on the source and destination agents involved in the transfer. To do this, add the following line to the agent.properties file:
- Add the following tuning options to your installation.properties file:
The commandMessagePriority property allows us to increase the priority by which agents handle internal command messages as opposed to external ones. Increasing this will improve performance; especially for existing transfers that might be in a recovering state.
The enableFunctionalFixPack property is specific to WMQ v18.104.22.168 or above and enables performance related features put into the MFT product. This includes optimizing transfers with single files that have a deep directory structure.
Debugging issues in WMQFTE or MFT should start with the agents and then progress to the infrastructure: the WMQ QMgrs.
- The first thing to look for are errors written to the Agent’s event log; also known as the output0.log file. Many times a trace is needed to help determine what is going wrong. Tracing instructions are available in this WMQ MFT document: Generating IBM MQ managed file transfer trace on Linux, UNIX, Windows, IBM i and z/OS
- If your agent is suffering out of memory issues, please review the recommendation to increase the memory allocation to the JRE. For example, to increase the max memory allocated to the agent’s JRE to 1MB, set the following environment variable:
For more detail on this environment variable and how to set the ulimit on UNIX® systems see: Hints and tips for using WebSphere MQ File Transfer Edition
- If agents are not listed by the fteListAgent command, please use the flowchart in this section to find your solution: What to do if your agent is not listed by the fteListAgents command
- If your agent becomes UNREACHABLE, see: What to do if the fteListAgents command shows an agent status of UNREACHABLE
- For transfers that go into a recovering state or seem to stall, please add the following two properties to the agent.properties file to get more information:
The logCapture properties will create a new file in the logs directory called capture0.log and will contain all the transfer log data that is also published to the SYSTEM.FTE topic. Enabling logCapture will create a log file showing what is happening to the transfer at the time of the issue. If the issue occurs again then knowing the state transitions of the transfer will be beneficial to any investigation.
The logTransferRecovery property will result in diagnostic events to be reported to the agent's event log (i.e. output0.log) whenever a transfer event log whenever a transfer enters recovery and the reason why it has done so.