Thank you for your question. SnapLogic pools SFTP sessions at the node (JVM) level. It does not create a pool per pipeline execution, and each SSH/SFTP-enabled Snap does not manage its own separate pool. Scope • Session pooling applies primarily to Binary Snaps (for example File Reader, File Writer and Directory Browser) when they use the SFTP protocol. Hadoop Snaps may also use it. • The pool is per node, not per Snaplex. Pipelines and Snaps running on the same node share it. How it works 1. A Snap obtains a session to the SFTP server, then opens a channel on that session. 2. Pooling is enabled by default. Sessions are keyed on server credentials: host, port, username and password. Snaps that connect with the same credentials can reuse a session, even if they use different SnapLogic accounts. 3. If an idle session is available, it is used. A session found to be dead is discarded and the next idle session is tried. If none are active, a new session is created. After use, the session returns to the cache. 4. By default each session carries one channel, so one session cannot serve multiple Snaps at the same time. Concurrent Snaps with the same credentials therefore open separate sessions unless the channel limit is raised. 5. A session idle past its timeout is discarded. Configuration (JVM options on the node) • cacheSftpSessions: set to false to disable pooling (default: enabled). • maxSftpChannels: maximum channels per session. The default is 1. Raise it to let one session be shared by multiple Snaps at once. • sftpSessionTimeoutSec: idle timeout after last use (default 3600 seconds, i.e. 1 hour).
Hi everyone — I wanted to put a great member of the SnapLogic community on your radar. Sanchita Ghuge, who many of you may know through her work at Gensler, is currently exploring her next career opportunity, and I wanted to help broaden her network within our community. Sanchita brings 8+ years of enterprise data integration and data engineering experience, including more than seven years working on complex integration environments at Gensler. She has deep, hands-on experience with SnapLogic, along with Python, SQL/T-SQL, Microsoft Fabric, SSIS, Azure Data Factory, REST APIs and enterprise data architecture. Her experience spans a broad range of enterprise platforms and business domains, including Workday, Salesforce, Anaplan, Kyriba, Active Directory, Vantagepoint, finance, HR, payroll and banking systems. She has also been heavily involved in platform modernization, production integration support, monitoring and reconciliation, data-quality initiatives, and large-scale system migrations. More recently, she's also been exploring how AI can be applied to integration operations and incident triage, combining her core data engineering background with emerging AI technologies. Having worked with Sanchita through the Gensler/SnapLogic relationship, I wanted to reach out to this community in case anyone is hiring—or knows an organization looking for an experienced Data Integration Engineer, Data Engineer, Integration Engineer or similar technical role. If something comes to mind, please connect with Sanchita directly or feel free to share this with your network. LinkedIn: linkedin.com/in/sanchita-ghuge Wishing you all the best with the search, Sanchita! 🙌
Hi Matthew H. Has Next — keep it exactly as is, it's correct:
$.entity.meta.page.hasMore == trueNext URL — need to construct the next URL using from or to as a cursor. The pattern is usually:
"https://their-api-base-url.com/their/endpoint?from=" + $.entity.meta.page.to
The to value (2279) typically becomes the starting point for the next page — the API is likely paginating backwards through record IDs. To answer your direct question: No, do NOT replace the Has Next line. Keep it. Just add the Next URL field with the constructed URL above. --- To confirm the exact cursor field, should check your API docs — specifically whether the next page call uses from=<to_value> or cursor=<to_value> or something else. But the $.entity.meta.page.to value is almost certainly the right cursor to use. "What does the base URL of your API call look like, and is there a from or cursor query parameter?" — that'll confirm the Next URL expression pattern. 🙂