Store and forward mode

The Transfer CFT store and forward mode enables you to route files from one computer to another via one or more intermediate relays (computers or communication sites). For example, when sending a file from computer A to computer C, where A and C are either not directly connected or have a connection problem, the file is routed via computer B.

In the same way, a file to be sent to clients that are dependent on the final receiver may transmit via intermediate systems and be sent on. This transfer is accomplished using the same protocol from one end to another.

Note This document describes the relay process as it relates to Transfer CFT. You can perform relay transfers using other Axway products as the intermediary site.

The following illustration features 3 Transfer CFTs, where the protocol may be the same or different between relay points:

  • Source [Initial Sender A]
  • Relay [Store and Forward B]
  • Target [Final Receiver C]

Routing a transfer via a relay

Implementing a relay

To implement a relay in conjunction with Central Governance:

  1. Create the flow as described in the Central Governance User Guide.
  2. In the SEND command include at a minimum:
    • The name of the final receiver, for example TARGET_APPLICATION.
    • The name of the flow, for example TEST_RELAY.
    • The file to be transferred, for example report.
    cftutil send part=target_application, idf=test_relay, fname=report
  3. Optionally you can configure target post-processing to automatically send a reply.
  4. cftutil send type=reply, part=&part, idm=idmr, idt=&idt, msg="Received file successfully."

    cftutil end part=&part,idt=&idt

Tip   You can use the script delivered with Transfer CFT in the runtime/exec directory/BIN_re.cmd as a basis for your ACK reply from the target application.
Note When viewing the final transfer in the CG View Cycle Graph, you see the number of Transfer CFTs involved minus 1 entries and that these entries are linked. In the example above, there would be two entries for the single "report" transfer.


  • You cannot use a distribution list on the relay site, that is, when this site is being used as part of a store and forward flow.
  • Transfer CFT store and forward mode is only possible from a requester/sender (write transfers only, not read).

Transfer routing

The following routing transfer concepts are described in this section:

  • The protocol used to implement the store and forward
  • The types of store and forward managed by the Transfer CFT

The processing possibilities using the store and forward site are detailed in the next topic, Store and forward processing.

Protocols to implement store and forward mode

In order to route a file transfer, you must identify the partners involved in the transfer: the initial sender and final receiver of the transfer.

Transfer CFT supports the following protocols for store and forward operations:

  • PeSIT E
  • PeSIT D CFT profile
  • Odette

For these protocol, the objects transferred can be files or messages, in write mode only, the sender requester mode.

These three protocols manage the acknowledgement messages following the reception of a file. See the SEND TYPE = REPLY command. The PeSIT profile protocol also manages the sending of messages. See the SEND TYPE = MESSAGE command.

Store and forward types

Three types of store and forward operations are possible on the initial sending computer:

  • Backup store and forward: After unsuccessfully attempting to connect to a final file receiver (the call retry attempts have expired), Transfer CFT forwards the file to an intermediary site as a backup.
  • Voluntary store and forward: For a given final receiver, the Transfer CFT immediately stores and forwards the file.
  • Forced store and forward: For a given final receiver, Transfer CFT routes a file from the sender to the first intermediary partner. Each site only knows the next (intermediary) partner. When using this mode, the final destination does not actually have to be configured in the source Transfer CFT configuration.

Store and forward mode processing

The processing possibilities for a store and forward site depend on the value of the COMMUT parameter in the CFTPART object. This parameter is associated with the sending partner that is defined on the store and forward site.

Depending on the value of this parameter, the processing performed by the Transfer CFT on the store and forward site is as follows:

  • COMMUT = NO: the transfer is refused, because the partner is not able to perform the store and forward operation
  • COMMUT = YES (default): the file is immediately sent to the partner that the received file is intended for

This mode is known as STORE and FORWARD. It is standardized within the framework of the PeSIT E and Odette protocols. It is also used in the PeSIT D CFT protocol. See also, Store and forward (concepts).

  • If COMMUT= SERVER: the file received is processed by the store and forward site before being sent on; the sending on of the file to the recipient is at the initiative of the store and forward site

This store and forward mode may be used where the store and forward site is an added value network server, known as Store and forward by a VAN server.

  • If COMMUT = PART: the file received is immediately sent on to the target partner

The following figure shows the processing possibilities on the store and forward site according to the value of COMMUT.

Processing on the store and forward site

Processing on store and forward sites

On the store and forward site

During the transfer of the file to be forwarded, the Transfer CFT does not activate an end of transfer procedure or an error procedure.

The transfer IDF is set to the value COMMUT: a command CFTRECV ID = COMMUT must consequently be defined on this site. The transfer is in fact saved in the catalog under the IDF = COMMUT file identifier.

When sending the file on, the compression factor may be transformed as a function of the parameter settings of the parties (sender, store and forward site, receiver) according to the values of the RCOMP/SCOMP parameters of the corresponding CFTPROT commands. No translation is, however, performed.

The file created on the store and forward site is "temporary" and is automatically deleted by Transfer CFT once it has been correctly sent to the next recipient (or to the next intermediate computer if applicable).

On the final receiver site

Transfer CFT receives the following application parameters, conveyed without modification from the initial sender:

  • IDT
  • Received file characteristics (NTYPE, NBLKSIZE, NLRECL for example)
  • File date and time (FDATE, FTIME without the hundredths of seconds)

The physical file name on the receiving site can be specified by the initial sender, through the SEND PART = C, NFNAME = filename command, if the recipient in question accepts open mode operation. The store and forward site is not involved in this mechanism.

On completion of file, or message, reception an acknowledgement message (SEND TYPE = REPLY) can be sent to the initial sender.

On the initial sender and final receiver

On completion of transfer, or in the event of error, Transfer CFT offers the possibility of executing procedures.

The usual symbolic variables for these types of procedures may be used.

Processing possibilities in the store and forward mode

Store and forward processing by a VAN server

On the store and forward VAN server (Value Added Network)

On completion of file reception, Transfer CFT does not immediately forward the file. User processing may first be performed on the file on the Value Added Network (VAN server). In particular, Transfer CFT activates the end of transfer procedure if one was defined by the user.

The IDF of the transfer received is deduced from the NIDF sent by the sender, in accordance with the usual mechanisms.

The store and forward site (VAN server) is responsible for forwarding the file to the final receiver. This may, for example, be accomplished during the end of transfer procedure, after the associated processing and checks. The file is forwarded in accordance with the usual mechanism using the SEND command (coupled with a CFTSEND command). The SPART parameter of the SEND command sets the value of the sender NSPART parameter to the value of the INITIAL sender of the file (refer to the SEND command).

Instead of returning the file, the store and forward site (VAN server) can make the file available to the final receiver (SEND command ... , STATE = HOLD).

The final receiver takes the file:

  • Either after sending the CD in ODETTE protocol
  • Or through a receive command (RECV) for the other protocols

If the final recipient requests the reception of the file, the following must be indicated as a partner in the RECV command:

  • The store and forward site in ODETTE protocol
  • The initial sender in PeSIT protocol

The difference lies in the type of protocols.

Related Links