What is the ListSFTP and FetchSFTP processor pattern and how does it work?

ListSFTP and FetchSFTP implement a two-stage pattern for ingesting files from SFTP servers, separating listing from fetching. This design also appears for S3 (ListS3/FetchS3Object), Azure Blob Storage, HDFS, and local filesystems.

ListSFTP: Connects to the SFTP server and lists files in the configured remote directory (with optional recursion and filename filtering by regex). For each file found, it creates a FlowFile with zero bytes of content but rich attributes: filename, path, sftp.remote.host, sftp.remote.port, file.size, file.lastModifiedTime, etc. Uses NiFi State Management to track already-listed files, emitting only new or modified files on subsequent runs.

FetchSFTP: Receives the listing FlowFiles and for each one downloads the actual file content from the SFTP server using the attributes. The result is a FlowFile whose content is the downloaded file bytes.

Why split listing from fetching? Listing is fast (one directory read) while fetching is slow (one network transfer per file). Separating them lets you run multiple FetchSFTP processors in parallel (by increasing concurrent task count) to download many files simultaneously, while ListSFTP runs on the Primary Node at its own pace.