Migration Guide from SFTP V2 (Deprecated) to SFTP (new) Connector

Differences between versions

General differences between SFTP V2 (Deprecated) and SFTP (new) connectors. The following table summarizes the general differences between SFTP V2 (Deprecated) and SFTP (new) across various feature areas. This guide is also intended to go over the details and considerations regarding the differences for Connection Configuration, New Advanced Configuration, and Operations.

Feature Area	SFTP V2 (Deprecated)	SFTP (new)	Key Differences (Not supported in V2)
Configuration	SFTP V2 (version 14) supports Jsch library v0.1.55 encryption methods. For more information, see this changelog. SFTP V2 (version 16) supports Jsch library v0.1.58 encryption methods. For more information, see this changelog.	Default supported Jsch library v0.2.19 encryption methods with the ability to override through advanced configuration. For more information, see this changelog.	- Modern key exchange and cipher supported, such as Edwards-curve Digital Signature - Ed25519. - Ability to override Jsch library defaults.
Operations	LISTEN, CREATE, GET, QUERY, UPSERT, DELETE, LIST	Listen, Write, Read, Delete, List	- User-friendly Operation Names - UPSERT operation was merged with Write (formerly CREATE) operation - QUERY operation was merged with List (formerly LIST) operation
Authentication	Username and password, Key Authentication File, Key Authentication Content	Username and password, key-based authentication via File Path or Key Content. Password+Public Key Authentication is also supported.	- UI fields for the SFTP Connector will be conditionally visible based on the authentication type selected, with specific fields available for username/password and public key authentication methods.
Configuration	Connection property	Remote Directory field is overrideable via document property.	- Overridable Remote Directory through document properties
Configuration	Directory Creation and Deletion	Directory Creation, Directory Deletion	- Ability to create directories in Write (formerly CREATE) operation - Ability to delete directories in the Delete (formerly DELETE) operation
Configuration	Basic SFTP Configuration	Advanced Configuration	- Advanced configuration options include a custom configuration UI section for key-value pair management and encryption or custom configurations.
Operations	LISTEN	Listen	- Operation has been renamed to Listen - Ability to specify subdirectories (relative to the parent path in connection) in the Listen operation
Operations	CREATE	Write	- Operation has been renamed to Write - Option to create the directory if it doesn't exist (Improvement) - Log operation properties (Improvement) - Document Properties now include File Name and Remote Directory - UPSERT Operation was merged into Write Operation
Operations	GET	Read	- Operation has been renamed to Read. - Delete file after reading option was replaced with Action After Read. The new UI will have four radio button options: - None: No action after read - Get and Move (new): Overrideable Operation Property for new Directory. - Get and Rename (new): Overrideable Operation Property for new FileName. - Get and Delete (behaves just like SFTP V2).
Operations	QUERY	-	- Operation was merged with List Operation.
Operations	UPSERT	-	- Operation no longer supported. - Refer to Write Operation
Operations	DELETE	Delete	- Operation was renamed to Delete. - Supports directory deletion with a new object, Directory, for imports. - Option to recursively delete within a directory.
Operations	LIST	List	- Operation has been renamed to List. - Operation now has a response profile (import).

Based on the key differences outlined above, consider the following when migrating:

• Operation Names: Update any existing processes that use the old operation names (CREATE, GET, QUERY, UPSERT, LIST) to the new names (Write, Read, Search, Delete, List).
• UPSERT Operation: The UPSERT operation has been merged into the Write operation. Adjust any processes that use UPSERT to use Write instead.
• QUERY Operation: The QUERY operation has been merged into the List operation. Adjust any processes that use QUERY to use List instead.
• Advanced Configuration: SFTP (new) offers advanced configuration options. Review these options to potentially enhance your SFTP processes.
• Encryption Methods: SFTP (new) supports a more extensive list of encryption protocols and ciphers. Ensure compatibility with your security requirements.
• Action After Read: The former GET operation's "Delete file after reading" option has been replaced with "Action after Read". Update your processes to use the new options:
  • Get and Move
  • Get and Rename
  • Get and Delete
• Directory Operations: SFTP (new) allows creating and deleting directories within the Write and Delete operations. Update your processes accordingly.

Connection Configuration Differences Between SFTP V2 (Deprecated) and SFTP (new)

The following table summarizes the changes in connection configuration fields between SFTP V2 (Deprecated) and SFTP (new):

SFTP V2 (Deprecated) Field Name	SFTP (new) Field Name	Notes
Authentication Type	N/A	This field is removed in favor of supporting username and password authentication in conjunction with key file paths.
Remote Directory	Remote Directory	Unchanged
Host	Host	Unchanged
User Name	User Name	Unchanged
Password	Password	Unchanged
Port	Port	Unchanged
N/A	Key Authentication	New field. Default is "None"
Client SSH Key File Path	Key File Path	Applies only when "Key Authentication" is "Key File Path"
Key File Password	Key File Password	Unchanged. Applies only when "Key Authentication" is "Key File Path"
Known Host Entry	Known Host Entry	Unchanged.
Use Max Key Exchange size of 1024	N/A	This field is removed. This backward compatibility-based checkbox isn't necessary in the new connector.
Private Key Content	Key Content	Applies only when "Key Authentication" is "Key File Content"
N/A	Key Content Password	New field. Applies only when "Key Authentication" is "Key File Content"
Public Key Content	Public Key Content	Applies only when "Key Authentication" is "Key File Content"
Key Pair Name	Key Pair Name	Applies only when "Key Authentication" is "Key File Content"
Use Keys' content for authentication	N/A	This field is removed.
Use Connection Pooling	Use Connection Pooling	Unchanged. (Checkbox)
Use Proxy	Use Proxy	Unchanged. (Checkbox)
Choose Proxy Type	Choose Proxy Type	Unchanged. Applies only when "Use Proxy" is "Checked"
Proxy Host	Proxy Host	Unchanged. Applies only when "Use Proxy" is "Checked"
Proxy Port	Proxy Port	Unchanged. Applies only when "Use Proxy" is "Checked"
Proxy Username	Proxy Username	Unchanged. Applies only when "Use Proxy" is "Checked"
Proxy Password	Proxy Password	Unchanged. Applies only when "Use Proxy" is "Checked"
Connection Timeout (ms)	Connection Timeout (ms)	Unchanged.
Read Timeout (ms)	Read Timeout (ms)	Unchanged.

The following lists the major differences:

• Authentication Type Removed: The "Authentication Type" field has been removed. SFTP (new) now supports username/password authentication directly in conjunction with key file paths/content.
• Key Authentication Field Added: A new "Key Authentication" field is added, with a default value of "None." This field determines how key-based authentication is handled (e.g., "Key File Path," "Key File Content").
• Key Content Password Added: A new "Key Content Password" field is added, which applies only when "Key Authentication" is "Key File Content."
• Obsolete Fields Removed: The "Use Max Key Exchange size of 1024" and "Use Keys' content for authentication" fields have been removed. These were related to backward compatibility and are no longer needed.
• Other Fields Unchanged: Most other fields, such as "Remote Directory," "Host," "User Name," "Password," "Port," proxy settings, and timeouts, remain unchanged.

These changes reflect a more streamlined and flexible approach to authentication in SFTP (new), removing unnecessary options and providing clearer configuration for key-based authentication.

SFTP (new) Advanced Configuration tab

Overview

The Advanced Configuration tab in the SFTP Connection Component provides granular control over the JSch session during client connection negotiation. This feature allows connector developers to override default settings and customize the SFTP connection to meet specific security and performance requirements.

Important Considerations

The configurations on this page correspond directly to settings applied to the JSch session during client connection negotiation. Users should exercise caution when modifying these settings, as improper configuration may impact connection stability or security.

As stated in the interface, please do not modify the contents of this configuration unless you are confident in its implications. The JSch README provides a comprehensive understanding of all available configuration options and algorithms.

Available Configuration Options

The Advanced Configuration tab offers the following customization options:

Key Exchange (KEX)

Controls the algorithms used for key exchange during the SSH handshake. The default options include:

• curve25519-sha256
• curve25519-sha256@libssh.org
• ecdh-sha2-nistp256
• ecdh-sha2-nistp384
• ecdh-sha2-nistp521
• diffie-hellman-group-exchange-sha256
• diffie-hellman-group16-sha512
• diffie-hellman-group18-sha512
• diffie-hellman-group14-sha256

Server Host Key

Specifies acceptable host key types for server authentication:

• ssh-ed25519
• ecdsa-sha2-nistp256
• ecdsa-sha2-nistp384
• ecdsa-sha2-nistp521
• rsa-sha2-512
• rsa-sha2-256

Cipher (s2c)

Defines encryption algorithms for data sent from the server to the client:

• aes128-ctr
• aes192-ctr
• aes256-ctr
• aes128-gcm@openssh.com
• aes256-gcm@openssh.com

Cipher (c2s)

Defines encryption algorithms for data sent from the client to the server:

• aes128-ctr
• aes192-ctr
• aes256-ctr
• aes128-gcm@openssh.com
• aes256-gcm@openssh.com

MAC (s2c)

Specifies message authentication code algorithms for server-to-client communication:

• hmac-sha2-256-etm@openssh.com
• hmac-sha2-512-etm@openssh.com
• hmac-sha1-etm@openssh.com
• hmac-sha2-256
• hmac-sha2-512
• hmac-sha1

MAC (c2s)

Specifies message authentication code algorithms for client-to-server communication:

• hmac-sha2-256-etm@openssh.com
• hmac-sha2-512-etm@openssh.com
• hmac-sha1-etm@openssh.com
• hmac-sha2-256
• hmac-sha2-512
• hmac-sha1

Compression (s2c)

Controls data compression for server-to-client communication:

• none (default)

Compression (c2s)

Controls data compression for client-to-server communication:

• none (default)

Language (s2c)

Configures language preferences for server-to-client communication. (Field appears empty in the interface.)

Language (c2s)

Configures language preferences for client-to-server communication. (Field appears empty in the interface)

Check Kexes

Verifies key exchange algorithms:

• sntrup761x25519-sha512@openssh.com
• curve25519-sha256
• curve25519-sha256@libssh.org
• curve448-sha512

Check MACs

Verifies message authentication code algorithms. (Field appears empty in the interface.)

Check Ciphers

Verifies encryption algorithms:

• chacha20-poly1305@openssh.com

Check Signatures

Verifies acceptable signature algorithms:

• ssh-ed25519
• ssh-ed448

SFTP Custom Configuration

The SFTP Custom Configuration section at the bottom of the tab allows users to define custom key-value pairs for additional configuration options not covered by the standard fields above.

The table includes columns for:

• Key: The configuration property name
• Value: The configuration property value
• Encrypted: Indicates if the value is encrypted
• Remove: Option to remove the property

By default, "No custom properties are defined" is displayed. Users can add new properties using the "Add Property" button. Keys already available for modification in the Advanced Configuration tab are restricted in the Custom Configuration section.

Migration Best Practices

1. Reference the JSch README for a complete list of possible configuration keys and appropriate values
2. Only modify these settings if you understand their implications on connection security and performance
3. Consider testing any custom configurations in a non-production environment first
4. Document any custom configurations made for future reference and troubleshooting

Important

For detailed differences in supported ciphers and key exchange across Boomi SFTP Connector versions, refer to this knowledge article:

Keys-and-Ciphers-Supported-by-the-Boomi-SFTP-Connectors

Write Operation (formerly CREATE)

Overview

The SFTP (new) Connector introduces several improvements to file operations, including a significant update to what was previously known as the CREATE operation. This section outlines the changes and enhancements made to this operation, now renamed as Write.

Key Changes

Renamed Operation: CREATE → Write

The operation previously named CREATE in the SFTP V2 (Deprecated) Connector has been renamed to Write in the SFTP (new) Connector. This change applies across all user interfaces, configurations, error messages, logs, and notifications within the connector.

The renaming provides more intuitive terminology that better reflects the operation's actual function while maintaining consistency with industry-standard terminology for file operations.

Enhanced Functionality

While preserving all the core functionality of the former CREATE operation, the Write operation now includes additional capabilities:

1. Directory Creation Capability

   • Similar to the UPSERT operation in the previous connector version, the Write operation now supports automatic creation of directories that do not exist.
   • When writing a file to a path where one or more parent directories are missing, the connector will create those directories automatically when this option is enabled.
   • This eliminates the need to first ensure the directory structure exists before writing files.

2. Improved Operational Logging

   • Enhanced logging of operation properties provides better visibility into the execution of the Write operation.
   • More detailed logs facilitate troubleshooting and monitoring of file creation processes.

3. Document Property Tracking

   • The Write operation maintains the existing document property tracking capabilities.
   • Key properties such as File Name and Remote Directory are tracked via process reporting.
   • These tracked properties allow for better monitoring and auditing of file creation activities.

Configuration Options

The Write operation in the SFTP (new) Connector includes the following configuration options:

Option	Description
Create Directory if it Doesn't Exist	When enabled, it automatically creates any missing directories in the specified path before writing the file.

Usage Example

The following example demonstrates the configuration of the Write operation to create a file in a potentially non-existent directory:

1. Configure the SFTP (new) Connector with appropriate connection settings.
2. Select the "Write" operation.
3. Enable the "Create Directory If Not Exists" option.
4. Specify "/reports/monthly/2023/march/" as the Remote Directory.
5. Set financial_summary.csv as the File Name.
6. Execute the operation.

In this example, if any of the directories in the path /reports/monthly/2023/march/ do not exist, they will be automatically created before writing the financial_summary.csv file.

Migration Considerations

1. While the automatic directory creation feature adds convenience, validation checks should be implemented to ensure files are being written to their intended locations.
2. Use the enhanced logging capabilities to monitor and audit file creation operations, especially in production environments.

Compatibility Notes

The Write operation maintains backward compatibility with the core functionality of the former CREATE operation.

Read Operation (formerly GET)

Overview

As part of the migration from SFTP V2 (Deprecated) to the SFTP (new), the operation previously known as GET has been renamed to Read. This section outlines the changes to this operation and provides guidance for migrating existing processes.

Key Changes

Renamed Operation: GET → Read

The operation previously named GET in the SFTP V2 (Deprecated) Connector has been renamed to Read in the SFTP (new). This change applies to all user interfaces, configurations, error messages, logs, and notifications within the connector.

While the name has changed, the core functionality remains the same - the operation still retrieves files from an SFTP server and processes them within your Boomi flow.

Enhanced Post-Read Actions

The most significant functional enhancement to the Read operation is the replacement of the simple "Delete file after reading" option with a more comprehensive "Action after Read" feature.

Previous Functionality (SFTP V2 (Deprecated))

• Basic "Delete file after reading" checkbox option

New Functionality (SFTP New)

• "Action after Read" selection with multiple options:

  • None - No action taken after reading (default)
  • Move - Moves the file to a specified directory
    • Requires a new directory path (absolute path)
    • Path can be set as an overridable operation property
  • Delete - Removes the file after successful reading
  • Rename - Changes the filename while keeping it in the same directory
    • Requires a new filename
    • Filename can be set as an overridable operation property

Configuration Changes

The following table outlines the configuration changes between SFTP V2 (Deprecated) and SFTP (new) for the GET/Read operation:

SFTP V2 (Deprecated) (GET)	SFTP (Read)	Notes
Delete file after reading	Action after Read	Expanded functionality with multiple options
N/A	Move to Directory	New field, appears when "Move" is selected
N/A	New Filename	New field, appears when "Rename" is selected

Migration Considerations

When migrating existing processes from SFTP V2 (Deprecated) to SFTP (new), consider the following:

1. DELETE Action Mapping:

   • If "Delete file after reading" was enabled in your SFTP V2 (Deprecated) connector:
     • Select "Delete" as the "Action after Read" in SFTP (new)
   • If "Delete file after reading" was disabled:
     • Select "None" as the "Action after Read" in SFTP (new)

2. Process Review:

   • Consider if the enhanced post-read actions (Move, Rename) offer opportunities to simplify your processes
   • Review any custom error handling that may have been implemented around file cleanup

3. Testing:

   • Test the migration thoroughly, particularly if you were previously using "Delete file after reading".
   • Verify that files are properly processed according to your post-read action settings.

Usage Example

The following example demonstrates the configuration of the Read operation with post-read actions:

1. Configure the SFTP (new) connector with appropriate connection settings.
2. Select the "Read" operation.
3. Configure the basic parameters:
   • Set the Remote Directory to "/incoming/orders/"
   • Set the File Name to order_*.csv
4. Configure the post-read handling:
   • Set "Action after Read" to "Move"
   • Set "Move to Directory" to "/processed/orders/"
5. Execute the operation.

In this example, the connector will:

• Read all files matching the pattern order_*.csv from the "/incoming/orders/" directory
• Process each file through the Boomi flow
• Move each successfully processed file to the "/processed/orders/" directory

Example Migration Scenarios

Scenario 1: Basic GET with Delete

SFTP V2 (Deprecated) Configuration:

• Operation: GET
• Delete file after reading: Yes

SFTP (new) Configuration:

• Operation: Read
• Action after Read: Delete

Scenario 2: GET with Manual File Management

SFTP V2 (Deprecated) Configuration:

• Operation: GET
• Delete file after reading: No
• File managed through separate process steps

SFTP (new) Configuration:

• Operation: Read
• Action after Read: None

Scenario 3: GET with Process Simplification Opportunity

SFTP V2 (Deprecated) Configuration:

• Operation: GET
• Delete file after reading: No
• Separate SFTP Connector with RENAME or another process

SFTP (new) Configuration:

• Operation: Read
• Action after Read: Move or Rename (as appropriate)
• Move to Directory or New Filename: (Configure as needed)

Compatibility Notes

The Read operation maintains backward compatibility with the core functionality of the former GET operation. File retrieval behavior remains unchanged, with enhancements focused on post-retrieval actions.

List Operation (formerly LIST, formerly QUERY)

Overview

The SFTP (New) connector introduces an improved "List" operation, which replaces the "LIST" and "QUERY" operations from SFTP V2 (Deprecated). This operation allows users to retrieve a comprehensive list of files and directories from a specified remote directory on an SFTP server, along with detailed metadata about each item.

Key Changes

Renamed Operation: LIST → List

The operation previously named "LIST" in the SFTP V2 (Deprecated) Connector has been renamed to List in the SFTP (new) connector. This change applies to all user interfaces, configurations, error messages, logs, and notifications within the connector.

While the name has changed, the core functionality remains the same - the operation still retrieves directory and file listings from an SFTP server.

Enhanced Response Profile and Object Types

The List operation in SFTP (new) includes significant improvements to the response profile and object types:

1. Improved Response Profile
   • The import functionality has been fixed to provide more consistent behavior. The file size property is now clearly documented with proper units
2. Enhanced Browse Functionality
   • The Browse feature now surfaces two distinct descriptor-provided objects:
     • File: Access to the actual file data
     • File Metadata: Access to file properties and attributes
3. Object Type-Specific Behavior
   • Functionality now diverges appropriately based on the object type:
     • File:

• Provides access to the actual file contents
• Still allows inclusion of metadata as tracked properties
  • File Metadata:
• Provides detailed file information without retrieving file contents
• Adds support for recursive directory listing (off by default)

Configuration Options

The List operation in SFTP (new) includes the following configuration options:

Option	Description
Remote Directory	Specifies the target directory path on the remote server to list the contents from
Object Type	Determines whether to return a File or File Metadata
Include Metadata	When using File, enables inclusion of file metadata as tracked properties
Recursive Listing	When using File Metadata, enables listing files in subdirectories (default: off)

File Metadata Details

The List operation returns comprehensive metadata for each file, including:

Property	Description	Notes
fileName	Name of the file or directory	Alphanumeric
directory	Parent Directory of the file or directory	Alphanumeric
fileSize	Size of the file	Bytes
modifiedDate	Last modification timestamp	ISO 8601 format
isDirectory	Indicates if the item is a directory	Boolean

Migration Considerations

When migrating existing processes from SFTP V2 (Deprecated) to SFTP (new), consider the following:

1. Operation Name Change:

   • Update any documentation or training materials to reflect the new "List" operation name
   • Review process maps and integration documentation for references to the old operation name

2. Response Profile Changes:

   • Review and potentially update any downstream processing that relies on the format of the SFTP V2 (Deprecated) LIST operation response
   • Verify that any custom error handling related to the SFTP V2 (Deprecated) LIST operation is updated

3. Object Type Selection:

   • Determine whether your existing processes require File or File Metadata
   • Configure the appropriate object type based on your process needs

4. Recursive Directory Listing:

   • Consider whether recursive directory listing would benefit your processes
   • Be aware of performance implications for large directory structures when enabling this option

Usage Example

The following example demonstrates the configuration of the List operation to retrieve file metadata with recursive directory listing:

1. Configure the SFTP (new) connector with appropriate connection settings.
2. Select the "List" operation.
3. Configure the operation parameters:
   • Set the Remote Directory to "/reports/quarterly/"
   • Select "File Metadata" as the Object Type
   • Enable the "Recursive Listing" option
4. Configure any additional filtering options as needed.
5. Execute the operation.

In this example, the connector will:

• Connect to the SFTP server
• Retrieve metadata for all files and directories within the "/reports/quarterly/" directory
• Retrieve metadata for all files and directories in any subdirectories (due to the Recursive Listing option)
• Return this information as structured data that can be processed in subsequent steps of your Boomi flow
• Each file's metadata will include name, size (in bytes), last modified time, file type, and other attributes

This configuration is particularly useful for inventorying files across a complex directory structure or for preparing a batch processing operation.

Example Migration Scenarios

Scenario 1: Basic File Listing

SFTP V2 (Deprecated) Configuration:

• Operation: LIST
• Basic directory listing with no special configuration

SFTP (new) Configuration:

• Operation: List
• Object Type: File Metadata
• Recursive Listing: Off

Scenario 2: File Content Retrieval with Metadata

SFTP V2 (Deprecated) Configuration:

• Operation: LIST
• With additional configuration to access file content and metadata

SFTP (new):

• Operation: List
• Object Type: File
• Include Metadata: Yes

Scenario 3: Comprehensive Directory Traversal

SFTP V2 (Deprecated) Configuration:

• Operation: LIST
• Possibly with multiple operations or custom logic to handle subdirectories

SFTP (new) Configuration:

• Operation: List
• Object Type: File Metadata
• Recursive Listing: On

Compatibility Notes

While the List operation maintains compatibility with the core functionality of the former LIST operation, the enhanced object types and configuration options offer new capabilities that may allow for process simplification. Review existing processes to identify opportunities for improvement using these new features.

Delete Operation (formerly DELETE)

Overview

The SFTP (new) connector includes an improved "Delete" operation, which replaces the "DELETE" operation from SFTP V2 (Deprecated). This operation allows users to remove files or directories from a specified location on an SFTP server, providing essential file management capabilities within integration processes.

Key Changes

Renamed Operation: DELETE → Delete

The operation previously named "DELETE" in the SFTP V2 (Deprecated) Connector has been renamed Delete in the SFTP (new) connector. This change applies to all user interfaces, configurations, error messages, logs, and notifications within the connector.

While the name has changed, the core functionality remains the same - the operation still removes files from an SFTP server as long as they are not locked.

Enhanced Directory Support

The Delete operation in SFTP (new) now includes improved support for directory objects:

1. Directory Object Imports
   • The operation now fully supports importing directory objects
   • This enhancement allows for more streamlined directory management within processes

Operation Details

The Delete operation removes a file or directory at a specified path on the SFTP server, provided the item is not locked and the user has sufficient permissions.

Key Features

• Targeted Deletion: Users can specify the exact file or directory path to be deleted
• Error Handling: Clear error messages are provided in case of failures
• Logging: All Delete actions are logged for auditing purposes
• Permission Verification: The operation verifies that the user has sufficient permissions before attempting deletion

Configuration Options

The Delete operation in SFTP (new) includes the following configuration options:

Option	Description
id	Specifies the target file or directory path on the remote server to be deleted. The ID is added to the remote directory path specified in the connection settings or overridden in the document property, creating the full path to the specific file or directory on the remote server that needs to be deleted.

Migration Considerations

When migrating existing processes from SFTP V2 (Deprecated) to SFTP (new), consider the following:

1. Operation Name Change:

   • Update any documentation or training materials to reflect the new "Delete" operation name
   • Review process maps and integration documentation for references to the old operation name

2. Directory Object Support:

   • Review processes that involve directory management to take advantage of the enhanced directory support
   • Consider whether previously complex directory management processes can be simplified

3. Error Handling Review:

   • Verify that any custom error handling related to the DELETE operation is updated
   • Consider adding specific handling for directory deletion scenarios

Usage Example

The following example demonstrates the configuration of the Delete operation to remove a directory and handle potential errors:

1. Configure the SFTP (new) connector with appropriate connection settings.
2. Select the "Delete" operation.
3. Configure the operation parameters:
   • Set Remote Directory to /archive/2023
   • Set the id parameter to "q1"
4. Add appropriate error handling in the process flow after the SFTP connector shape.
5. Execute the operation.

In this example, the connector will:

• Connect to the SFTP server
• Attempt to delete the "/archive/2023/q1/" directory
• If successful, continue processing

This configuration takes advantage of the enhanced directory object support in SFTP (new) while implementing proper error handling.

Example Migration Scenarios

Scenario 1: Basic File Deletion

SFTP V2 (Deprecated) Configuration:

• Operation: DELETE
• Remote Path: /path/to/directory
• Id: file.txt

SFTP (new) Configuration:

• Operation: Delete
• Remote Path: /path/to/directory
• Id: file.txt

Scenario 2: Directory Management

SFTP V2 (Deprecated) Configuration:

• Operation: DELETE
• Potentially limited or complex handling for directory objects

SFTP (new) Configuration:

• Operation: Delete
• Remote Path: /path/to/directory/
• Id: directoryName (Directory name to be deleted within the remote path specified above)
• Now with improved directory object support

Error Handling

The Delete operation error handling recommendation for various scenarios:

Error Scenario	Description	Recommended Handling
File Not Found	The specified file does not exist	Configure the process to handle gracefully if appropriate
Permission Denied	Insufficient permissions to delete the file	Verify credentials and permissions on the SFTP server
File Locked	The file is currently in use or locked	Implement retry logic with appropriate delays
Directory Not Empty	Some servers may not allow deletion of non-empty directories	Consider using a recursive deletion approach if needed

Compatibility Notes

The Delete operation maintains compatibility with the core functionality of the former DELETE operation. The primary enhancement is the improved support for directory objects, which may allow for process simplification when managing directories.

Listen Operation (formerly LISTEN)

Overview

The SFTP (new) connector includes a "Listen" operation, which replaces the "LISTEN" operation from SFTP V2 (Deprecated). This operation enables real-time monitoring of specified directories on an SFTP server for new files or changes, allowing for immediate processing of files as they arrive.

Key Changes

Renamed Operation: LISTEN → Listen

The operation previously named "LISTEN" in the SFTP V2 (Deprecated) Connector has been renamed Listen in the SFTP (new) connector. This change applies to all user interfaces, configurations, error messages, logs, and notifications within the connector.

While the name has changed, the core functionality remains the same - the operation still monitors directories on an SFTP server for incoming files and triggers processes accordingly.

Enhanced Event Monitoring

The SFTP (new) Listen operation includes significant enhancements to event monitoring capabilities:

1. Granular Event Types

   • New options to specify which types of events to monitor:
     • Include Create events - Detect when new files are created
     • Include Modify events - Detect when existing files are modified
     • Include Delete events - Detect when files are deleted

2. Sub Directory Support

   • Explicit configuration for monitoring a subdirectory.

Operation Details

The Listen operation continuously monitors a specified directory on an SFTP server for file system events, triggering actions when events matching specified criteria are detected.

Key Features

• Directory Monitoring: Continuously watches a designated directory on the SFTP server for file changes
• Event Triggering: Initiates processing when file events are detected
• Event Type Filtering: Allows selective monitoring of create, modify, and/or delete events
• Configurable Parameters: Provides options for polling intervals and singleton processing

Configuration Options

The Listen operation in SFTP (new) includes the following configuration options:

Option	Description
Sub Directory	Specifies the subdirectory within the connection's base path to monitor
Polling Interval	Determines how frequently the connector checks for file events (in milliseconds)
Is Singleton	When enabled, it ensures only one instance of the process runs at a time
Include Create events	Enabled by default, detects and processes file creation events
Include Modify events	When enabled, it detects and processes file modification events
Include Delete events	When enabled, it detects and processes file deletion events

Usage Example

The following example demonstrates the configuration of the Listen operation to monitor a directory for file creation events:

1. Configure the SFTP (new) connector with appropriate connection settings.
2. Select the "Listen" operation.
3. Configure the operation parameters:
   • Set the Sub Directory to "boomiAutomation" (subdirectory within the connection's base path)
   • Set the Polling Interval to 3000 seconds
   • Disable "Is Singleton" if you want multiple instances to run concurrently
   • Enable "Include Create events" to detect new files
   • Disable "Include Modify events" if you don't need to detect file modifications
   • Disable "Include Delete events" if you don't need to detect file deletions
4. Set the Tracking Direction to "Output Documents"
5. Configure any downstream processing in the Boomi flow to handle the detected events.
6. Deploy and start the process.

In this example, the connector will:

• Connect to the SFTP server every 3000 milliseconds (3 seconds)
• Check the "boomiAutomation" subdirectory for any new file creation events
• When new files are created, generate output documents for processing in the flow
• Continue monitoring for new file creation events according to the polling interval

This configuration creates an automated workflow that monitors and processes only new file creation events, ignoring modifications and deletions.

Migration Considerations

When migrating existing processes from SFTP V2 (Deprecated) to SFTP (new), consider the following:

1. Operation Name Change:

   • Update any documentation or training materials to reflect the new "Listen" operation name
   • Review process maps and integration documentation for references to the old operation name

2. Event Type Specification:

   • Determine which event types (Create, Modify, Delete) are relevant to your process
   • Enable only the necessary event types to improve performance
   • Verify that the appropriate event options are selected based on your use case

3. Subdirectory Configuration:

   • Update your configuration to use the new "Sub Directory" parameter format
   • Ensure the subdirectory is specified relative to the connection's base path

4. Singleton Processing:

   • Decide whether to enable "Is Singleton" based on your concurrency requirements
   • Consider the impact on process execution if multiple instances need to run simultaneously

Example Migration Scenarios

Scenario 1: Basic File Creation Monitoring

SFTP V2 (Deprecated) Configuration:

• Operation: LISTEN
• Polling Interval: 1 millisecond
• Is Singleton: Enabled

SFTP (new) Configuration:

• Operation: Listen
• Sub Directory: (appropriate subdirectory)
• Polling Interval: 1 millisecond
• Is Singleton: Enabled
• Include Create events: Enabled
• Include Modify events: Disabled
• Include Delete events: Disabled

Scenario 2: Comprehensive File Event Monitoring

SFTP V2 (Deprecated) Configuration:

• Operation: LISTEN
• Polling Interval: 60000 milliseconds (60 seconds)
• Is Singleton: Disabled
• (Limited event type options)

SFTP (new) Configuration:

• Operation: Listen
• Sub Directory: (appropriate subdirectory)
• Polling Interval: 60000 milliseconds (60 seconds)
• Is Singleton: Disabled
• Include Create events: Enabled
• Include Modify events: Enabled
• Include Delete events: Enabled

Performance Considerations

When using the Listen operation, consider these performance factors:

1. Polling Interval: More frequent polling (smaller millisecond values) increases responsiveness but also increases server load and connection frequency
2. Event Type Selection: Enabling multiple event types increases processing but provides more comprehensive monitoring
3. Singleton Processing: Using "Is Singleton" prevents multiple instances but may cause processing delays
4. Directory Size: Monitoring directories with large numbers of files may impact performance
5. Event Processing Time: Ensure that event processing can complete within the polling interval to prevent backlogs

Compatibility Notes

The Listen operation maintains compatibility with the core functionality of the former LISTEN operation while offering enhanced event type filtering. The primary changes are:

1. The naming convention (LISTEN → Listen)
2. The addition of granular event type monitoring options
3. The explicit subdirectory configuration