You use transferFile to perform a file transfer. transferFile starts the file transfer and waits inside ftscript for the end of the file transfer.
The file transfer itself can be restarted.
If you specify remoteSuccessScript (see section “remoteSuccessScript”) or remoteFailureScript (see section “remoteFailureScript”) then the corresponding script is subsequently run on the remote computer.
For local scripts, you should use faulthandlers (see section “faulthandler”) or executeScript (see section “executeScript”). For an example, see "transferFile".
Types of file transfer
You use transferFile to transfer files as follows:
File transfers from "remote" to "local" (fromRemoteFile toLocalFile)
File transfers from "local" to "remote" (fromLocalFile toRemoteFile)
File transfers from "remote" to "remote" can be accomplished by means of two sequential transferFile activities, e.g in a sequence activity:
File transfer from "remote" to "localTmp"
(fromRemoteFile toLocalTmpFile)File transfer from "localTmp" to "remote"
(fromLocalTmpFile toRemoteFile)
Restrictions
After de-referencing, fromRemoteFile and toRemoteFile must possess a partner specification.
The elements fromLocalFile and toLocalFile must not possess any partner specification after de-referencing.
You cannot use transferFile to perform any file transfers from "local" to "local".
To perform file transfers from "local" to "local", you must use a corresponding script (copy) or specify one of the two files as "remote" and specify the local computer as the partner (specify transferAdmission).
Format
|
Attributes
Name | Value | Meaning |
|
| The default value is none. The file is not compressed. |
|
| The default value is replace. If the file exists then it is overwritten. If the file does not exist, it is created. |
| | The default value is false. The file is transferred as standard. |
|
| The default value is no. |
Examples
1. File transfer with remoteSuccessScript / remoteFailureScript
|
The file bin.mp3 is transferred from the partner remote to the local file bin.mp3. The file status.txt is then created with the following contents:
if transfer is OK
everything ok |
if an error occurs
something failed |
If errors occur during the compilation of the file status.txt then the script is aborted.
2. File transfer from "remote" to "remote"
|
In the example, the file data.txt is first copied from the partner remote1 to a temporary file. The temporary file is given an internal name. The suffix of the temporary file corresponds to the suffix of the associated fromRemoteFile (here *.txt).
Conversion is performed using autoDataSpec charPattern for character symbols because the filename suffix corresponds to the pattern .txt (see section “autoDataSpec”). If the local system is a Windows system then the line ends are converted accordingly.
When the temporary file is transferred to the remote system remote2, the autoDataSpec settings made when the temporary file was created are taken over. They are inherited as well as maxRecSize and the data properties of the fromRemoteFile element. If the local system is a Windows system then the data is not converted on the second transfer. In the case of a local Unix system, the reverse would be true. When the transfer to the local system is performed, no data is converted. Instead, the data is converted on the subsequent transfer to the remote system.
3. Use of faulthandler and executeScript for local scripts
faulthandler (see section “faulthandler”) corresponds to the localFailureScript, and the executeScript, which directly follows transferFile (see section “executeScript”) corresponds to the localSuccessScript.
You can activate a transferFile request with local*Script as indicated in the example below:
...
<sequence>
<context>
<faulthandler>
<default>
<executeScript>
.... localFailureScript...
</executeScript>
</default>
</faulthandler>
</context>
<transferFile>
....
</transferFile>
<executeScript>
... localSuccessScript...
</executeScript>
<sequence>
...
This sequence can also be located in a parallel or foreach - parallel statement.