JADE Parameter Reference - MoveSource

• Schema: MoveSourceFragmentRef, MoveSourceFragmentRef

This element references a readable fragment that is used to move files in a Move operation.

Any number of reusable Fragments elements can be configured and are distinguished by YADE based on their name attribute.

A subsequent fragment reference element points to the fragment that is used as source in the Move operation.

• Schema: FTPFragmentRef, FTPFragmentRef

This element references the fragment that is used for an FTP file transfer operation.

Any number of reusable FTPFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the FTPFragment element.

• Schema: FTPSFragmentRef, FTPSFragmentRef

This element references the fragment that is used for an FTPS file transfer operation. Any number of reusable FTPSFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the FTPSFragment element.

• Schema: HTTPFragmentRef, HTTPFragmentRef

This element references the fragment that is used for an HTTP file transfer operation. Any number of reusable HTTPFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the HTTPFragment element.

• Schema: HTTPSFragmentRef, HTTPSFragmentRef

This element references the fragment that is used for an FTPS file transfer operation. Any number of reusable HTTPSFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the HTTPSFragment element.

• Schema: LocalSource, LocalSource
• Mapping:
  • protocol

A local source is considered to be located locally to the YADE Client, i.e. in the local file system.

• Schema: SFTPFragmentRef, SFTPFragmentRef

This element references the fragment that is used for an SFTP file transfer operation. Any number of reusable SFTPFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the SFTPFragment element.

• Schema: SMBFragmentRef, SMBFragmentRef

This element references the fragment that is used for an SMB file transfer operation. Any number of reusable SMBFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the SMBFragment element.

• Schema: WebDAVFragmentRef, WebDAVFragmentRef

This element references the fragment that is used for an WebDAV file transfer operation. Any number of reusable WebDAVFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the WebDAVFragment element.

• Schema: AlternativeMoveSourceFragmentRef, AlternativeMoveSourceFragmentRef

Alternative fragements can be specified as a replacement for existing file transfer fragments in case that a connection cannot be established with those fragments.

Alternative fragments can be specified from a range of protocol fragments for use with the source of a file transfer operation without modifying files.

For each fragment type depending on the file transfer protocol in use an alternative fragment type is available.

• Schema: FTPFragmentRef, FTPFragmentRef

This element references the fragment that is used for an FTP file transfer operation.

Any number of reusable FTPFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the FTPFragment element.

• Schema: FTPSFragmentRef, FTPSFragmentRef

This element references the fragment that is used for an FTPS file transfer operation. Any number of reusable FTPSFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the FTPSFragment element.

• Schema: HTTPFragmentRef, HTTPFragmentRef

This element references the fragment that is used for an HTTP file transfer operation. Any number of reusable HTTPFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the HTTPFragment element.

• Schema: HTTPSFragmentRef, HTTPSFragmentRef

This element references the fragment that is used for an FTPS file transfer operation. Any number of reusable HTTPSFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the HTTPSFragment element.

• Schema: LocalTarget, LocalTarget
• Mapping:
  • protocol

A local target is considered to be located on the server where the YADE Client is operated, i.e. in the local file system.

• Schema: SFTPFragmentRef, SFTPFragmentRef

This element references the fragment that is used for an SFTP file transfer operation. Any number of reusable SFTPFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the SFTPFragment element.

• Schema: SMBFragmentRef, SMBFragmentRef

This element references the fragment that is used for an SMB file transfer operation. Any number of reusable SMBFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the SMBFragment element.

• Schema: WebDAVFragmentRef, WebDAVFragmentRef

This element references the fragment that is used for an WebDAV file transfer operation. Any number of reusable WebDAVFragment elements can be configured and are distinguished by YADE based on their name attribute.

The reference to a fragment is based on the value of the ref attribute of this element to the corresponding name attribute of the WebDAVFragment element.

• Schema: Directory, Directory
• Mapping:
  • dir

This parameter is used to specify a directory on one of the involved servers. Directories can be adressed using a folder structure, e.g. /folder1/folder2.

For Windows systems when used with the LocalSource parameter then a Windows path including a drive letter can be specified. For all server systems the standard syntax using can be used which includes forward slashes to separate folder names.

The directory can be set absolute or relative to the working directory, where the working directory depends on the server configuration. If for example a user "test" connects to an SFTP server then this user might have /home/test/ as a working directory. This applies to servers that use the home directory as the working directory. In this case you can use relative and absolute adressing as in

• data
• /home/test/data

• Schema: SourceFileOptions, SourceFileOptions

These options apply to the handling of files on a source server. They specify e.g. the Selection of files for Copy and Move operations.

• Schema: CheckSteadyState, CheckSteadyState
• Mapping:
  • check_steady_state_of_files

In some file transfer scenarios the recipient of a file does not know when the sender creates the file. In case of (very) large files the recipient may try to read the file before the sender has finished writing it. This can result in the recipient retrieving an incomplete file.

Including the CheckSteadyState parameter ensures that the file is checked at its reception point for completeness before starting the transfer.

Including the CheckSteadyState parameter ensures that the file is checked at its reception point for completeness before starting the transfer.

If the check of the steady state of one incoming file did not succeed successfully then no file will be transferred.

Note that this is not a very reliable approach as the recipient checks the date of last modification and the size of the file. If neither changes during a specified a period of time then the file is assumed to be complete. However, if transmission is terminated without the file being completely written, the network goes down or the processing speed of the file is slow, then the receiver will get a corrupted file.

The shorter the check interval is chosen the more likely it may happen that a file is detected as steady, although this was not yet finished writing.

• Schema: MaxFiles
• Mapping:
  • Max_Files
  • MaxFiles

This parameter specifies the maximum number of files that are considered for transfer. If additional files were available then they will be ignored.

Note that it is not possible to specify which files will be ignored should the value set for this parameter be exceeded. It therefore only makes sense to use this parameter in particular situations such as when the contents of a directory will be repeatedly polled.

• Schema: CheckIntegrityHash, CheckIntegrityHash
• Mapping:
  • check_security_hash

This parameter makes use of a checksum file that is available with the source of a file transfer. The name of the checksum file is assumed to be the same as the source file with an additional extension .md5. During file transfer the contents of the checksum file is compared with the checksum that is calculated from the transfer of the file.

When used with a jump host then integrity checking applies to source and jump host, not to the target of the transfer.

With this element being used a checksum file is expected on the source system and the integrity hash for the target file is calculated and compared with the respective integrity hash of the source file. If the hashes are not equal then the file transfer will be rolled back. If the checksum file on the source system is missing then this will be reported as an information but will not affect the transfer of files.