Protocol Fragments
File transfer source and target are specified using elements in the configuration Fragments branch.
ProtocolFragments are children of the Fragments element and in turn can have any number of child elements. Example protocol fragment elements would be the FTPFragment and the SFTPFragment.
Protocol fragment elements have descendants that specify parameters such as the authentication method, the connection type and proxy.
The first diagram shows the structure of the upper levels of the Fragments branch as represented in the XSD Schema.
3-LEVEL FROM FRAGMENTS
Protocol fragment elements are protocol specific - that is, there is a ProtocolFragments element defined in the XSD schema for each file transfer protocol. This enables the properties of each protocol to be reflected in the schema and allows dependencies and incompatibilities to be defined. A trivial example here would be that a PassiveMode element can be specified for an FTPFragment but not for an SFTPFragment.
The next diagram shows the structure of an example protocol fragment element - the FTPFragment.
3-LEVEL FROM FRAGMENTS
Calling Protocol Fragments
Any number of ProtocolFragments can be specified within a file transfer configuration and any number of fragments can be defined for a particular protocol. A particular fragment is identified by a name attribute and this attribute is referenced by a corresponding fragment reference element in the configuration Profiles branch
Operation-dependent source and target elements specify the ProtocolFragments element that is to be used. For example:
- A Copy operation requires that CopySource and CopyTarget elements are specified.
- The CopySource and CopyTarget elements in turn are used to specify CopySourceFragmentRef and CopytargetFragmentRef elements, that respectively define the Fragments to be used for each of the two parts of the operation.
3-LEVEL FROM COPY
The use of protocol fragments is described in more detail in the Configuring Protocol Fragments article.
General Comments
The advantage of this approach - which may at first seen somewhat complex - is that fragments can flexibly reused within the otherwise strict XML hierarchy and that configurations can be validated against an XSD schema. Validation means that the possibility of configuration errors is greatly reduced.
A Fragment can be used as a source or as a target within the one Configuration.
ProtocolFragments can also be referenced from other fragments:
- AlternativeFragments elements can specify a number of Fragments. These fragments will be applied in order, should, for example a server not be available. For example, it is conceivable that in some situations a less secure protocol would be tried if a secure one is not available.