Transfer CFT provides a high performance, multi-platform, non-intrusive file transfer service that you can implement as part of a managed file solution. Transfer CFT uses the concept of logical names to allow platforms and applications to run independently from one another, allowing flexibility for continued growth.

This section begins by introducing a high level overview of the product architecture and key concepts to help you understand how Transfer CFT works as follows:

How Transfer CFT works

Each data transfer involves a local and a remote file transfer service. The two services interact using a file transfer protocol. Transfer CFT provides file transfer services that use PeSIT, typically over TCP/IP.

The party that initiates a communication session is referred to as the requester, and the other is the server. The requester controls the communication session, regardless of the data flow direction.

Only logical objects are exchanged between applications to provide higher security and more flexibility. What this means is that the file's physical characteristics, such as the name or its directory, are defined locally and not exchanged with the partner.

The primary goal of Transfer CFT is to transfer files, but there are other value added services, such as:

  • Synchronization and automatic restart of transfers: The transfers can be configured with synchronization points that guarantees the transfer delivery without downtime.
  • Transfer metadata: Along with the transfer itself, Transfer CFT also sends protocol metadata that corresponds to all information regarding the transfer. This metadata can be used, parsed, transmitted, controlled, and so on.
  • Scheduling: Transfer CFT can schedule periodic transfers.
  • Folder monitoring: Transfer CFT can trigger transfers when files are deposited in a directory.
  • Store and Forward: Transfer CFT can push a file to a final receiver that is only known by certain intermediary partners.
  • Replies: Transfer CFT can provide acknowledgments (both positive and negative).
  • Additional services: Security, access management, etc.
  • Processing: You can create pre or post-process procedures depending on predefined conditions (such as if the transfer is successful, etc.).

Architectural overview

You can seamlessly integrate Transfer CFT into either your A2A or A2B architecture model. Transfer CFT is placed in front of each back-end application, which triggers transfers to other applications. Each of these transfers can be automated, scheduled, and triggered by applications or systems.

A Transfer CFT implementation comprises some or all of the following:

  • Transfer CFT: Processes executables that start local transfer services. Local and remote file transfer services are set up in the execution environment, which also manages initial and ongoing configuration attributes.
  • Batch utilities: Enable you to perform Transfer CFT functions and requests.
  • APIs and Web Services: Enable you to write programs that work as an interface with Transfer CFT.
  • UIs: Enable easy operations via a user friendly interface (Central Governance and applet).
Note Transfer CFT is available on a variety of platforms, each of which has the same internal architecture, commands and interfaces, meaning that regardless of the platform all services are the same.

About the PeSIT protocol

Transfer CFT uses PeSIT as a file transfer protocol to read and write files between systems using a connection over a network. To avoid differences between the file management systems, PeSIT takes advantage of a virtual file concept. This provides a common file organization model that is suitable for all systems types, that is, file transfers can occur between heterogeneous or homogeneous platforms.

Example: Each transfer is a managed translation between physical files and virtual files transferred by the protocol.

Transfer CFT includes related technical parameters along with any the transfer. These parameters can include information on the file format and how to process the file on reception.

Additionally, Transfer CFT offers several methods for customizing transfers such as sending groups of files or sending to multiple destinations. Refer to Transfer concepts for a description of the available Transfer CFT transfer options.

Note To exchange files between various operating system, Transfer CFT must be installed on each platform.

Transfer CFT modes

To understand the possible Transfer CFT modes, it helps to understand basic PeSIT protocol connection steps. In simple terms, one party sends data and the other party receives it. However, the sending party may or may not be the initiator for the data flow.

  1. The requester initiates a connection using a connection request. The party that receives this request is the server. At this point you do not know if the requester is going to send or receive the data; they are simply requesting a connection.

    • Transfer requests originating from a local Transfer CFT are termed requester mode. Frequently these transfer requests are in the form of batch commands or an interactive application.
    • Transfer requests originating from a remote Transfer CFT are termed server mode.
  3. The sender is the source of the data and the receiver is the target.

These two modes lead to the following transfer owner combination pairs:

Flow Connection Details
Sender Requester The source Transfer CFT initiates the connection and sends the file to the target Transfer CFT
Receiver Server The target Transfer CFT receives the file sent by the sender
Sender Server The source Transfer CFT makes a file available for the target Transfer CFT to download (this file)
Receiver Requester The target Transfer CFT gets the file from the remote Transfer CFT

Example: The source Transfer CFT is always the sender, and the target is always the receiver.


Transfer monitoring

Transfer CFT monitoring features include log, catalog, and metadata functionalities.

Example: The following diagram illustrates the interaction between the transfer processing and the monitoring features.


Transfer CFT records all events related to transfer operations in a dedicated file: these are called log messages. These records list events and codes that are related to transfer operations. You can use this information to troubleshoot and monitor session activity. You can modify the default log values to, for example, use a more precise timestamp, rotate log files at certain times each day, or change the default number of entries in the log file.

In Transfer CFT this is the CFTLOG object. See also Housekeeping for log files.


Transfer CFT records all file transfers in its local database, the catalog. This information includes the request and indicates the status of each transfer such as pending, in progress, aborted or completed successfully.

In Transfer CFT this is the CFTCAT object. See also Housekeeping for the catalog.


Transfer CFT records metadata on both the transfers and the product's health. It also sends protocol metadata that corresponds to all information regarding the transfer. Each of these metadata can be used, parsed, transmitted, controlled, etc,. for end of transfer procedures, and so on.

In the catalog details for each transfer, you can see the value for each type of metadata.

Integrate with applications

You can integrate Transfer CFT with API, web services, end of transfer procedures, and preprocessing procedures for your data flows.

Application integration implies:

  • Seamless integration with existing processes/applications
  • Transfer requests via CFTUTIL, scripts, APIs, etc.
  • End of transfer processing


For an example of a transfer request, see Example application transfer request. For information on types of data that you can transfer, go to Transfer types.

End-to-end processing and acknowledgments

Transfer CFT features both transfer acknowledgments (ACK) and negative acknowledgments (NACK).

  • The Transfer CFT catalog provides a technical acknowledgement for each transfer. A technical acknowledgement provides the current transfer status (such as In Progress) and the resulting status of the transfer (successful, not successful, in hold,…). This in and of itself is proof that a file was transferred.
  • Transfer CFT can also provide a functional acknowledgement for each transfer. A functional acknowledgement provides the user with additional proof that the file was not only received, it was correctly integrated (consumed or processed) by the application. This additional level of acknowledgement creates end-to-end monitoring.
    • Positive acknowledgments are sent by the back-end application that integrated the received file. If the file was successfully integrated by the end of transfer procedure, the application sends a positive ACK.
    • Negative acknowledgments are sent by a back-end application that did not, for some reason, integrate or process the received file.  If the file was not successfully integrated by the end of transfer procedure, the application sends a [negative] NACK.

Access management

Central Governance provides access management, which consists of a policy that allows users to perform actions on Transfer CFT.


  • Actions on transfers
  • Actions on Transfer CFT 


  • Secure data

Related Links