ftp egress connector

FTP Egress Connector

Version: 17.07

Supported Since: 17.07

What is FTP Egress Connector?

The FTP Egress Connector can be used to send files to a remote FTP server. The connector would be able to communicate with any FTP server variant which implements the generic FTP protocol.

When sending a message out to a FTP server, the connector expects the file content to be present as the message payload and the file name to be present either as a transport header (dynamic) or as a connector configuration (static).

In order to use the FTP Egress Connector, you must first select the FTP Connector dependency from the connector list when you are creating an empty Ultra project. If you have already created a project, you can add the FTP Connector dependency via Component Registry. Select Tools → Ultra Studio → Component Registry and from the Connectors list, select the FTP Connector dependency.
ftp egress ports

Out Ports

On Exception

The message will be emitted from this out port if the processing element fails to upload the incoming message content as a file to the configured FTP location

Side Ports

Connector Operation

This port is used to connect operational elements to the Egress Connector. By default, user does not have to connect any operational element and the default no-op connector operation will be used.

Parameters

* marked fields are mandatory

Host *

Basic

Hostname or IP address of the target FTP server

Port *

Basic

Remote port on the target FTP server. Default value is 21.

Username *

Basic

Username for the FTP account that will be accessed on the server

Password *

Basic

Username for the above FTP account

File Path *

Basic

Absolute path on the FTP server for uploading files. Note that relative paths may not work.

File Name

Basic

File name to be used for the upload. If there is an original name to the file, it will be preserved if this property is not provided. In order to construct the file name, you can use message headers, message properties, additional variables set, message ID, message context ID, and message context properties in following formats respectively: @{message.headers.<name>}, @{message.properties.<name>}, @{variable.<name>}, @{message.id}, @{mc.id}, @{mc.properties.<name>}

Further, if the file name is not set and the message contains a transport header with key ultra.file.name, the value of the header will be used as the file name. Apart from that, if the message contains both ultra.file.name and ultra.file.move_timestamp_format transport headers, the file name will contain the value of the ultra.file.name header with the current timestamp prepended, formatted based on the ultra.file.move_timestamp_format.

Append Mode

Advanced

If this is enabled, the framework will append the current message payload if there is a file with same name in the destination. If this is disabled, any existing file at the destination will be overwritten by the new file.

Weight

Advanced

Weight for the Egress Connector if this Egress Connector is with a weighted Egress Load Balancer

Timeout

Advanced

Timeout in milliseconds, to be used while connecting to the remote FTP server. If the framework cannot establish a connection with the FTP server within this time period, it will be considered as a connection failure. By default, this value is 60000.

Binary Mode

Advanced

Whether to use binary mode (type I) for data transfer. Enabled by default.

Passive Mode

Advanced

Whether to use passive mode (PASV) for data transfer. Enabled by default.

Sample Use Case

Use case description

In this scenario, we need to append content from a locally generated daily journal file, into a master journal file on a remote FTP server at ftp.remote:21. The existing system writes to the local journal from 9AM until 6PM (after which the journal would be idle) each day, and our integration logic should transfer the existing local journal content to the master journal at midnight.

Implementation

First create an integration flow named ftp-to-ws, and add and configure a File Ingress Connector as follows.

ftp egress sample 1 file basic
ftp egress sample 1 file filemod
ftp egress sample 1 file scheduling

The configuration ensures that the original local journal file is either removed (after a successful transfer) or moved to a backup location (on failure, so that the failed content is not lost and can be handled separately later on), so that the local system will be able to start writing into a fresh journal file on the following day.

Then add a Logger processing element to generate a log line acknowledging the daily journal transfer, including the file name (ultra.file.name header) and transfer size (ultra.file.size header) using placeholder syntax as:

Appending @{message.headers.ultra.file.name} (@{message.headers.ultra.file.size} bytes) to upstream

ftp egress sample 2 logger

Now we are ready to transfer the journal content (message payload) into the remote FTP server in append mode. Add a FTP Egress Connector and configure it as follows.

ftp egress sample 3 basic
ftp egress sample 3 advanced

The finalized flow would resemble:

ftp egress sample flow

Now if you run the flow, and write content to a file named in the format daily_journal_<suffix>.log under the /var/log/localsystem local directory, the content will be appended to /srv/ftp/audits/journal.log on the FTP server, and the local file will either be deleted (on success) or moved to /var/log/localsystem/failed (on failure). Additionally an INFO in the Project-X runtime log will indicate the original name and size of the transferred file.

In this topic
In this topic
Contact Us