Transferring between two different MFT topologies

Managed File Transfer (MFT) agents can only perform managed transfers between other agents in the same topology. However, if you have multiple topologies, it can be useful to transfer data between them. The following text provides some high level guidance on how to do this.

Here is a diagram that shows two different topologies:

Figure 1. AGENT1 and AGENT2 are part of a topology in the Production environment, and AGENT3 and AGENT4 are part of the Development environment topology.
Diagram showing AGENT1 and AGENT2 as part of a topology in the Production environment, and AGENT3 and AGENT4 as part of the Development environment topology.

The Production topology is separate from the Development topology. This means that is not possible for the agents in Production to directly participate in managed transfers with the agents in the Development environment (for example, AGENT2 cannot perform a managed transfer to AGENT3). To transfer data between the environments, you can use either a shared file system, or file-to-message and message-to-file transfers.

Transferring data using a shared file system

In this solution, the agents in both topologies have access to the same shared file system.

An agent in one topology acts as the destination agent for a managed transfer and writes a file to a known location on the file system. Another agent in the second topology uses a resource monitor or a scheduled transfer to detect when a file appears in that location, and then processes it.

Figure 2. Here, AGENT2 is the destination agent for a managed transfer running in the Production Environment topology, and writes a file to a location on the shared file system. A resource monitor running inside of AGENT3 polls that location. When it detects the file written by AGENT2, it submits a managed transfer request to AGENT3 to process it and bring it into the Development Environment topology.
Diagram showing AGENT2 as the destination agent for a managed transfer running in the Production Environment topology, and writes a file to a location on the shared file system. A resource monitor running inside of AGENT3 polls that location. When it detects the file written by AGENT2, it submits a managed transfer request to AGENT3 to process it and bring it into the Development Environment topology.

Note that the shared file system should be reliable, to ensure that data is not lost.

Transferring data using message-to-file and file-to-message transfers

An alternative approach is to use a gateway queue manager in between the two topologies. This queue manager is connected to agent queue managers in the topologies using sender and receiver channels, to allow data to pass between the two.

An agent in one of the topologies performs a file-to-message transfer, to write data to a remote queue. The message is then routed through the gateway queue manager to a local queue on a queue manager in the other topology. An agent in that topology then performs a message-to-file transfer to get the message and process it.

Figure 3. Here, AGENT2 is connected to its agent queue manager AGENTQM-PROD and performs a file-to-message transfer to write a message to a queue called Q1. Q1 is a remote queue, and so the message gets routed via the Gateway Queue Manager and sender/receiver channels to the local queue Q1 on the queue manager AGENTQM-DEV. AGENT3 then performs a message-to-file transfer to get the message and bring it into the Development Environment topology.
Diagram showing AGENT2 connected to its agent queue manager AGENTQM-PROD and performs a file-to-message transfer to write a message to a queue called Q1. Q1 is a remote queue, and so the message gets routed through the Gateway Queue Manager and sender/receiver channels to the local queue Q1 on the queue manager AGENTQM-DEV. AGENT3 then performs a message-to-file transfer to get the message and bring it into the Development Environment topology.

This solution uses standard IBM® MQ networking to transfer messages from one topology to another via the gateway queue manager. This means that if a channel between the gateway queue manager and one of the agent queue managers is unavailable for some reason, messages might get stuck and not arrive on the destination queue. In this situation, you should check the channels to ensure that they are all running.