Date: Fri, 29 Mar 2024 15:10:58 +0000 (UTC) Message-ID: <1998911392.13045.1711725058273@change.sos-berlin.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_13044_1028062828.1711725058273" ------=_Part_13044_1028062828.1711725058273 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
When a source or target is specified for a file transfer operation a ref= erence is made to a ProtocolFragment element. ProtocolFragments= are elements in the Fragments branch of the YADE XSD Schema and can b= e thought of as a series of predefined part configurations that can be call= ed up as required for specific file transfer operations.
Protocol fragments usually form the starting point when configuring<= /em> a file transfer. Profiles, which reference protocol fragments= , can then be specified after the necessary protocol fragments have been de= fined.
Operationally, the starting point is a Profile, which then call= s the protocol fragment(s).
In the YADE XML hierarchy ProtocolFragments are children of the = Fragments element and in turn can have any number of child element= s. Example protocol fragment elements would be the FTPFragment and the SFTPFrag= ment.
Protocol fragment elements have descendants that specify connection para= meters such as the authentication method, the connection type and proxy.
The diagram below shows the fragment hierarchy required to specify a con= nection to carry out file transfer from a remote source per FTP using passw= ord authentication.
You are recommended to use the XML Editor to generate the configuration.= The editor uses the YADE parameter configuration XSD schema to guide param= eter specification.
Starting at the ProtocolFragments element, the Add child button is used to insert valid elements at each level in the hierarchy u= ntil the configuration is complete.
Note that the links behind each parameter name in the diagram lead to th= e Parameter Reference page for that element, which provides detailed= information about the parameter.
Protocol fragment elements are protocol-specific - that is, there is a&n= bsp;ProtocolFragments element defined in the XSD schema for each f= ile transfer protocol. This approach enables the properties of each protoco= l to be reflected in the schema and allows dependencies and incompatibiliti= es to be defined. A trivial example here would be that a PassiveMode elem= ent can be specified for an FTPFragment but not for an SFTPFragment.= p>
Note that protocol fragments can be used for either a transfer source or= target as required. This is described in more detail in the next section.<= /p>
Any number of ProtocolFragments can be specified within a file = transfer configuration and any number of fragments can be defined for a par= ticular protocol. A particular fragment is referenced by a name at= tribute and this attribute is referenced by a corresponding fragment refere= nce element in the configuration Profiles branch.
Operation-dependent source and target elements specify the ProtocolF= ragments element that is to be used. For example:
The following optional fragments can be specified in addition to Pro= tocolFragments:
The use of the Operations element - the only Profiles = child element whose use is required - is described in the Operation section of this manu= al.