Inbound Transports provide a connection to a location that you can retrieve files from.

Transports are typically used in business-to-business transactions where data files have to be transferred from one business to the other, although other Transport scenarios are supported.

You configure the Inbound Transport with the appropriate details for connecting to the source location and retrieving any files that match your requirements. The Inbound Transport will always activate with a particular File Connection, and it is the properties of this File Connection that determine the filter for matching files.

Inbound Transports are assigned to Actions. You can then provide the schedule upon which the Inbound Transport checks the remote server or service for new files. Commonly, an Action using an Inbound Transport will be set to Monitor for incoming files, and the Inbound Transport will be scheduled to run every few minutes or hours. The File Connection that has been set on the Action for monitoring is the one used to filter the matching files on the Inbound Transports remote location.

Many of the Transport types are based around industry-standard protocols.

These protocols vary in the security and reliability that they offer - some allow encryption of data, while some provide more rigorous proof-of-delivery features.

Basic file transfers can be achieved by sending data files as attachments to email messages. Files can be retrieved from an email account using a POP or IMAP Transport.

Access to the messages is controlled by the server and the protocols, and the data can be encrypted during retrieval. However, there is almost no control over what messages are received into the email account (e.g. spam), and inwards messages are not encrypted. One of the disadvantages of using the email protocols is that messages may include such things as company logos, which appear to be attachments but are not the data file attachments that we are wanting to work with.

If inwards controls such as spam filters are in place, then there is a risk that valid messages will be filtered out and will not be available to Statelake.

Inbound messages to an email account can be shared across multiple Trading Partners and this may cause a bottleneck when trying to identify which message is which. In many such cases, a Statelake File Router action step within the Action can be configured to help manage the situation.

File Transfer Protocol, or FTP, offers more control over the transfer of files.

If an FTP account has been set up with a password, and if encryption is used, then file transfers are protected from initial posting through to retrieval onto your Statelake server. The server would not be open to unsolicited files. An FTP server can have multiple accounts, and files can be placed into sub-directories if required.

If the FTP server is hosted away from your Statelake server, then an FTP Transport can be used to retrieve files. If you are hosting the FTP server, and files are being uploaded to your server, and if Statelake has access to the sub-directories on your FTP server, then a LAN Transport can be used to transfer the files across to Statelake, because the file locations are now essentially local to Statelake.

The other Statelake Transport types are not used as often, but they allow your configuration to fetch files from a variety of sources if the need arises.